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,e7151167e0767ecc X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!newsfeed.stueberl.de!feed.news.tiscali.de!news.belwue.de!LF.net!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: Feasibility of using Ada in new development Date: Tue, 24 Aug 2004 02:06:00 +0200 Message-ID: <871xhx4cyf.fsf@deneb.enyo.de> References: <8429999a.0408231027.2850e800@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: codeneb.enyo.de 1093306355 7121 212.9.189.171 (24 Aug 2004 00:12:35 GMT) X-Complaints-To: Cancel-Lock: sha1:/h3OKQEDKMkT9yXkrCCVHj4ju7g= Xref: g2news1.google.com comp.lang.ada:2946 Date: 2004-08-24T02:06:00+02:00 List-Id: * Robert Law: > I would like to start by saying my message is not an attempt to start > a flame war or anything like that. At least when I was still reading every message, comp.lang.ada is unusually civil and not too snobby (unlike some other groups in the comp.lang.* hierarchy). > I've been programming for years using everything from COBOL, RPG, C, > Java, PHP, etc. I've written a number of business applications, > usually accounting ones. (That's the advantage of having more than > twenty years of experience.) I'm at the point in my life where I want > to pursue a dream I've had for years of having my own software > development company, basically a VAR or ISV. I have to admit that I have much less experience, and I've never been a full-time programmer/designer/software engineer, and I still consider myself an ambitious amateur. > I want to use a language that meets the following criteria: > > 1. It must be reliable. Reliable in what sense? There are several things that can make a language unreliable: - The language has lots of unsafe features that are very closely related to common operations (think of C pointer arithmetic and string processing). - The language changes a lot, sometimes in incompatible ways. There are several popular examples, but you won't name any. - The standard run-time support library (if it can be separate from the library) can have similar problems. - There are no high-quality implementations available. - The language actively encourages bad style and is bad at dealing with program complexity. Large programs tend to fail apart. - It's impossible to get formal certification for software implemented in it, for whatever reason. - The language deeply affects programmers and their ability to interact with other programmers (particularly those using different languages) and non-programmers I don't think Ada has any of these flaws, and GNAT is stable at the source code level (the ABI is still a bit in flux). > 2. It must be supported. > 3. It must be usuable to develop applications in a graphical > environment. Basically Motif, GTK, or KDE. I can't really comment on these two. GNAT is supported, obviously, but the support offerings are mainly useful to larger companies with an Ada development team. My personal rule, after some experimentation, is that there must be a GCC front end maintained in the official GCC repository. Anything else is just too painful. It's possible to write Gtk applications using GNAT, but I generally view GUI work as painful and haven't found very early versions of GtkAda the definite improvement. > 4. It must be usuable to develop programs used via a browser. Certainly possible, via the CGI interface. There's also a complete Ada web server that you can embed into your application, but I haven't used it. > 5. It must be able to interface with relational databases either > through a standard interface or ODBC. I've done some work using GNAT and PostgreSQL. The nice thing about Ada is that you can define a new string type for SQL statements. This way, you can discourage manual construction of SQL statements, which should prevent SQL injection attacks. (You'd need a static code checker, implemented using ASIS, to make this really foolproof, though. ASIS is a standardized interface to compiler representations of Ada programs.) > 6. It would be nice if it was somewhat object oriented. I'm not an > object oriented purist, but it does have some nice features. I > especially like its automatic garbage collection of no lonter used > variable. Unfortunately, garbage collection is a bit of a stepchild in the Ada camp. Ada, as a language, is quite good at supporting garbage collection, especially if you don't use machine addresses directly and avoid certain language features which require that objects are destroyed at certain point, potentially much later than the last reference to the object vanished. There are some kludges to use the Boehm-Demers-Weiser conservative collector, but I've got a hunch that there are many unresolved issues (with tasking, for example, or with objects that are always reachable during the program's lifetime because GNAT explicitly adds pointers to be able to finalize them at program termination). Furthermore, this collector discards (almost) all type information, so it's far more inefficient than it needs to me. OTOH, it's doubtful that you can beat it with a custom-written collector which hasn't been fine-tuned over the years. 8-) >From a reliability perspective, even somewhat inefficient garbage collection is hard to dismiss (of course, only if you aren't doing real-time work). But nevertheless, there isn't any demand for garbage collection from commercial Ada users (at least that's what the compiler vendors say, and they should know). > I do want it to be a language that is efficient yet doesn't give you a > rope with a noose or a loaded, cocked, gun when you use it. > > You can see that I'm leary of C and C++. I have used them, and > continue to use them, but I'm not at all sure that I want to use them > to develop business applicatons. I'm tired of reading about buffer > overflows. During the past 12 months, I've written about 15,000 lines of C++ code (as I said above, I'm not a full-time programmer), and now I regret bitterly that I haven't written them in Ada. The risk of buffer overflow bugs is quite real, and although I tried to isolate all the risky marshaling operations, I wasn't completely successful at that. The marshaling library (actually, there are two of them, one design is somewhat flawed) also contained one or two bugs which prevented it from getting the compile-time overflow/underflow checking right. It was fun to write the programs, but it gives me an uneasy feeling, partly because the code is not really maintainable (I'm not sure how many C++ programmers deal with that level of template meta-programming on a daily basis), but mostly because it's so hard to tell if it's really safe to use it in a hostile Internet environment. After that experience, I'm looking at other options besides C++. The "scripting languages" are out of the game because some of the applications involve IP packet processing in (soft) real time. They also perform quite a bit of bit fiddling, which results in an unusually large performance hit when switching to scripting languages. I benchmarked partial implementations and the results weren't too encouraging. Then there's Lisp. I actually wrote something non-trivial that did work, but I found support from the free implementations for programming in the large rather weak, even with my limited code base. You can probably cope with that when you are guided by an experienced Lisp programmer, but I'm not that lucky. Furthermore, decent performance at bit fiddling means that you have sacrifice run-time checks, which means that your code isn't that much safer than C++ code. (I like Emacs Lisp a lot, though, and it's really good as a rapid prototyping environment.) And Java. Well, the GNU Java implementation always seems to be one "year" behind (or whatever you want to call Sun's Java technology cycle), because the language and in particular the run-time environment keep changing. In my experiments, I quickly ran into compiler and run-time library misfeatures. This is a bit disappointing because I don't want to bet the future of my source code on Sun's generosity. Writing Java programs turned into an exercise in twos complement arithmetic. I really doubt that the resulting code is maintainable. However, there are some very nice development tools for Java, and there is a rich selection of rather well-documented libraries. C# is too young to be sure. There doesn't seem to be a traditional development environment with native code generation, and the Mono project doesn't aim for it. At least C# has unsigned types. Programming in it probably doesn't give you the feeling that you should rather use the language to control washing machines, or describe business logic at a suitable level. As a result, I'm back to Ada. I've written some Ada code before, so what drove me away from Ada? I think the main points were: - It's hard to find industrial-strength libraries for basic building blocks. - There are bindings to many C libraries, but the quality of the bindings varies a lot. Many important libraries still lack bindings, too. - There's the reimplementation trap. Something isn't right unless it's implemented in Ada, so you end up reimplementing C libraries which are actually quite usable as is (through a binding). - Writing Ada code is often a mechanical task, at least compared to C++ (template meta-programming! yay!). This is especially true if you have to create a lot of bindings. - There's no garbage collection support. With my programming style, I can't avoid the dangerously-looking UNCHECKED_DEALLOCATION. - There is no de-facto standard for a container library. Thanks to Ada's built-in array type, things aren't completely hopeless, and there is usually some compatibility between different libraries. However, a standard container library is in development, it looks promising. - Perceived productivity is much, much lower. I should have done actual measurements which include debugging time (I chased few very nasty bugs in C++ code, some of the directly related to C++'s shortcomings), but without that, there's just the subjective feeling that I was more creative when I wrote C++ code. I hope that I've learned something in the meantime and that I'm old enough avoid most of these mistakes by now. Hmm, my message paints Ada as the best possible choice, more or less -- all others are either impossible like Java or just worse. But this is only part of the truth. For someone like me who doesn't implement GUIs at all, the GNAT environment with its Emacs support easily beats anything that is available for other programming languages on the GNU platform (Eclipse being the only possible exception, but it's still tied to some extent to Sun's proprietary Java implementation, so it doesn't count fully). I don't know of any other development environment that offers precise and complete cross-reference information from within the editor, even for homographs. Once set up correctly, it's easy to jump to definitions, find all references to a specific record field (and there are no false hits of subprograms that have the same name). GNAT's error messages that occur in practice are very easily understood (with a few exceptions, but you can use Google for them). When written in the GNAT/Ada Reference Manual style, Ada programs look very clean, and they don't leave a bad taste in my mouth (admittedly, some of my C++ code does, unfortunately). Hopefully, the experience that C++ does offer shortcuts, but that these shortcuts come at a price, was just what I needed. 8-) > I have played around somewhat with Ada but by no means am I an expert. > I'm concerned that Ada may be starting to fade into obscurity. If I > get my company going (I know its a BIG if), I want to use the language > for years and not chase after every silver bullet that comes along. Ada has already faded into obscurity, so it can't get much worse. Most companies also offering Ada development technology already have other priorities, except AdaCore of course. I strongly believe that GNAT will be around for the next decades, like other GCC technology. Quite a few large companies have significant interest in a maintained GNAT version. The only thing that might happen is that Ada is adopted in the free software community on a larger scale, but that's not very likely. But even the current, small community manages to continuously grow the pool of freely available high-quality Ada libraries, so this shouldn't bother you. (Bit rot of Ada libraries that do not interface directly with operating systems is rather low anyway, much lower than C++ at least.) I'm not sure if my post was helpful to you. I have to admit I wrote it mainly for myself, so that I might have a look at it in a year or two and see if my expectations were met. 8-)