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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,103b407e8b68350b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-03 09:59:56 PST Message-ID: <3E15CF31.1020900@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Anybody in US using ADA ? New language competition? (long) References: <3E148004.5000408@cogeco.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 03 Jan 2003 12:58:09 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1041616689 198.96.47.195 (Fri, 03 Jan 2003 12:58:09 EST) NNTP-Posting-Date: Fri, 03 Jan 2003 12:58:09 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:32496 Date: 2003-01-03T12:58:09-05:00 List-Id: Marin David Condic wrote: > Well, Ada's original requirements were targeted towards the embedded world > and for a whole bunch of reasons, it went over like a lead balloon with the > embedded developers. Partly because it initially didn't satisfy those > requirements in practice. (Eventually, it got there but not after having > created a horrible first impression and leaving a bad taste in the mouths of > too many embedded developers.) In its day, I could see why embedded people had concerns (Ada is still a very large "language"). The largeness should not be a concern for general purpose use - GNAT just flies through compiles on my 1.2Ghz laptop. I can only image how fast it is on current technology. The only general fault that I would state about the Ada95 _language_ apart from a few "warts", would be the complexity of some of the rules. But then, I suppose, if you were to implement limited types (for example) in a new language, you'd probably still have those same complex rules under different names/circumstances. The freezing rules are a bit tricky, and some of the visibility aspects are a bit tricky. I also think better could be expected of "representation rules" as well. > I don't think there is anything inherently wrong with the language and there > isn't anything inherently wrong with its original requirements. I would generally support this (with exceptions noted above). > However, if > I was going to write a new set of requirements for Ada (or some new > language) to meet, I'd spend some time talking to the folks who are not > using Ada now and find out what they want most in a programming language. I think we've discussed this before-- the real reason IMHO is the lack of "library support". It is less an issue of the language, but more about the libraries and bindings. Being that Ada95 is different than C/C++, bindings come into just about everything (for both Windows and UNIX) -- speaking non-embedded world wise. Also a lack of a "generally accepted" container library (standard or not), is also a "fracturing component". I myself find the Booch components extremely useful, but many I suppose do not like the complexities of the instantiations required to use them. Is it possible that the generics in the _language_ needs to be researched to make container libraries more elegant? Or are the implementations of these (Booch?) the problem? Or are we too hard on the requirements? > I'd bet (given the history of what is being bought out there) that > development leverage would tip the scales in its favor. "Hey guys! Pay that > initial investment in learning curve and infrastructure development up front > and you'll be building apps in half the time you do now and oh, P.S., > they'll be portable across Windoze, Unix, Linux and Mac too!!!" I think you could eventually sell Ada if the binding/library support was there. If developers could find all the bindings to the O/S, database, GUI and all that other cool Open Sourced set of libraries, then it becomes only a matter of language choice. The reality is that using Ada for general purpose work is still very much an uphill battle on most of these fronts, because the developer must become expert in writing bindings to existing libraries and often O/S facilities. Portability might be enhanced with a _standard_ preprocessor (something like gnatprep). > Reliability, performance, maintainability are all wonderful and desirable > things - but first you've got to deliver! THat is where libraries/bindings would be a great benefit. > Ada's problem is that it has a > history of promising how great its going to be one day, but doesn't > deliver - at least not on time. By this, I mean that it has promised things > like being good for embedded development and then taking years to get > efficient enough to do it and not being targeted to nearly enough embedded > platforms. People went with C because Ada just talked about how great it > would be one day. Embedded systems have their own challenge, because they are very much focused on efficiency with very limited resources. On the GP scene however, I don't believe this needs to be much of a factor. > Same story now for workstation/PC development. One day, if > enough bindings and libraries are built you could develop better GUI apps > that are more reliable. Yes, that's it. > But so what? C++ and/or Java are already there with > their libraries and bindings. Yep, that is the _competition_ then -- the competition is at the library level. > Too bad that "One Day" Ada could do it better. > People are picking their languages and platforms today - not "One Day". If > Ada wants to win, its got to get out in front and lead the way with > more/better leverage *today* rather than "One Day". > Marin David Condic I do believe however, that language/tool choice is becoming increasingly critical in the GP scene. Consider this: 1. Assembly language was the language of choice for operating systems when hardware was slow, clunky in resource strapped. This was so in order to be efficient (mostly), due to limited choice of compiler technology and memory/CPU resources and needs. 2. People started to write O/S in higher level languages: C, Modula-2 etc. There was still a need to be "resource frugal", but the higher level language was decidedly much more reliable, and saved time in development and maintenance. 3. Large software systems like the X-Window software was written in C, because it was available and efficient for the hardware of that time. It is still in C, primarily due to its age and "legacy reasons" 4. About the same time, we have various incarnations of unreliable Microsoft software also being written in C initially, although increasingly in C++. 5. The Internet: with it came the problems of security and virus and hacking threats. Users are sick of Windows unreliability. Also a fork into the foray of java etc. 6. Users/IT is sick of securing against network hacks. Still contending with "instability". Systems of all kinds are getting "huge" and built with an "unstable foundation". 7. Recognition that software reliability requires that the compiler technology must be very rigid. Two alternatives: i) Form a consortium to design a new language/tools. ii) Recognize that Ada95/Ada200y is the best new tool for the job. iii)Fork off another Ada200x variant that is targeted to general purpose work, leaving the embedded systems roots behind. Clean up warts. 8. Build new foundations (O/S etc.) in this/these new language(s). # 4, 5 and 6 remind me of the time when O/S were unstable because of their assembler language roots. Now we have O/S that have some instability due to their C roots (granted a great improvement in some cases over the assembler counterparts). Now its time to move past C into Ada (thinking optimistically...) I like to think optimistically, that we are headed in the 7.ii or 7.iii direction in the near future. We cannot keep buiding humungous systems on unstable foundations. At some point, someone is going to say "scrap the foundation and put something more reliable there, so that we can get _on_ with building on top reliably". How can you build a tower if you have to keep patching the basement? This even applies to the embedded world still -- I can't believe the number of software bugs I have encountered in my Kodak digital camera. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg