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
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 , 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* ).
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?).
"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 .
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]
"Semantics [...] is the study of meaning."
 What I'm considering here is ideas, rather than their expressions in
 Why this? (why this positive connotation?)
You received this message because you are subscribed to the Google Groups "PPIG
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.