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: 5b1e799cdb,3ef3e78eacf6f938 X-Google-Attributes: gid5b1e799cdb,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!novia!border2.nntp.dca.giganews.com!nntp.giganews.com!backlog2.nntp.dca.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail NNTP-Posting-Date: Wed, 22 Jul 2009 03:09:20 -0500 From: Jon Harrop Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.modula3,comp.programming Followup-To: comp.lang.eiffel,comp.lang.ada,comp.lang.modula3,comp.programming Date: Wed, 22 Jul 2009 10:18:59 +0100 References: <51617b48-400b-4296-9362-78aa712bb6b2@a7g2000yqk.googlegroups.com> <0bd49fc3-8fae-44ca-93fb-938fabffb892@q11g2000yqi.googlegroups.com> Organization: Flying Frog Consultancy Ltd. User-Agent: KNode/0.10.9 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-ID: X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-RUeiUOER6wo0yBiK0feXli8JRQXMyPWTCk5EtPexQmK1WLu/zjnGnNl5qEQjjHb0Av7jq+gdc3M9H5k!ydMZb4GO7ApleCGBNjLfy3ukDntcEk0lpiX3/EKsAtv5irQD2JQy4LoD779F8Tfhg3nZxNkmWItZ!zfcAjW8AYlgyVZZubkobJvzW X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.39 Xref: g2news2.google.com comp.lang.eiffel:387 comp.lang.ada:7262 comp.lang.modula3:84 comp.programming:11967 Date: 2009-07-22T10:18:59+01:00 List-Id: Martin wrote: > On Jul 21, 5:06 pm, Jon Harrop wrote: >> Martin wrote: >> > On Jul 21, 3:09 pm, Jon Harrop wrote: >> > But I'm afraid it does...20 years ago it didn't. >> >> Not according to John Barnes' "Rationale for Ada 2005": >> >> http://www.adaic.org/standards/05rat/html/Rat-3-4.html > > The first part of this shows how they weren't...read on and it shows > that have been added (anonymous access types) to provide downward > closures (what I took from "first-class lexical closures"). No, it explicitly states that Ada still has only downward closures and not first-class lexical closures. My assertion about Ada was exactly correct: they sacrificed hugely-productive features for embedded apps. >> > Yes, that's right...and they are replacing them with GNU/Linux >> > bozes...you didn't read far enough. >> >> If they are still running on embedded 68k CPUs then it cannot be very >> computationally intensive work by today's standards. They seem to be just >> gathering a not-huge amount of data which is neither interesting nor >> relevant in this context. > > I didn't realise there was a size threshold before something became > "interesting" :-) If the context is high-performance computing then work being done on 68k CPUs today is irrelevant. >> > There's plenty that's modern about Ada - it did multi-core natively >> > and portably long before the current flavour-of-the-month boys came to >> > the party. >> >> Fortran did parallelism before Ada and the current "flavour-of-the-month >> boys" like Cilk and .NET 4 provide modern solutions for parallelism built >> upon wait-free work-stealing concurrent deques that Ada not only does not >> have but cannot even express. > > Yes, their were other pre-Ada concurrent languages - just shows how > modern Ada is! ;-) > > I don't use .NET but there's certainly Ada support for it (A# as it > was called, now available from https://libre.adacore.com/libre/). If > it's built into .NET then I don't see any reason why support couldn't > be added. Does .NET offer different task scheduling policies? Or do > you just 'get what's implemented'? There are 4 tasking policies > already defined in Ada and implementations are free to add others: > > pragma Tasking_Dispatch_Policy > (Wait_Free_Work_Stealing_Concurrent_Deques); > > ...doesn't exactly trip off the tongue but that's it expressed... > > Or if you're refering to the work by Chase & Lev @ Sun, then they > implemented it in C++. As far as I know there is nothing you can > implement in C++ that you can't in Ada (or many other languages) and > visa-versa, so it could be added as an external library (akin to > replacing the built in language 'task' keyword with library calls as > you do when using an ARINC-653 supporting OS). Atomic intrinsics are an obvious counter example. >> > The one thing that is missing is lambda support but that doesn't >> > bother me to much given the sort of domains I work in. I think I heard >> > it was being considered for the next language revision. >> >> What do you mean by "lambda support" if not first-class lexical closures? > > Ada only supports downward closures not full blown lambda expressions > or functions - that really is the domain of the functional languages > (or TMP). > > I can't write unnamed functions, e.g. classic C++ Boost example: > > for_each(a.begin(), a.end(), std::cout << _1 << ' '); > ^^^^^^^^^^^^^^^^^^^^^^ > unnamed function > > I'd have to wrap that in a function in Ada to a pass that (named) > function. I can't return an unnamed function in Ada either. It's just > downwards. But that's a whole lot more that the original Ada83 spec, > which expected you to use generic (template) functions instead. Do- > able but a lot more effort. > > I believe there is work on adding some sort of unnamed function > support to a future language revision. So Ada not only lacks first-class lexical closures but it doesn't even have anonymous functions. Even C# has both of those features now. >> >> "the right choice for courses in elementary programming" >> >> > Nothing wrong with that - it's also very well suited to intermediate >> > and advanced programming. >> >> In the embedded space, perhaps. > > Not just embedded - it's a general purpose language but it certainly > isn't functional. Right. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?u