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,df1a7f1c3c3bc77e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: An Ada Advice Inquiry References: <463B7BBF.4080603@obry.net> <65gsg4-9si.ln1@newserver.thecreems.com> From: Markus E Leypold Organization: N/A Date: Sat, 05 May 2007 16:07:34 +0200 Message-ID: <2kbqgzwehl.fsf@hod.lan.m-e-leypold.de> User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:9rHHmTU09aN8bNZh6NAW3PEtyEE= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.250.189 X-Trace: news.arcor-ip.de 1178373556 88.72.250.189 (5 May 2007 15:59:16 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news4.google.com!proxad.net!213.200.89.82.MISMATCH!tiscali!newsfeed1.ip.tiscali.net!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: g2news1.google.com comp.lang.ada:15576 Date: 2007-05-05T16:07:34+02:00 List-Id: Jeffrey Creem writes: > Markus E Leypold wrote: > >> Last time I checked they were to expensive to develop an embedded >> appliance with them (in small quantities) and then keep the compiler >> around for 10 years for maintainance (which every sane customer will >> reuqire). AFAIR they still have that minimum 5 seat clause (a bit much >> for the 9 years of maintainance). >> Regards -- Markus >> > > While I agree it is nice to keep maintenance around for that time, > this is probably another example of the different bar people set when > they use Ada. No. not really. If you develop bespoke software, you'll gave to give some amount of maintenance afterwards regardless of the language. For one thing, the customer will demand some commitment how long you'll fix bugs and how long you'll support him when migrating to new versions of his platform (i.e. from Win 2000 to Vista). In most jurisdictions you also cannot avoid to give some kind of warranty (i.e. if the software stops working after some time because there is a bug in the database index handling, you're for it: Fix it, or pay somebody else fixing it for your customers. You can get sued for this). 10 years is an intervall you better plan for and often demanded by customers, because they themselves base products (or production of products) on the software and expect you software to work for the time they are building that product line. Usually the level of (badly paid) maintenance activity will drop some time after deploying the software in question. With many languages just keeping the development infrastructure available is not very expensive. It is with Ada. <...> > In this case, we will tell people they should/must pay for 9 years of > maintenance, which will be too expensive. So, the person will go off, > select (as a contrived example) visual studio 6, not consider > maintenance and end up with a product which will not be supported 2 > years out. Well -- that's why I never would select vs6. I'd select a command line compiler and a traditional make based system for maintenance, because that is much more probable to stay around for some time and because it suffices for re-building the program. Furthermore migrating from one C-compiler to another is not trivial, but it can be done. One should always keep a fallback option (and that also applies to libraries which opens a whole other can of worms). > The whole maintenance thing is largely a sham. I've dealt with a lot > of compiler (multi language) and OS vendors over the years. Sure in I don't care wether it's a sham. What counts, is, how much will it cost to me to have a compiler of that kind on a then-current platform 5 years in the future (like Vista 2012 :-). As an example: - Gcc => will it run on Vista 2012? Certainly. There has been much commitment of that kind in the past and I'll expect it to continue in the future. As an emergency fallback I can always buy a C compiler from MS, Borland or Comeau. - Similar arguments could be made for Java: I've always had the choice of at least 2-3 distributions on every platform. - Gnat => Well -- there is the sad history of the public releases from ACT and then there is FSF Gnat (integrated in Gcc). FSF Gnat has not really taken off in the last 2 years, so there is a risk it will not be around in 2012. The GPL releases from AdaCore are not identical to what they serve to paying customers and seem to be rather more beta. So the only certain choice will be to shell out 1x000 a year. Aonix will not be a fallback, since libraries written for Gnat won't compile with Aonix (GtkAda AFAIR, perhaps that changed). What does look more reliable to you and which choice would incur the most financial risk WRT the costs of maintenance? > plenty of cases I've had bugs that they have solved...But in just > about as many cases, I've either needed to find a workaround or use > either the full source code or source code snippets to fix their > problems for them and then send it back to them so it can appear in a > future version. It always struck me as strange that you have to PAY a product vendor just for being allowed to report them their bugs. > Just about the worst thing you can do if you really care about long > term support is pick any tool that requires some automated method for > license enforcement (dongle, flexlm, etc). 10 years out, you can > pretty much bet that even if the vendor wanted to support you, they > would no longer know how and you can end up with a dead tool. Yes, I know. I (that is, my customer) have already had this kind of experience (and it sucks the more, the cheaper the tool was at the beginning). > If I were spending money and micromanaging a development contractor, > I'd be a lot more interested in making sure they pick a tool suite > that will not fail 100% when the license server dies. > Compiler bugs that pop up after 5 years of service almost certainly > can be worked around...Node locked license servers..maybe not. I completely agree. Still, the development (maintenance) environment also is a moving target, so if the customer comes in 5 years from now and wants a binary that runs on Windows Vista 2012 and the Gnat tasking runtime has this little bug which makes it fail utterly on the massively parallel multicore processors of the next decade (or whatever), what do you do then? Generally speaking, one doesn't need a tool that not only runs in 5 years from now, but a tool which runs on the then-current platforms. Regards -- Markus