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,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-09 17:53:34 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: aek@vib.usr.pu.ru (Alexander Kopilovitch) Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? Date: 9 Sep 2003 17:53:33 -0700 Organization: http://groups.google.com/ Message-ID: References: <9keolvs9tjbbbuv1ndnsr69af7mtddemhk@4ax.com> NNTP-Posting-Host: 213.33.245.29 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1063155214 24231 127.0.0.1 (10 Sep 2003 00:53:34 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 10 Sep 2003 00:53:34 GMT Xref: archiver1.google.com comp.lang.ada:42334 Date: 2003-09-10T00:53:34+00:00 List-Id: Dmitry A. Kazakov wrote: > >Why take all the mess and inefficiency of that JVM? Why not use Ada-to-C > >translation step? As far as I understand, the SofCheck has and can supply > >you that technology/toolset. And you may tell your customers that this is > >simply a great way to achive both goodies in one bottle: good high-level OO > >language for development and maintenance, and at the same time fashionable > >restricted C for deployment on targets. > > They are managers, you know. Sometimes talking with them I am thinking > that all stoies about Martians capturing humans, washing them brains > and then returning them back are true. Managers are those returned! Or > maybe dressed Martians. (:-)) Today they keep on wanting Java. That's > it. Well, even if they are Martians that doesn't matter - why not export our products to Mars, or via Mars? They still will pay in a currency, which is valid here on Earth. And Mars do not pose an immediate threat. Actually, they do not want specifically Java - they want fashionable things, and no more. And furthemore, they want fashionable things just because they consider them as relatively safe things. They are responsible for decisions (or at least for propositions, which may lead to decisions), so they feel themselves liable for future failures. And they know well, that the punishment for a failure probably will be heavier if the decision resulted in the failure somehow deviated from a perceived "industry standard". They know that probably nobody will investigate the details and motives, but instead the manager will be found guilty for failure to maintain the industry standart (or state-of-art). So, a manager will agree to deviate from a fashionable thing only if he thinks that the *weighted" risk for him will be lower with this deviation. Alternatively, you may provide him a solid argumentation (which he find satisfactory for the possible future self-defence) for that you propose is not a deviation, but actually the true industry standard for the case. > Seriosly, one good thing about JVM has is a large library of widgets > and communication protocols. To convince a manager your demo > application should have all that and works on his PDA. Once you get a > contract, you can slowly drag them into the right direction. But only > then. Well, so you, perhaps, should separate application's "front-end" from the application's "engine" in your overall design, and then give that "front-end" to some cheap subcontractors, giving then your specifications *in Ada* (they will quickly learn some Ada for that, because that will be part of their work, and you know that this is not difficult for cheap subcontractors -:), and monitoring them with your QA. Those subcontractors will provide you that "front-end" in Java for demo and prototyping purposes, while you will be free from all that mess. And for those customer's managers you may explain that your technology is a great combination of a solid software engineering methods and technique for fundamental issues of the project and a modern, state-of-art (Java) technology for data communication and data presentation. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia