Advice on selling Ada to a C shop
in [ADA]
|
From: anon on 6 Jul 2010 07:14 In <avd536h33st9rfce1ld2b4nidcsmeaggv8(a)4ax.com>, David Thompson <dave.thompson2(a)verizon.net> writes: >On Tue, 22 Jun 2010 22:39:51 -0700, Dennis Lee Bieber ><wlfraed(a)ix.netcom.com> wrote: > >> On Tue, 22 Jun 2010 18:01:50 +0000 (UTC), anon(a)anon.org declaimed the >> following in comp.lang.ada: >> >> > A second problem is until Ada 2012, C is the only common used language >> > that allows functions to have "in out" type of parameters. If functions >> > having the "in out" parameters, was a good idea, you would think then >> > other older languages like Fortran, Pascal would have them. Or even >> >> Uhm... The last time I worked FORTRAN (about a decade ago), >> functions COULD have side-effects. After all, the normal passing method >> in FORTRAN is by-reference, and I never encountered a compiler that >> would enforce read-only access to arguments inside a function. Now, >> maybe post '90/'95 standard have implemented such -- but I'd bet most >> shops are still running a compatibility option for older code... > >Indeed. Classic Fortran did, and F90+ still does by default (i.e. >INTENT unspecified) or if you specify INTENT OUTor INOUT. >Only if you explicitly make a subprogram PURE or ELEMENTAL then a >function, but not a subroutine, is prohibited from having modifiable >arguments. (Both a function and subroutine are prohibited from other >'global' side-effects, i.e. on module~package data or external files.) > >So did Pascal if you specify VAR, a68 with ref, and COBOL and PL/I >always. anon may argue that some of those are not now 'common[ly] >used', but Java certainly is and makes all nonprimitive arguments >writable references; there's not even a syntax to make a reference >readonly -- although you can write a target object, or a wrapper or >adapter etc., to be readonly (always or controllably) and some >important standard objects like java.lang.String are immutable. > >And C++ of course, but that's arguably covered under C. It does have >added syntax for references (and OO 'this') but same semantics. > Classic Fortran is Fortran I,Fortran II, Fortran IV. Now with Fortran 77 they introduce the if-then-else structure which start the fall of Fortran. But "Intent" was not a Fortran keywords yet. And with the addition of the keyword "Intent" in Fortran 90/95 and other features, it just hammered the nails in the coffin for Fortran. Most of the major Fortran players have since move on. But now, Adacore and others wants to do the same for Ada. by allowing functions to have or "out" and "in out" as parameter modes. As well as some other features. What people are trying to do is create a PLII or PL2. If people want to create a PLII aka "Programming Language II" then they should start from scratch and create it. And stop trying to add the features of one language they like into an other language, and in the process destroying the beauty of the unmodified original language. Building PLII is not difficult, it start with setting down and make a list of what features one like about each language then adopt common features and then add those features that are desired. But most people who want a type of PLII just think they can modify an existing language and community for that language will accept it. The community as a whole does not accept the changes they just find another language. So, it is time to tell those modifiers that's enough. If you want PLII then create it and leave the other languages like "Ada" alone. If Adacore and others want to modify Ada why not create a new language which base language would be Ada, then they could called new language may be Ada2. And this new language could adopt the new additions, they want to add, and remove some features they dislike about the original Ada. This way they could keep their existing clients that wants the original Ada design without unintentionally destroying the "Ada language" as well as their relationship with existing clients that uses the original Ada. And if Ada2 works then fine, no harm done to either language or their clients, but if Ada2 falls then Adacore has the original Ada and clients to fall back on and still no harm done. Just a little cost for "research and development" which could be a waste or grow into a great value. In other words, if Adacore keep playing this game with adding features of other languages, like C they may find themselves out of bussiness. With the death of the "Ada Language". Note: I started using Ada before Fortran 90 came into existence, and found it to be a better language for my needs than Fortran, C or any other language.
From: Marco on 9 Jul 2010 09:21 On Jul 6, 4:14 am, a...(a)att.net wrote: > What people are trying to do is create a PLII or PL2. If people want to > create a PLII aka "Programming Language II" then they should start from > scratch and create it. And stop trying to add the features of one > language they like into an other language, and in the process destroying > the beauty of the unmodified original language. Building PLII is not > difficult, it start with setting down and make a list of what features > one like about each language then adopt common features and then add > those features that are desired. But most people who want a type of PLII > just think they can modify an existing language and community for that > language will accept it. The community as a whole does not accept the > changes they just find another language. So, it is time to tell those > modifiers that's enough. If you want PLII then create it and leave > the other languages like "Ada" alone. Agreed - it is either a function that returns a value or a procedure that can manipulate state not both
From: Dmitry A. Kazakov on 9 Jul 2010 09:45 On Fri, 9 Jul 2010 06:21:07 -0700 (PDT), Marco wrote: > Agreed - it is either a function that returns a value or a procedure > that can manipulate state not both Function manipulates the state of its result. (Stateless computing is a fiction) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Georg Bauhaus on 9 Jul 2010 10:12 On 09.07.10 15:45, Dmitry A. Kazakov wrote: > On Fri, 9 Jul 2010 06:21:07 -0700 (PDT), Marco wrote: > >> Agreed - it is either a function that returns a value or a procedure >> that can manipulate state not both > > Function manipulates the state of its result. > > (Stateless computing is a fiction) When the word "function" is just not present in a programming language, is there a problem at all? I mean, do people complain? Every terminating procedure does compute a function from input variables and stores the result in some output variables. Correct? Do we want "function"? Or do we want "modifies"?
From: Dmitry A. Kazakov on 9 Jul 2010 11:08
On Fri, 09 Jul 2010 16:12:15 +0200, Georg Bauhaus wrote: > On 09.07.10 15:45, Dmitry A. Kazakov wrote: >> On Fri, 9 Jul 2010 06:21:07 -0700 (PDT), Marco wrote: >> >>> Agreed - it is either a function that returns a value or a procedure >>> that can manipulate state not both >> >> Function manipulates the state of its result. >> >> (Stateless computing is a fiction) > > When the word "function" is just not present in > a programming language, is there a problem at all? > I mean, do people complain? > > Every terminating procedure does compute a function > from input variables and stores the result in some > output variables. Correct? No, because you have no way to denote them as an entity. Function in Ada is a procedure, which allows to denote its dedicated argument called result in a useful way: 1. in a transition context (temporary result) 2. supporting constraint inference (indefinite result) 3. constructing the result out of nothing, as an object, function is "equivalent" to the object it returns, and any object can thought as a function ("functional view"). > Do we want "function"? Or do we want "modifies"? We (I) want to keep the following three issues separated: 1. Syntax of a call 2. Purity of a subprogram 3. Ordering of side effects -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |