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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,447bd1cf7a88c198 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-11 12:24:04 PST Path: supernews.google.com!sn-xit-03!supernews.com!freenix!proxad.net!nerim.net!codeine.org!diablo.netcom.net.uk!netcom.net.uk!cpk-news-hub1.bbnplanet.com!news.gtei.net!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: mark_lundquist@my-deja.com Newsgroups: comp.lang.ada Subject: Re: Do we need "Mission-Critical" software? Was: What to Do? Date: Thu, 11 Jan 2001 20:11:21 GMT Organization: Deja.com Message-ID: <93l410$mt6$1@nnrp1.deja.com> References: <3A4F5A4A.9ABA2C4F@chicagonet.net> <3A4F759E.A7D63F3F@netwood.net> <3A50ABDF.3A8F6C0D@acm.org> <92qdnn$jfg$1@news.huji.ac.il> <3A50C371.8B7B871@home.com> <3A51EC04.91353CE7@uol.com.br> <3A529C97.2CA4777F@home.com> <3A53CB9E.EA7CF86C@uol.com.br> <3A5466DE.811D43A5@acm.org> <932aol$ikc$1@nnrp1.deja.com> <932mi6$r2k$1@trog.dera.gov.uk> NNTP-Posting-Host: 130.213.203.244 X-Article-Creation-Date: Thu Jan 11 20:11:21 2001 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) X-Http-Proxy: 1.1 x58.deja.com:80 (Squid/1.1.22) for client 130.213.203.244 X-MyDeja-Info: XMYDJUIDmark_lundquist Xref: supernews.google.com comp.lang.ada:3923 Date: 2001-01-11T20:11:21+00:00 List-Id: In article <932mi6$r2k$1@trog.dera.gov.uk>, "Kevin Rigotti" wrote: > Much as it pains me to say so, Ada is not always the most appropriate > language. > > For example, however good the bindings, toolsets, etc that are available it > is simply easier and more convenient to write X Windows user interfaces in > C/C++ because that's what the designers expected you to do. Does it follow because "the designers expected" you to code in C for X, that it is therefore "easier and more convenient" to do so, "however good the bindings... etc."? That's not at all obvious to me. Am I missing something? Is your statement based on actual experience with Ada bindings to X? And even so, "easier and more convenient to write" is not the only criterion of fitness, would you not agree? Probably not even the most important criterion... > Bindings and support for Gtk are a good thing, but at the end of the day > what I and others in a similar situation really want to do is to build the > clever stuff in Ada then hand it over for integration with someone elses > GUI, produced using whatever is cheapest and easiest. Your statement here suggests to me that you just are not interested in GUIs or GUI programming! You care about "the clever stuff" :-) You haven't substantiated your claim that programming GUIs in C/C++ is "cheapest and easiest". You're just saying, "Who cares, it's only the GUI -- just so long as I get to write my clever stuff in Ada", right? Fair enough, but then how about leaving the discussion of Ada GUI bindings to people who _do_ care about writing them? To offer something you don't give a rip about as an example of an area where you would yield to the idea of Ada being less suitable than other languages seems a bit disingenuous... :-) > > I don't care if the trivial stuff is written in C, C++, Java or anything > else There's a sense in which GUIs might be considered "trivial", but that sense isn't particularly relevant to the discussion at hand. GUIs are neither unimportant to the product, nor are they especially easy to program. Here again, I suspect that by the word "trivial" you mean that they are uninteresting to you personally... Last year I delivered a project in C. This was a software licensing component that wrapped an interface to a commercial license-management product and added additional semantics (while hiding unnecessary features of that interface). This was in many ways a trivial project. Because of the nature of the project, how and where and by whom the component was going to be integrated etc., I wasn't able to implement it in Ada. But man, did I wish that I could! It really would have been quicker, easier, and more convenient, in spite of the fact that the designers of that commercial licensing product certainly do "expect" you to code to their C interface. Note that my real-life example confirms your broader point -- that sometimes Ada is not the most suitable language -- but falsifies the notion that this has anything to do with ease and convenience of coding. Hence I would expect that I would probably say the class of cases where Ada is less suitable is probably smaller than you would probably say it is. On a side note -- I originally implemented this licensing component in C++, but the integration issues due to platform differences and compiler version dependencies in a multiplatform, shared-library environment made this impossible, as far as I could determine. So I had to reimplement it in C, ripping out all the STL and hand-coding the collection stuff, etc. > but I do care about integration costs, particularly if they are so > painful that I have to implement experiment critical code in a language I > consider inappropriate in order to reduce them. Aren't you letting the tail wag the dog? You're saying that the ability to integrate "seamlessly" from Ada to C/C++ is crucially important, otherwise you might be forced to implement your "clever stuff" in C/C++ just so you can avoid the cost of cross-language interfacing to integrate with the "trivial" part, which somehow can only be implemented in C/C++. If it's so trivial, why would it be so unreasonable to implement it in Ada, especially if you already have a binding that hides the cross-language level of integration from you to begin with? > > So, the thing that would make the biggest impact on the uptake of Ada in my > environment at the moment is being able to mix and match Ada with C++ > seamlessly, using whichever fitted the problem most cost effectively. > I'm betting that cultural and organizational factors have more to do with your situation than you are letting on, as much or more so than do technical factors... whaddya say? > [...] > > We could then use the youngest, cheapest staff for the C++ hacking You seriously have part of your product that is so unimportant that it can be fully entrusted to young cheap C++ hacking? I find that hard to believe... > and when > they'd had time to learn what real software engineering was all about they > could move on to doing the important stuff in Ada. C++ hacking leaves no time for learning what real software engineering is all about :-) All time is consumed with chasing down link-time errors and debugging run-time errors. Meanwhile it conditions programmers to think that nonsense is normal... Anyway Kevin, I think your perspective is a little bit sick and twisted :-) :-) First, the idea that parts of the programming product are unimportant, and secondly the idea that C(++) is "good enough" for the unimportant parts, while somehow it's not good enough for your important parts! Best regards, -- mark Sent via Deja.com http://www.deja.com/