Re: Some exciting new trends in concurrency and software design

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Fri, 24 Jun 2011 12:32:50 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> That's Ada history. Find it looking for "Requirements for
> High Order Computer Programming Languages".
Will have look, thanks for the reference

> The pattern of ignoring things is present in ML syntax.
If I understand you correctly, this is not a pattern provided by the  
language to design things with the language, but a pattern which was  
applied when designing the language. This is not the same.

> Andrew
> Appel expounds in his Critique of ML. In one paragraph, he mentions
> that ML syntax does not get him into trouble any more.  But in later
> paragraphs, he explains at some length where and how ML syntax was
> *not* given the same attention as the semantics of Standard ML, and
> why this is not the best of things.
>
> I believe that ML syntax wasn't forgotten. Just ignored. It wasn't to
> be refined later, either.  It wasn't simplified for modeling
> reasons.  It was just ignored.  With SML out the door, we, the
> programmers,  can get our load of condescension when we complain
> about inscrutable error messages when some expression gulps the
> rest of the compilation unit:  "Why didn't you put the
> optional semicolon there, STUPID!? If your expression awaits
> another function, then the compiler is quite right to consider
> the next fun definition in the file to be that function!"  Or similar.
You got the point. I indeed agree with that: SML syntax is really an  
issue, and if registered into the wiki dedicated to discuss future  
evolution of SML, that was to suggest to rework the syntax. I have planned  
to argue it this way: leave the abstract semantic construct as-is, which  
is safe, and work on the syntax, which would be valuable and still safe. I  
feel this would add a big value at rather low cost.

Example is semi-colon omission as you said (the same error JavaScript  
did), there are also ambiguous construct which cannot be caught by the  
compiler and end into program which was not as intended by the writer. An  
example come with nested “case” conditional expressions (I had a very bad  
surprise with this one, ad since, I always wrap these within parenthesis).  
Another example is not an ambiguity, but an example of weird syntactical  
choice: “fun” vs “fn” (different meaning depending on the presence of a  
letter or not, is simply silly, as both refers to the a same word which so  
should have a unique meaning: “function”). There are also some know issues  
of SML compiler developers, involving structure instantiation, with some  
syntactical constructs (luckily rare enough) which are so much ambiguous  
without complex handling to solve the ambiguity, that no SML compiler  
support these.

It even happens I though a kind of SML-Lint would be welcome (the same  
kind of Lint you have with C-Lint or JS-Lint, which is not glorious for  
SML, I agree)

OK. But that is still not forgetting more or less low level aspects of a  
design, that is all about failures in the design of a language. Not what I  
introduced.

Side note: obviously Ada is an unbeatable winner in the area of syntax  
(may be modulus some comments worth to discuss, like the one you did about  
array components)

> (Do you recognize the familiar argument: Joe Bloggs, the programmer,
> writes something obviously correct, but it isn't correct; a language
> "feature" has caught Joe; then someone says that Joe is stupid (and
> shouldn't be programming) because Joe doesn't know the language
> "feature".)
Effect of a bad language syntax or hardly understandable semantic  
definition (like with C/C++), I know. The doctor should suggest Ada as a  
good medicine here :D

> Next they address us in managerial style to talk
Clever wording

> about the Practical
> Programmer who would just accept things the way they are.  Just don't
> have the makers of ML admit they have made a serious mistake
> when ignoring the very manifestation of human-computer interaction:
> the syntax.   And once the example is out, others will copy it.
Right, except as I said above, I am not a proponent of “forget about  
language design”.

Do you agree the targets are different ?

Silly choice of semi-colon omission behavior, as nothing to do with the  
target of helping the author to write at model level: this simply does not  
serve this target and was not introduced in that purpose (this what is  
called “Syntactic sugar” instead… see my actual signature, which is an old  
enough quote).

> Syntax is the means by which humans structure what they wish
> to express, a program in our case.  How can this be forgotten?
At least, what I am pleased with here, the the time you spent to point how  
much syntax is important (so I can still be pleased even if this not the  
matter I introduced :) ).

> When does industry accept the time loss spent in training
> awareness of idiosyncrasies and in tackling the effects
> of things ignored?
I do not know enough about industry (I am mostly jobless, you know), but I  
guess they often do irrational choices (people who sells generally do not  
understand the matters people who do have to deal with).

>> Not a language failure, but an application design error.
>
> When a language is basically not thread safe, I'll call it
> a language issue.
Finally, you are right for me.

> Let a problem P have a relational solution R. Demand that R be
> implemented using a non-relational, but acclaimed language O.
> Ignore programmers who mention that the admittedly fashionable
> choice O might turn out wrong, and costly in the long run.
Turns out to be a similar comment as the one you made above about industry  
losing time with silly design errors.

> Another instance of the pattern of ignoring things at work.  The
> motive here is the relative weight of feeling the immediate advantages
> of crowd decision on the one hand and concerns about long-term
> technical consequences on the other.  If the crowd is the current
> source of profit, the choice seems clear.
I have never invoked the crowd when promoting SML as a possible modeling  
language for some Ada applications or design parts.

> This is the crucial bit.  The goal is a language based on ML,  like
> ATS.  But by the pattern, the designers of ATS seem to ignore both
> ML's int (which raises Overflow in place of erroneous execution)
> and they also ignore alternative "functional ints".  Instead,
> for "practical reasons" I guess, they choose C int behavior.
> Assume that the new language is out the door, and is being used
> on commercial projects. Will it continue to offer only C int and
> associated semantics or will it move towards better defined int?
> Will sacred backwards compatibility be in the way of rectifying
> int towards ML's, for example?
I believe there is provision to rectify the definition of integers, as ATS  
seems not too much widely used for the time.

> Assume, for the sake of generalization, that a pointer points
> safely to a sum of addresses computed from int offsets.
OK, so this was in reference to the prior comment about integer operations  
errors.


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit