On 10/04/15 20:18, oritha wrote:

Dear Psychology-of-Programing interest group members,

Following the Communications of the ACM publication *Is abstraction the key
to computing?* <http://dl.acm.org/citation.cfm?id=1232745>* (Jeff Kramer
2007)*, we are hoping to construct a test that measures students' ability
to use abstraction in problem solving situations in computer science and
software engineering.

As a starting point, we have formulated a set of 8 question patterns that
might serve as a means to teach and test abstraction. We would very much
appreciate your help in assessing their suitability. The question patterns,
as well as a request for information on your background experience, appear


Sorry for replying so late.

I think your research would make sense if it followed another process of research, namely about the notion of abstraction, which result were a definition of "abstraction", and of "level of abstraction", and this particularly in the context of programming. Without that, I find myself unable to answer any of the test's questions (and would be as well as a student forced to do it). Follow some ideas of mine.

I think the term "abstraction" is totally misused in programming and CS. (Not as much as "semantics", which is literally used backwards [1], but still...) I think we use the term, most commonly, to mean something like construction, expression, expressive construction, or semantic construction (in the proper sense of semantic: related to *meaning* [1]).

I think what we are constantly doing in programming is constructing new notions from other notions, all of which are fully abstract right from the start. For instance, consider the definition of a new type or a new procedure. Every constituent is fully abstract; in no way is the new notion constructed out of them abstract, or more abstract, relative to its constituents, is it? Or, how do you (do we implicitely) define "abstraction" or "level of abstraction"?

I think abstract is the opposite of concrete. Consider the following:
    "those 3 cows we saw yesterday eating grass on that hill flank"
This idea is, in my view, very concrete; more or less as concrete as can be when expressed in language. The ralevant aspect is that everything is put in a concrete context, and every point contributes to "concretise" (to "unabstract") the whole. See what I mean? There are 4 what-entities (we & the cows & grass & the hill), there is 1 what-process (eating grass), there is a when (yesterday), there is a where (on the hill), and there is a mental relation (see). All of that forms a concrete whole and generates a model of it (in mind of the listener). In fact, the only fully abstract point here, in my opinion, is 3 (maybe because numbers are, somehow, kinds of absolute abstractions?).

Now, consider:
    "3 cows eating grass on a hill flank"
The concrete cows, and the concrete hill flank are replaced by abstract ideas. They are out of (concrete) context, and they more or less lose all form. When reading that, we restore some form in mind, from knowing about cows and hill; however this is very different from the concrete (and real) and known forms of the concrete (ditto) and known cows and hill, isn't it?

Now, another variant:
    "those 3 animals we saw yesterday..."
This one is no more abstract than the original idea, I guess; just a little more *general*. We are still talking of concrete animals in a concrete context, only the term used to refer to them is more general. We still know the animals, and their concrete form. We are not talking of abstract categories (cow, animal) out of any concrete context, but of known and concrete and form-al ones. Those things, whether we call them cow or animal or whatnot are the concrete ones we know with a concrete form we also know --theirs for the matter. At times, we generalise constructions in programming, for instance when replacing a constant by a variable, or when introducing a new variable. However, not all generalisation is an abstraction. (But: maybe all abstraction also is a generalisation, by nature, by necessity?)

I think the notion of abstraction is very important, or should be, in programming (and CS, if CS were the science of programming). But misusing (if not abusing) it prevents it from playing the clarifying & "enlightening" role it may otherwise play when talking of this noble ;-) activity. Abstraction, in my view, happens on the modeling side of programming; totally in mind; it happens whenever we are thinking whatever we are programming, and desperately trying to form a coherent model of it. For instance, a model of the game I'm trying to develop. We construct fully abstract conceptual models. However, when talking of programming, for some reason(s), we never talk of *that*, of the modelisation process. Instead we talk of the expression side, where no abstraction ever happens, and none could ever, if I'm right, because there everything already is fully abstract: there, we are playing with totally abstract concepts (defined by prog langs or libs or whatnot) right from the start.

We use, in my view, "abstraction" like a magical incantation, a word devoid of any meaning, *and* of any referent (object) for the matter; the only very bit of meaning the term brings with it is a vague aspect of positive connotation [3]. If there were a research project on abstraction, and/or on abstraction in programming, I would be very interested.

[CC to mailing list 'PiLuD,' just in case]


[1] https://en.wikipedia.org/wiki/Semantics:
"Semantics [...] is the study of meaning."

[2] What I'm considering here is ideas, rather than their expressions in 

[3] Why this? (why this positive connotation?)

You received this message because you are subscribed to the Google Groups "PPIG 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ppig-discuss+unsubscr...@googlegroups.com.
To post to this group, send an email to ppig-discuss@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to