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: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: in defense of GC From: Georg Bauhaus In-Reply-To: <1ktzxxuhm4.fsf@hod.lan.m-e-leypold.de> References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> <1mahvxskejxe1$.tx7bjdqyo2oj$.dlg@40tude.net> <2tfy9vgph3.fsf@hod.lan.m-e-leypold.de> <1g7m33bys8v4p.6p9cpsh3k031$.dlg@40tude.net> <14hm72xd3b0bq$.axktv523vay8$.dlg@40tude.net> <4zwt33xm4b.fsf@hod.lan.m-e-leypold.de> <1j7neot6h1udi$.14vp2aos6z9l8.dlg@40tude.net> <1170838486.7656.7.camel@localhost.localdomain> <1170891160.30084.116.camel@localhost> <1ktzxxuhm4.fsf@hod.lan.m-e-leypold.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: # Message-ID: <1171033688.5352.89.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Date: Fri, 09 Feb 2007 16:08:08 +0100 NNTP-Posting-Date: 09 Feb 2007 16:07:51 CET NNTP-Posting-Host: 2d66c07a.newsspool1.arcor-online.net X-Trace: DXC=4 On Thu, 2007-02-08 at 10:24 +0100, Markus E Leypold wrote: > Georg Bauhaus writes: > > > How will a piece of source code, your own or someone else's, and > > a language with tools fit these and the market as we might think > > it is now? > > It will depend on the ability of mine or someone else to code in this > unnamed language with arbitrary tools. Note that I doubt that "we > think" the same about the market and what counts -- finally -- is how > the market is, not how we think about it, which might be a different > thing altogether. > > Does that answer satisfy you? No? I thought so. Yes, it does! And more or less uncertainty about causes and effects of PLs in production use is the only common base we have for making decisions, right or wrong. Partial knowledge is all we will ever have, still it is something to build on. Nevertheless, this is where *Ada* started, AFAIKT: Some of the effects of using more than 400 PLs in one large organization were pretty well diagnosed. A catalogue of desirable PL properties was drafted, and reviewed. Looking at the outcome, my conclusion is that this large research effort did suggest answers to some of the questions of this co-thread about redundancy, explicit typing, or robust syntax (To see highly sensitive syntax typical of the Bell labs tradition ;-), try struct s { int a; } int main() { struct s x; return 0; } > Well, things have changed, but you're probably missing how. > George, you're not trying to find out things, but to win. At, I might > say, every price. I'm only trying to draw attention to some findings when programming is observed as caused by programmers using programming languages. This includes findings about old and new languages. [*] Any findings are important because they can affect decisions. As a consequence of these, they will potentially affect the amount of money spent, the technical qualities of solutions and the time needed to produce. I'm trying to allude to data to again be placed in a frame of reference for language design decisions. But I understand you are convinced that OCaml, if you let me name it as a representative of a few things, answers many of the questions best. So do I, to some extent. Yet, if conviction is all there is, then indeed we loose the common ground for a discussion. [*] Comparing, say, Ada and Haskell wrt understandability, neither is intuitive enough for my taste, though not always for the same reasons. Some language properties are hidden away, even when they are useful, or important to know for runtime behavior. - Like Ada tagged types being aliased therefore you can have 'Unchecked_Access to function parameters... - Like the Haskell expressions sum [1 .. n] or foldr (+) 0 [1 .. n] should almost certainly be rewritten. The programmer has to find out why and how. Yet, the first expression is so nice and straight forward and reflects almost exactly what Hughes has suggested in 1984...