GNAT packages in Linux distributions
in [ADA]
|
From: Yannick Duchêne (Hibou57) on 4 Jun 2010 10:24 Le Fri, 04 Jun 2010 15:49:49 +0200, Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> 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 ? My advocating: it starts with high level expressions [*], which are not even compilable (don't even think about such a word as âcodingâ in this context). Then you go down to implementation step by step, and each step has to be proved (the kind of proof it uses is comparable in some way to the ones of SPARK). There is no other road than, first, know what you want (very important), then, know why it can be implemented this/that way (requirement: intuitions, as with any logic/mathematical proof). [*] Please, don't tell me UML do the same, although it may be nice for communication (another area). > One inescapable ingredient of any popular PL seems to be magic at the > level of syntax, if this is how programmers most visibly see themselves > express themselves. Can't force them to wear boring ties. Eiffel's > syntax appears to be expanding ... I did not understood this sentence: âEiffel's syntax appears to be expanding ...â What you were you to mean ? > 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 ? 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) -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: (see below) on 4 Jun 2010 11:29 On 04/06/2010 14:49, in article 4c09047d$0$6976$9b4e6d93(a)newsspool4.arcor-online.net, "Georg Bauhaus" <rm.dash-bauhaus(a)futureapps.de> wrote: > On 03.06.10 15:49, (see below) wrote: >> On 03/06/2010 04:16, in article op.vdpfdcgoxmjfy8(a)garhos, "Yannick Duch�ne >> (Hibou57)" <yannick_duchene(a)yahoo.fr> wrote: >> >>> Le Thu, 27 May 2010 17:21:57 +0200, (see below) >>> <yaldnif.w(a)blueyonder.co.uk> a �crit: >>>> My experience is that CS/SE students always focus on "coding" at the >>>> expense >>>> of problem analysis, program design, project planning, verification, >>>> validation, documentation, and anything else they find less congenial. >>> I always though this was not so much with these students. So why do they >>> choose it if they are not aware of what it requires ? >> >> They are aware. That makes no difference. > > 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? I don't think this has anything to do with PL design. It is to do with competence, and a professional attitude. Programmers who possess those qualities work well, even in C. -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: Georg Bauhaus on 4 Jun 2010 13:34
On 04.06.10 16:24, Yannick Duchêne (Hibou57) wrote: > Le Fri, 04 Jun 2010 15:49:49 +0200, Georg Bauhaus > <rm.dash-bauhaus(a)futureapps.de> 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.) |