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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d4bbf45291b13fd3,start X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!proxad.net!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Robert C. Leif" Newsgroups: comp.lang.ada Subject: RE: comp.lang.ada Digest, Vol 19, Issue 114 Date: Thu, 17 Mar 2005 18:55:52 -0800 Organization: Newport Instruments Message-ID: Reply-To: rleif@rleif.com NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: melchior.cuivre.fr.eu.org 1111114623 58515 212.85.156.195 (18 Mar 2005 02:57:03 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Fri, 18 Mar 2005 02:57:03 +0000 (UTC) To: Return-Path: X-Authenticated-User: rleif.rleif.com X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050317195052.495E54C412F@lovelace.ada-france.org> Thread-Index: AcUrKvIUoNaAAtVJRry6cYLMZTg3fwAL0aRw X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: g2news1.google.com comp.lang.ada:9578 Date: 2005-03-17T18:55:52-08:00 Although in principle these additions would be useful, the simulation capability should be separated from the mathematical capacity. Ada should stop being based on glass-typewriters! The new front end should be XML including MathML. Ada sources would be in XHTML-strict. Ada should be able to parse expressions written in MathML. Simulation could then be added to this with outputs in scalable vector graphics (SVG). This would result in a language with some SEX-Appeal. Bob Leif ------------------------------------------------- Message: 1 Date: Thu, 17 Mar 2005 16:35:10 +0100 From: "Dmitry A. Kazakov" Subject: Re: NOACE- End of the road for Ada? To: comp.lang.ada@ada-france.org Message-ID: <1wuefxdhphvq5.1te56e3jttqln.dlg@40tude.net> Content-Type: text/plain; charset="us-ascii" On Thu, 17 Mar 2005 13:25:25 GMT, Marin David Condic wrote: > adaworks@sbcglobal.net wrote: >> >> >> It would be really cool to have a standard interface between Ada and >> Matlab. >> > Probably, but it would be even MORE cool if there was an entire Ada > equivalent of Matlab, et alia. The whole bundle of stuff produced by The > Mathworks is pretty cool for the modeling world, but I think it has > problems when people try to bring it into production. It is very > tempting to say "Well, now that you've defined the control in the model > world and conducted a bunch of tests on it, why don't we just compile it > and take that code into the production box..." But the model world likes > to play fast and loose with all the things that might cause problems in > a production world. (For example, everything tends to be just a "real" > number - not much type checking going on. Or not much support for > low-level representations of data that might matter when the zeros and > ones actually connect to the hardware. Or any number of other complaints.) > > So people like to just build these models then take the code into > production, but might it not be BETTER if the modeling tool had > capabilities aimed at the production world? Might it not be BETTER if a > modeling tool took into consideration the needs of and proven techniques > of embedded software development? So if someone designed such a modeling > tool and incorporated Ada-isms into it and had it generating Ada code, > and it provided BETTER capabilities to the guy designing models, might > that not create an interesting marketplace for Ada? It absolutely true. I can confirm that in the automotive area it would be a great breakthrough, if something like above existed. Simulink lacks multi-threaded middleware for deploying the models. Considering a wide range of complex protocols which need to be supported (from CAN to TCP/IP), clearly there is an abyss between the code generated by Simulink to the code needed. More to the point, there is no chance that people drawing diagrams would be able to get this communication code right. An Ada platform with a middleware taking care of this mess would be technically unbeatable. However, there is a problem of acceptance. People want C. Even more they want C#. Lots of projects are doomed to fail before they change their minds... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ***********************************