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 Newsgroups: comp.lang.ada Subject: Re: How come Ada isn't more popular? References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> From: Markus E Leypold Organization: N/A Date: Sun, 28 Jan 2007 00:24:27 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:an4w0I0degZA31VXRVQYz1mFDUI= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.252.37 X-Trace: news.arcor-ip.de 1169939982 88.72.252.37 (28 Jan 2007 00:19:42 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:8636 Date: 2007-01-28T00:24:27+01:00 List-Id: Charles D Hixson writes: > Markus E Leypold wrote: >> Charles D Hixson writes: >> >>> goes on. I, personally, think that one factor IS the lack of a >>> standard garbage collector. Related to this is the awkwardness of >>> dealing with strings of varying lengths. >> Actually that is rather good compared to C or C++. The different >> string package s make it possible to often use stack allocated storage >> only or get the comfort of unbounded strings. After a while I really >> started to like this. >> > Note that "After a while"? Yes. I couldn't decide at first when better to use Fixed and when Unbounded strings. The problem got aggravated by my attempts to stay minimalist and use fixed string where ever possible and also where impossible. The insight that some algorithms are better not performed with bounded buffers took a while to take hold. > The first hour, the first day, the first week, and the first month > are the most important for forming lasting impressions. Yes, but it's not the "impressions" that count. I came from Pascal background (after learning programming in BASIC and assembler) and looking at Ada was love at the first glance -- as far as languages of that family go. I often thought: Wow, there is a design decision where everything has done right after a lot of thinking and not decided in an ad hoc fashion. I hope I'm not limited to my first expressions, though. > I still remember the extreme frustration I experienced the first > time I tried to print a string...it was an unbounded string, and I > hadn't used Ada.Text_IO.Unbounded...and I didn't have anyone I could > ask "What does that silly error message MEAN!?!?" :-). Fun, yes. The error messages of GNAT(e.g.) are sometimes less than helpful. Fortunately I always had my copy of Barnes' book with me and from C/C++/SML etc I learned to compile often and morph programs through syntactically correct intermediate stages. So that couldn't trip me up too much :-). > It's easier to do simple things in Fortran, C, Pascal, Modula II, PL/I > or even Snobol. Oh, yes, and BASIC, too. (The other current It's easier to do simple things with languages that have lists in them. E.g. Lisp or Scheme (or Python for today programmers). No, I disagree: It's not even easy to do simple things in C: Every time I'm astounded by the contortions I've to go through for anything involving strings of varying length (OK, I can work in large statically allocated buffer, but this simply stinks, since it imposes arbitrary limits). And very soon the wish comes up not to have to write out specialized list processing code every time for 'list of ints', 'list of floats', 'list of strings', 'list of lists of strings', 'list of trees' etc -- and than you start to suffer and it never ends. There is no way to write generics in C, to fake them or even graft them onto the language as an afterthought and use a precompiler or a preprocessor (I'm perhaps exaggerating here, but the pain is there nonetheless. I've written those things (a generics "expander" for C :-) and I think/hope I know about what I'm talking here). > contenders weren't around then, I never learned Cobol, and it isn't > easier in any assembler I ever learned.) Well, that what all my recent posts to this group try to assert: That there are languages beyond assembler (including C) and the pascalish family (including Ada). Of course I'm posting to c.l.a. so I know that this might develop into flame bait. But it wasn't me, starting to bash C (It was J R Carter :-), and when we start to discuss the respective merits and dis-merits of various languages than we can as well go the whole way and accept the fact that development has not stopped with imperative compiled languages. I'm also pining for the days when I almost understood everything the compiler did and there was no VM and no JIT and no whatever-optimization. If you're a control freak like me, you just feel better if you understand everything at least in principle and can say things like "this statement/call expands to the following instruction sequence but ..., so if you compare you can ..." and if you can -- in principle -- recreate your own tools (which is of course an illusion). But those days are long gone and, if I think about it for a moment, good riddance. Give me a modern functional languages with lot's of complicated types and katamorphisms every day. I finally want to get things done -- and I suggest to compare e.g. haskell.org or Jon Harrop's demo source for OCaml with the list of "free projects" on the ACT site (or where ever ...) and moreover the scope of ambition of those projects and I'm starting to anticipate what an expressive language can be. Let me put it like that: Trees and graphs are fundamental models in computer science, mathematics and finally document processing (XML ...). An expressive language supports to manipulate those easily without much ado, without wrapping objects or iterators or factory patterns around a simple concept, without the need for explicit memory management, preferably by recursive functions which are the natural form of expressing a transformation of those structure. How does Ada stand there? How does C? Both bad. Fixing the argument (Why/where does Ada fail?) on C vs. Ada misses an important point. Both languages are relatively good in shoveling bits from one place (bus, memory, ports, interfaces) to another and doing not too complicated things to those bits. But that is not where the real interesting things happen these days. Say, in example, "scene graph". Can you feel the complexity :-)? Do you want to maintain it with explicit pointers and memory management in an imperative fashion? I don't. But whatever - YMMV (that applies to everyone on c.l.a. :-) Regards -- Markus