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!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!feeder.news-service.com!94.75.214.39.MISMATCH!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 03:27:25 +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> NNTP-Posting-Host: SY4WBM7bg4NAg3lX0bMRPQ.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:20992 Date: 2011-06-24T03:27:25+02:00 List-Id: Le Fri, 24 Jun 2011 00:17:23 +0200, Georg Bauhaus = a =C3=A9crit: > Ignoring things is a pattern in programming Funny wording :) > whose consequences, > while known to turn out expensive, are consistently ignored, too. > A pattern, incidentally, that seems to have been strikingly absent > when the HOLWG collected a catalog of language requirements more > than 30 years ago. Please, tell more > Ignoring some things can set the stage for successful software > business, since ignoring things allows concentrating on a model that > is simple, and clearly defined. Yes, that's the purpose of modeling. But this does not include on-purpos= e = erroneous design, as you erroneously suggest later (seems you've ignored= = some possible views on the topic :-P ). > A simple to use framework is an > example. Or a cute sequential scripting language. Or some easy to > program mapping of objects to relational database tables. (Or the aspe= ct > of a FPL that interests you most.) I was not talking about FPL in the large, as I know only one, which is S= ML = (others are too much different). And this one was not designed to be cut= e, = but to be sound. It was specified prior the first implementation (as you= = know I guess), just like Ada was, and this specification was not based o= n = The Great Cute Levels Catalog, but made of coherence proofs instead. = Unfortunately, you've made this error so much early, that a large part o= f = what you wrote since here is unclear due to that assumption. But you are= = still OK, as its my sole fault I was too much imprecise about the meanin= g = of =E2=80=9Cforget=E2=80=9D (will be clarified a bit later). > These simple offerings have a few characteristics in common: > > - They are all simple. > > -They can therefore be understood and handled by many. > > - They are therefore attractive, None of the three applies here. > So they are seen as having potential. Not really, as people complains the crowd did not adopted it (true for = Haskell too). > Alas, the potential turns out to be highly energetic. > > When the potential of simplified attractive offerings is activated, > its first effect is that "the market" quickly establishes businesses > around the simple offerings. It also establishes a workforce that > accumulates knowledge about these things; some will know the > framework, some will have learned the scripting language, some will > have started mapping objects to RDBMS tables. > > (Ada, I guess, has had its new market, too, but for different reasons,= > not because things had been ignored. "The mandate" would help create > Ada business in those years.) > > Second, the offerings' potential, when moving the marketm is then = > starting > to generate an ecosystem of work. Work that isn't easy, frequently no= t > fun, and not very productive: work that is about tackling the things t= hat > have been ignored. Such as: Hey, I was not talking about Python! > - when the framework turns out to be little more than boilerplate > text---but otherwise requires detailed knowledge of a vast configurati= on > sublanguage. > > - when the scripting language is used to process international text > in a concurrent environment and fails, since char issues and concurren= cy > have been ignored. Not a language failure, but an application design error. > - when the program's data model turns out to be relational, but > the object-as-a-table magic does not quite work. Wrong analysis. No language can avoid this, as this is often prior to = enough text in any language, except human's languages. > The workforce then finds themselves trying to reinvent a relational > database management system, investing man months ... You end into reinventing paradigms when you used the wrong language for = = the wrong thing, which was what I was arguing against in another message= = to someone (nicely) stating Ada is the best language ever for everything= . = I would not promote SML as the best language for everything, not more th= an = I would do this for Ada. You have to feel that SML is well suited for on= e = task prior to use it, or else, don't use it. In short, I would say SML i= s = well suited when 1) you want to express some kind of algorithm with the = = safety of avoiding side effects (which Ada can't prevent by nature) 2) = when you want to express an algorithm with some terseness, which is = something I know Ada lawyers will argue against, but which is anyway = better than abstract comments in an Ada program, which would be controll= ed = in no way and which would be too much interleaved with the Ada text to b= e = of real readability help 3) when you want expression based text, which m= ay = help proof by any mean (by hand, or why not automatic). To be honest, Ad= a = provides tools for the latter, especially since Ada 2012 and its = conditional expressions. But it still lack terseness and easy avoidance = of = side effects. Never mind, it should not provide these, as this is not it= s = purpose. When I said =E2=80=9Cforget things=E2=80=9D, I meant for example, forget= about number = limitations, explicit annotation of type (which are anyway statically = explicit to the SML compiler, thanks to type inference) to help tersenes= s = and then provided a better view of the whole with less cognition load, a= nd = forget about any other kind of memory concrete things, like available = memory, including memory management. When you start forgetting such things, you do not build anything = erroneous, you just create something which will need to be refined and = specialized, which is different than something which will need to be = totally redesigned. You may think of it as HTML+CSS, where HTML is the core of the meaning a= nd = CSS the layout layer: the core meaning of an algorithm may be the SML = text, and the meaning+presentation would be the concrete implementation = to = be presented to some machine or hardware, the one which is better = expressed with Ada, due to many of the requirement at this stage. If HTML forgets about presentation, that's for a good, and this does not= = lead to erroneous pages. This leads instead to pages with potentially = multiple implementation, due to clean separation of both, just like an S= ML = text may have multiple Ada implementations, depending on requirement:s = memory limitation, concurrency available or not, preference for sequenti= al = implementation or not, use of garbage collector or not -- which I = personally dislike, available or recommended width for numbers, etc. Thi= s = is of no help at all to introduce all of these too much early, this woul= d = have the same effect as obfuscation. > The reason that in the context of FPLs I'm mentioning this pattern (of= > deliberately ignoring some things being a cause and expensive work > being an effect) is that one of these languages, the ATS language, is > really highly efficient by design and also includes a proof system > right in the language. It has safe pointers, too. So it would seem > promising. Even as a layman, I am sure there are many interesting > advancedfeatures in ATS. > > But as usual, some things have been ignored. Yes, Among others, modularity (I still not tried this one, sorry, just = read about it). > As far as I can tell, at least these: > > The numeric types are, by default, basically int of ISO/IEC 9899 (C). > A factorial function of a large enough argument may therefore > return a number < 0. Likewise, watch the program > > implement main() =3D begin > print_int(4000000000) ; print_newline() > end > > $ ./a.out > -294967296 Does not stand for what I was suggesting to forget about. Otherwise I = would have suggested to simply leave Ada ;-) and I didn't. > O'Caml appears to be operating at a similar level, if my copy > isn't broken: > > # let i =3D 4000000000;; > val i : int =3D 4000000000 > # i * i;; > - : int =3D -2446744073709551616 > # Do you know what SML proponents says about OCaml ? They complains the = fundamental principles of SML were sacrificed to efficiency, it is = suspected to be less sound, and to be less safe due to heavy use of side= = effects. Let's try it with SML: Moscow ML version 2.01 (January 2004) Enter `quit();' to quit. - val i =3D 4000000000; ! Toplevel input: ! val i =3D 4000000000; ! ^^^^^^^^^^ ! Lexical error: integer constant is too large. Oops, integer too large, so let's drop a zero (I did not checked MoSML = specific limitations) - val i =3D 400000000; > val i =3D 400000000 : int - val j =3D i * i; ! Uncaught exception: ! Overflow Either a compiler error or a runtime exception. And that's not Moskow ML= = specific, that's by SML specification. Just to underline a modeling language which help to forget about = somethings, is not to be confused with a badly designed language. > The puzzling issue is why don't functional programmers just copy > the solution from Lisp, such as CMUCL? Or from Python? Are they > ignoring even "their own relatives"? > > * (let ((i 4000000000)) > (* i i)) > > 16000000000000000000 > * > >>>> i =3D 4000000000 >>>> i * i > 16000000000000000000L I could not understand that point. > Won't it be a good idea to first collect requirements for a system > of fundamental types such as whole numbers for use in new languages? > Then implement them for new functional languages. So as to *not* > build new ideas atop ISO/IEC 9899 and spoil it with the consequences > of importing int. Doing so seems like breaking future software by > design. I don't remember if I already told you (I feel I remember I did, but I m= ay = be wrong), but there is a plan to refine SML specifications. = Unfortunately, as this one is not famous enough, too few people contribu= te = ideas. This is still the best base I believe, due to the amount of work = = already done for that language (proved soundness and some experienced = users with worthy comments). > Continuing things ignored in ATS: > Syntax. Programmers will need initiation into another interpretation > of ASCII punctuation. ATS does use ASCII symbols, which may be a lot > better than words insofar as symbols are as international as "+". > The symbols have precisely specified meanings. But they have these > meanings in just this language. How many programmers use just > one language? Well, I guess they =E2=80=9Cuse only one for everything=E2=80=9D :D > The situation is worsened by overloading ASCII Hum, Unicode phobia again. > symbols, which according to Australian studies does not seem > to help newcomers understand source text. At least not me, so I can believe it. > (Which, incidentally, > is an argument against Ada's X(42) meaning both array component > and call.) No, that's not the same, because array access is a kind of function :-P = . = While that said, this would be easy enough to wrap array access in a = function when one want the source to be independent of whether Foo is = defined as an array or a function. This feature is from time to time, ev= en = promoted as a good feature of Ada (array access using the same syntax as= = function invocation) > Concurrency. ATS does address concurreny---with POSIX threads > and such. Well, that's at least something. Or maybe not? I am tempted to say =E2=80=9Cnot as clean as Ada task, probably=E2=80=9D= , that's a good = point to notice about ATS, but this is not really due to the ability of = = the language to hide feature X which is not relevant at stage Y. > ATS appears to be a research work, too. I understand that Haskell is > the outcome of a collaborative effort to create a FPL that would have > desired properties. Maybe ATS work will at some stage be integrated > into some FPL. Hopefully, though, only the ideas will be adopted into= > contemporary programs, not the underlying fundamental types. > How can a safe ATS pointer be safe in the presence of int ? What is the question precisely ? I am not sure I've understood the = question. > In the long run, I don't think it is a good idea to ignore things > as often as it is actually done, and supported. When you say =E2=80=9Cas it is actually done, and supported=E2=80=9D, do= you suggest there = could a good way to do ? > The pattern, > whether employed in language design or in programming, will generate > insecure software and entail costly repair. What about the example precisions I provided above in this message ? -- = =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