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,23c0de5a42cf667e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news4.google.com!feeder.news-service.com!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 04 Jun 2010 19:34:59 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GNAT packages in Linux distributions References: <16bz9kvbqa8y9$.155ntpwpwl29d.dlg@40tude.net> <4be97bea$0$2966$ba4acef3@reader.news.orange.fr> <1p87qdlnjbufg.127laayhrw9x3$.dlg@40tude.net> <4j73xhgimt6r$.pu55kne2p2w5$.dlg@40tude.net> <4c09047d$0$6976$9b4e6d93@newsspool4.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID: <4c093944$0$6992$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 04 Jun 2010 19:35:00 CEST NNTP-Posting-Host: 2e6c78d6.newsspool4.arcor-online.net X-Trace: DXC=On5>lf^]Sg>d8Nb@@ZG@b=4IUK:Lh>_cHTX3j=hV7`gSK[6m9 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:12257 Date: 2010-06-04T19:35:00+02:00 List-Id: On 04.06.10 16:24, Yannick Duchêne (Hibou57) wrote: > Le Fri, 04 Jun 2010 15:49:49 +0200, Georg Bauhaus > a écrit: >> Coding invariables makes me think of a tricky(?) question: >> What should a language look like that naturally makes the programmer >> think before coding, and take his/her time? What would its >> features and offerings have to be? > Undoubtedly, I would think to start with a VDM like (whose theory I know > a bit, however never practiced, sorry) > > I don't mean Ada is not nice for that (it has many things which suggest > you to think about the logic and structure of things before to start, > and SPARK completes it has it give logic), I just mean this has some > additional things, which make it mandatory (based on what I read about > it some 15 years ago). > > Do you agree with that idea ? I guess VDM or Z or B means contracts for module interfaces. These work mostly at the level of type construction and associated subprogram profiles. What I have in mind is programmers answering "system design questions" on the one hand versus language support on the other hand. Here is a question: "What typical collection of types/modules would I have to use, and in which way, in order to have a system that performs this or that use case?" Surely, answering this question involves entities whose specific properties are, maybe, programmed in some programming language. But they are not "naturally expressed" in the programming language, there are no "intrinsics" to express system design ("architecture"). You think about module relations. You think about usage patterns. Is there a formalism for such relations that is not some variation of UML? I think that, yes, there is, or might be: I vaguely remember work by David C. Luckham (the name that is associated with the ANNA annotations language) about architecture and a formalism for it. For example, one could start from the observation that novel web based application design forces certain construction principles. These are not directly expressible in any language available for programming in such an environment. (I don't know any such language, that is.) I'm picking Google App Engine as one example of a different computer model: (1) Stop using files for storage. (Google data store, AWS S3 (that's Amazon Web Services), WebDAV, HTML5, or whatever; all without "file pointers", and no streams.) (2) you must process your data not at once but in steps so that Google's quota system and web request processing logic is satisfied. Google App Engine is different, as an operating system. Programming in this environment means - writing request handlers as you "normally" would. But they must do little or else they will be killed - writing request handlers to be added to task queues (task in the non-Ada sense) for background processing, to be called by the GAE's queuing system, and - writing request handlers to be run as cron jobs; these are web requests initiated by the GAE environment at specified times, or else N times per period. Note: all request processing is subject to quota, so you had better design your program following these restrictions (no large chunks). Right now, to establish a "program" in Google App Engine, you use - programming languages Python or Java, - a set of libraries, - configuration scripts, and notably - recommendations and *conventions* layed out in the documentation. It feels like you have to *emulate* the "real language", a language that has words and symbols for the computer model that Google App Engine establishes. But you can only follow the GAE rules. The programming language has no constructs to help you *specifically*. Couldn't there be an expressive formalism that better addresses the issues? > I did not understood this sentence: “Eiffel's syntax appears to be > expanding ...” > What you were you to mean ? It looks like keywords keep being added to Eiffel, for example in the context of iterators. Like Ada's for loop would get syntax to make Has_Element/Element/Next automatic. >> Maybe some Cobol style modules headers listing major internal >> and external parts to be manipulated might help? > Can you give a short example of what it would look like for ones who > don't know COBOL ? My knowledge of Cobol is close to non-existent, but I know that a Cobol program has divisions, Identification Division. ... Environment Division. ... Data Division. ... Procedure Division. ... And there is an "input-output section" in the "Environment Division". This is where you talk about files that your program is going to use. To me, this is a vast improvement over scanning a source tree for possible I/O related fragments. > Are you to complete your list of thoughts about programming languages in > the large ? (I remember you talked about it if I'm not wrong) A complete list? A complete list would be quite an achievement ... ;-) But I am collecting thoughts and, fortunately, I'm not alone. For example, researchers have consistently identified properties of programming language properties that help majorities of programmers (students) get their programs right. Typically they have used some approximation to controlled teaching experiment. Things that don't help: + Overly complicated or strange syntax. + Syntax abstracting away the differences (The expression A(X) has even more meanings in Turing than it has in Ada, wiping out the possibility of understanding what is meant, just by looking at an expression. This finding is at odds with the purpose for which Turing was intended, IIUC!) + Absurdly unhelpful error messages caused by e.g. the "run-away properties" of a language's grammar. (Syntax error at end of file... template spit... Hm. I still have to complain about GNAT's wording, telling me that S : String may assume lower bound of one in expression S(1)...) + Lack of subsetting the language. This means that meaningless compiler messages cannot be avoided when translating a subset; you don't know yet what they mean when you have mistakenly used some advanced language concept. (Turn on Ravenscar and you see "not supported when Ravenscar profile is in effect" or similar for certain constructs. PLT Scheme has teach packs restricting the language similar to Ada profiles.)