From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,f3bebae566a54cab X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news1.google.com!news.glorb.com!aioe.org!.POSTED!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: Some exciting new trends in concurrency and software design Date: Fri, 24 Jun 2011 15:45:08 +0200 Organization: Ada @ Home Message-ID: References: <8a5765ba-622a-42cd-9886-28ed7cfed31e@s17g2000yqs.googlegroups.com> <4dff5be5$0$6565$9b4e6d93@newsspool3.arcor-online.net> <9b65f3c7-caee-440f-99ed-0b257221ce58@m24g2000yqc.googlegroups.com> <1v2auyktde5q4.1wqpdg3fval5k.dlg@40tude.net> <4e03bb73$0$6584$9b4e6d93@newsspool3.arcor-online.net> <4e0467d3$0$6577$9b4e6d93@newsspool3.arcor-online.net> NNTP-Posting-Host: tcjcYi8FVf78iyoerU1krw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/11.11 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news2.google.com comp.lang.ada:20996 Date: 2011-06-24T15:45:08+02:00 List-Id: Le Fri, 24 Jun 2011 12:32:50 +0200, Georg Bauhaus = a =C3=A9crit: > 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 plann= ed = 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. A= n = example come with nested =E2=80=9Ccase=E2=80=9D 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: =E2=80=9Cfun=E2=80=9D vs =E2=80=9Cfn=E2=80=9D (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: =E2=80=9Cfunction=E2=80=9D). There are als= o 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 abo= ut = 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 =E2=80=9Cforget a= bout = language design=E2=80=9D. 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 n= ot = serve this target and was not introduced in that purpose (this what is = called =E2=80=9CSyntactic sugar=E2=80=9D instead=E2=80=A6 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 h= ow = 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 no= t = 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 indust= ry = 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 A= TS = 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 operatio= ns = errors. -- = =E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D [Ep= igrams on = Programming =E2=80=94 Alan J. =E2=80=94 P. Yale University] =E2=80=9CStructured Programming supports the law of the excluded muddle.= =E2=80=9D [Idem] Java: Write once, Never revisit