ML: psychological basis of language ranking?

[Avoi...@gmail.com]

What does Harper mean?
I'll try to interpret this first/easier one, my self:
]Object-oriented programming is eliminated entirely from the
]introductory curriculum, because it is both anti-modular and
]anti-parallel by its very nature, and hence unsuitable for a modern
]CS curriculum.
Does he mean, that since the essence of OO is that objects
are defined [hence dependant on] by their ancestor, knowledge
about an object can't be decoupled from knowledge about its
ancestors?

Which leads into my main topic: we need to STATE our top-goal
for computer-languages; which surely [like all else in life] is to
get the best cost::benefit ratio. The cost/pain comes largely from
having to remember and be-concerned-about stuff.

So is he saying, that the cost for OO comes from the need to
be-concerned-about the ancestors?

Yes, for me, the freedon to NOT be-concerned-about
side issues is a MASSIVE advantage for any programming
system. And the ability to 'pipe/data-transform' sequentially
like forth, and at tested/confirmed stageN not to need to
be-concerned-about stageN-2.

Does ML support such a [concatenative] style?

Where's the literature about the psychological basis of computer
language design, instead of vague implications of 'why you like it'?

====> Then in
http://existentialtype.wordpress.com/tag/type-theory/
he writes: [in my simplified non-LaTex notation]

>In languages we have the fundamental concept of a typing judgement, written
> x1:A1,...xn:An => M:A
> stating that M is an expression of type A involving variables xi of type Ai.

That's OK.
>
>A typing judgement must satisfy the following basic structural properties:
> x:A => x:A
>
> y:B => N:C x:A => M:B
>-----------------------
> x:A => [M/y]N:C
>
> We may think of the variables as names for "libraries", in which
> case the first states that we may use any library we wish, and the
> second states closure under "linking" (as in the Unix tool ld or its
> relatives), with [M/x]N being the result of linking x in N to the
> library M .

Let's try to unpick that, in steps:
y:B => N:C
means N is an expression of type C involving variable y of type B
x:A => M:B
means M is an expression of type B involving variable x of type A

By `"linking" (as in the Unix tool ld)`, does he mean 'replace the
expression, with the code-which-implements it'?

What is his main point?

== TIA.

[Torben Ægidius Mogensen]

Avoi...@gmail.com writes:

> What does Harper mean?
> I'll try to interpret this first/easier one, my self:
> ]Object-oriented programming is eliminated entirely from the
> ]introductory curriculum, because it is both anti-modular and
> ]anti-parallel by its very nature, and hence unsuitable for a modern
> ]CS curriculum.
> Does he mean, that since the essence of OO is that objects
> are defined [hence dependant on] by their ancestor, knowledge
> about an object can't be decoupled from knowledge about its
> ancestors?

I don't think so. Objects are anti-paralllel because the fundamental
operation on modules is reading and updating storage local to the
object. I'm not sure what in particular makes him call them
anti-modular, but it might be for much the same reason: If there is
local mutable state in objects, you can't compose them freely, as a use
of the object in one place can affect another use of the same object in
another place in a way that you can't predict from its interface.

> Yes, for me, the freedon to NOT be-concerned-about
> side issues is a MASSIVE advantage for any programming
> system. And the ability to 'pipe/data-transform' sequentially
> like forth, and at tested/confirmed stageN not to need to
> be-concerned-about stageN-2.
>
> Does ML support such a [concatenative] style?

If I understand you correctly, it does. Function composition is natural
and easy in ML.

The main point is that types act as contracts: If you replace a variable
of type B with an expression of type B, this will not yield typpe errors
and the type of the surrounding expression should not change by this
exchange. Basically, An expression of type B has the same type in every
context (assuming free variables, in this case x, do not change their
type in the different contexts).

Torben