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 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!feeder.news-service.com!novso.com!nerim.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 24 Jun 2011 00:17:23 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110613 Thunderbird/3.1.11 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Some exciting new trends in concurrency and software design 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <4e03bb73$0$6584$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 24 Jun 2011 00:17:23 CEST NNTP-Posting-Host: c78b4de1.newsspool3.arcor-online.net X-Trace: DXC=7X@lABA086aPKPPVf;4hUjMcF=Q^Z^V3h4Fo<]lROoRa8kFejVh`5e^Q[KBN:h_=YD8d On 6/23/11 12:57 PM, Yannick Duchêne (Hibou57) wrote: > Le Thu, 23 Jun 2011 12:25:00 +0200, Dmitry A. Kazakov a écrit: >> This is a weak argument. The strong one is that the mathematical numbers >> used in engineering are simply incomputable. The question is not efficiency >> ("how"), it is "if": you cannot represent numbers involved, e.g. real >> numbers. Engineering computations are on the model numbers, where range is >> just one constraint among others. > Was indeed what I wanted to mean (yes, even SML is not able to really express the ideal nature of numbers, and nothing is able to). > >> All programming is actually about constraints, which makes things so hard, >> mathematically, algorithmically and also in terms of types (e.g. LSP >> violation). Ignoring this does not help. > Ignoring things can help. > > There is always some stage where you ignore some one of some other things. Ignoring things is a pattern in programming 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. 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. 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 aspect of a FPL that interests you most.) 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, So they are seen as having potential. 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 not fun, and not very productive: work that is about tackling the things that have been ignored. Such as: - when the framework turns out to be little more than boilerplate text---but otherwise requires detailed knowledge of a vast configuration sublanguage. - when the scripting language is used to process international text in a concurrent environment and fails, since char issues and concurrency have been ignored. - when the program's data model turns out to be relational, but the object-as-a-table magic does not quite work. The workforce then finds themselves trying to reinvent a relational database management system, investing man months ... 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. 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() = begin print_int(4000000000) ; print_newline() end $ ./a.out -294967296 O'Caml appears to be operating at a similar level, if my copy isn't broken: # let i = 4000000000;; val i : int = 4000000000 # i * i;; - : int = -2446744073709551616 # 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 = 4000000000 >>> i * i 16000000000000000000L 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. 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? The situation is worsened by overloading ASCII symbols, which according to Australian studies does not seem to help newcomers understand source text. (Which, incidentally, is an argument against Ada's X(42) meaning both array component and call.) Concurrency. ATS does address concurreny---with POSIX threads and such. Well, that's at least something. Or maybe not? 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 ? 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. The pattern, whether employed in language design or in programming, will generate insecure software and entail costly repair.