[Bluej-discuss] first languages

[Aryeh M. Friedman]

>> What is worse too much semantic overhead or the syntax from hell??!?!?!?
>>     
>
>   
First a small clarification:

Syntax from hell -- Scheme
Semantic overhead -- Java

> Syntax from hell?  All functions, whether built-in or user-defined, 
> are invoked using the exact same syntax rule. 
That is semantics not syntax.... I am sure one can call APL or the
sendmail config file semantically clean but try to read it!

>  There's no ambiguity, 
> so you don't need to memorize a table of operator precedence.  

There is conceptual ambiguity in pre/post fix because it is so
unfamiliar to non-CS people.

> One 
> word, one semantics; there are no keywords (like "virtual" in C++) 
> that mean half a dozen different things in different syntactic 
> contexts.  The only syntactic "concept" you need to learn is nesting, 
> which you would also need to learn in Java, C, C++, perl, Python, 
> Pascal, Fortran, BASIC, even HTML.  In fact, I suspect the average 
> Scheme/Lisp program has LESS syntactic nesting than the average 
> program in any of those other languages, once you count parentheses, 
> curly-braces, square-brackets, and keywords (each of which has 
> different semantics).  Anyway, a good beginner-oriented IDE like 
> DrScheme can help with the nesting, e.g. shading code between 
> matching parentheses.
>   

If a lang needs an ide just to be writable (parens in LISP) it is not a
beginners lang ;-)
>   
>> the best compermise I have found between the two from a teaching stand
>> point is Mozart (www.mozart.org)... at one level it is a very
>> semantically/syntactical clean lang but at a deeper level incorporates
>> some features *I WISH* java did like real data flow variables vs. this
>> hard to visualize mutex stuff.... an other advantage is if taught right
>> (see Peter VonRoy's book [don't have an URL]) it introduces each concept
>> at exactly the right time...
>>     
>
> I've got the book, and have heard very good things about it, but 
> haven't had time to read much of it myself, much less learn Oz. 
> (That's on my to-do list for the next few months, as I consider using 
> Oz in a "principle of programming languages" course next semester.)
>
> Introducing each concept at exactly the right time is an important 
> consideration.  The way I put it (with regard to programming 
> language) is
> 1) Introduce only one language feature at a time;
>   

Thats why I like Oz so much I have never seen a more orthanginal language.

> 2) Introduce each language feature only when it's necessary to convey 
> an important programming concept;
>   
Due to lazy eval and a few other semantic sugers (not to mention some
matching syntactical ones) almost all concepts can be taught
atomically... for example var's can be taught without much concern for
explaining scope (it just magically falls out in most cases).

> 3) Corollary to 2: any language feature that doesn't help you teach a 
> CS1 concept doesn't belong in CS1, no matter how cool it is.
>   

Agree completely and except for the last few chapters of Peter's book he
is dead on with the same concept (except for him CS1 seems to mean a 1st
semster grad school CS refresher for students whose BA is not CS... what
I mean is it covers the same ground undergrad CS1 does but at a level
that assumes a very good grasp of higher math and elementary
computational theory)
> (For example, one of the dialects of Scheme shipped with DrScheme has 
> data flow variables, if I understand what you mean by that, but I 
> wouldn't dream of introducing them in CS1.)
>   

If by data flow variables you mean concurrency via "value" locks (very
hard to explain in a short email but basically the way I have always
visualized it is if I need some event in an other thread to happen
before the current thread proceeds data flow handles this
automatically).   Matter of fact I am writting a OS and the only reason
for not using Oz to do it is its memory model is completely wrong for
machine level interaction (eg. writing a device driver would be
impossible with it) so instead I am working on making a Java vm that
just happens to be identical to a x86 and a matching compilor to do the
OS with (while I am at it I am going to add data flow variables to the
lang [so not completely Java])
>   
>> Mozart is functional and it is clearer ***BUT*** almost all functional
>> langs are too dynamic for easy debugging and it is almost not to
>> introduce some very non-mainstream concepts like monad's.
>>     
>
> Something went wrong with that last sentence; could you type it again?
>   

I meant that most functional languages, in allowing you to functionalize
all operators, become too flexible for easy debugging unless you a very
experienced and disciplined debugging specialist.
> I do introduce (in a CS0 course full of theatre and history majors) 
> some "non-mainstream concepts" like higher-order functions, because 
> they're so easy to do in Scheme.  Why are these "non-mainstream"? 
> Because they're difficult to express in C++, and even more difficult 
> (albeit more consistent) in Java.
>   

I have never completely understood the concept of "monads" but it seems
every time I see functional langs discussed they come up very quickly.