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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,3ef3e78eacf6f938 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Newsgroups: comp.lang.eiffel,comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <19vb3fanruozp.kpikpepa685o.dlg@40tude.net> Date: Tue, 21 Jul 2009 17:46:12 +0200 Message-ID: <1lr1geiforebf$.127mieldddg2b$.dlg@40tude.net> NNTP-Posting-Date: 21 Jul 2009 17:46:12 CEST NNTP-Posting-Host: be7fa95d.newsspool2.arcor-online.net X-Trace: DXC=X8i=m8HA9EHlD;3Yc24Fo<]lROoR1^YC2XCjHcb9EL]HnTC4DNcfSJ;bb[5IRnRBaCd1mg_e`DQde On Tue, 21 Jul 2009 11:45:30 -0300, Cesar Rabak wrote: > Dmitry A. Kazakov escreveu: >> On Mon, 20 Jul 2009 22:33:59 -0300, Cesar Rabak wrote: >> For number crunching it is even more important, because numerical methods >> deal with different models of numbers. Even if the domain set is say real >> (R), you might wish to consider to use something different than Long_Float, >> because Long_Float is just a model of R, which might turn unsuitable for >> your needs. Ada allows you to use various models, develop models of your >> own, and design algorithms in terms of a specific model, as well as generic >> ones in terms of some set of models. > > Ada here is not as suitable as other languages, which Lisp is a better > example because Floats ultimately map to the underlying HW (a case of > premature optimization), whereas it could store the number as rationals > increasing accuracy and avoiding numerical instability. Huh, numerical instability is a property of an algorithm. It is not one of rounding errors. There is nothing in Ada which should prevent use of rational arithmetic, if that might be useful. Especially because one type of rational arithmetic is built in the language (see fixed point numbers). >> Another important aspect is strong typing, which allows you to concentrate >> on the problem rather than on debugging. Sometimes it is very difficult to >> debug scientific applications like number crunching, because in many cases >> you cannot tell whether the result is right. After all, the task of the >> application is to give a result. If you knew it, you would not need to >> crunch anything... >> > After years working with both strong (and static) typed and more > 'dynamic' ones, I disagree on this. Strong static typing plus the need > of the signatures as we're discussing here brings a lot of artifacts > that do not anything to do with the problem to be solved. > > For doing experimental work (here as opposed to, say, writing a library > for publishing) I suggest all be done in a dynamic language. I am doing both scientific (fuzzy machine learning) and engineering (automation, SCADA) work in Ada. I never felt any need in making it more dynamic. In fact, I'd like to see much more static features in Ada, than it presently has. In my list are: 1. Contracted exceptions 2. Static pure functions 3. Compile time type constraints 4. Static pre-/postconditions and invariants I don't buy Ada's current trend towards anonymous types, run-time checks, run-time pre-/post conditions, "functional style" of limited types initialization. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de