Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
in [ADA]
|
From: Maciej Sobczak on 24 Mar 2010 04:31 On 24 Mar, 07:33, "Martin Krischik" <krisc...(a)users.sourceforge.net> wrote: > > Are they supposed to make products for those platforms that they > > consider inferior? Why? > > Self fulfilling prophecy? > > Consider something inferior and then rigged the test condition to prove > the point? That's one possibility. The other is: make a test (however naive), find the best platform (according to the test) and make products that target it. That would be actually rational. We can speculate, but objectively we don't know which is the case here and the innocent-until-proved-guilty rule of the modern society should prevent us from making unfounded accusations. I play the devil's advocate role here, but really I see no reasons to make a noise about this paper. Especially if Ada is not even being mentioned. From the Ada point of view this paper is neither right nor wrong. Heck - it is actually off-topic here. :-) -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Warren on 24 Mar 2010 11:07 Patrick Scheible expounded in news:w9z39zqlr2s.fsf(a)zipcon.net: > Warren <ve3wwg(a)gmail.com> writes: > >> balson expounded in news:4BA8BA91.4050905(a)cherrystonesoftware.com: >> >> > Andrea Taverna wrote: >> >> Hi folks! >> > [snip] >> >> In the past I used C, but now I have decided to change language. >> >> I'm looking for a "better" one. >> >> >> >> Here follow the features it should have, ranked approximately by >> >> relevance: >> >> >> >> 0) open-source support and an alive community >> >> 1) directly compiled to efficient code >> >> 2) statically typed and object-oriented, better if multi-paradigm >> >> 3) general-purpose libraries (possibly standardized, either by >> >> standard or de facto), including containers and some math >> >> abstractions. 4) garbage collected. As an alternative, provide >> >> memory management policies via libraries (e.g. memory pools and >> >> such) 5) optional run-time checks and some kind of control over >> >> compilation and low-level issues >> >> 6) "relatively simple and consistent" >> > >> > Where's performance on this list? >> >> Performance is mentioned in "1) directly compiled to efficient >> code". >> >> > IOW, stay away from the likes of Java, C#, Pascal. Unless you >> > have a >> > very specific reason for going in that direction. Your performance >> > will suffer. >> > Jim >> >> I don't think many people would be surprised by these results. >> After all Java, C# and Pascal (variants) are still largely >> interpreted languages, even if they use some sort of compiled >> intermediate code. > > Pascal is not an interpreted language. One of Pascal's selling points > was that it was one of the first languages that could be parsed by a > simple recursive descent parser without backtracking. > > -- Patrick P-code implementations were. Warren
From: Warren on 24 Mar 2010 11:10 Martin Krischik expounded in news:op.u916w9k9z25lew(a)macpro-eth1.krischik.com: > Am 23.03.2010, 17:50 Uhr, schrieb Warren <ve3wwg(a)gmail.com>: > >> I don't think many people would be surprised by these results. >> After all Java, C# and Pascal (variants) are still largely >> interpreted languages, even if they use some sort of compiled >> intermediate code. > > I would say the most used Pascal variants these days is Delphi and Ada > - both which compile native code. > > Martin Ok, sure (apart from old P-code variants). One has to wonder then why the Pascal "compiled code" was so miserable in their results. I don't recall if they mentioned which Pascal compiler they used. So if there is a surprise in there, Pascal would be it. ;-) Warren
From: Warren on 24 Mar 2010 11:15 Jim Balson expounded in news:4BA8FD54.8020200(a)cherrystonesoftware.com: > J-P. Rosen wrote: >> balson a écrit : >>> IOW, stay away from the likes of Java, C#, Pascal. Unless you >>> have a >>> very specific reason for going in that direction. Your performance >>> will suffer. >>> >> I don't see why you put Pascal in the same basket. Pascal is not part >> of the benchmark, therefore there is no evidence for what you say, >> and Pascal does not require an interpreter or semi-interpreter. > > I included Pascal because once you get up into languages that do > bounds checking, performance will degrade. ... Leave out bounds checking, and quality will degrade. Warren
From: Warren on 24 Mar 2010 11:23
John B. Matthews expounded in news:nospam-E19D5A.22083823032010 @news.aioe.org: > In article > <3b3f991b-8fcd-435c-83f6-e1a1a5e8f6ed(a)a31g2000prd.googlegroups.com>, > Adam Beneschan <adam(a)irvine.com> wrote: > >> On Mar 23, 1:27 pm, "John B. Matthews" <nos...(a)nospam.invalid> wrote: >> > In article >> > <7a0c7a19-5d83-4cc6-be68-95ebf4153...(a)t23g2000yqt.googlegroups.com>, >> > >> > cbcurl <cbc...(a)gmail.com> wrote: >> > > since when was Pascal ever an interpreted language >> > >> > AFAIK, ca. 1977, <http://en.wikipedia.org/wiki/UCSD_Pascal>. >> >> I wouldn't call it an interpreted language, really. The UCSD >> compiler generated code for a machine that didn't exist, and then >> programs ran by interpreting that machine's instructions. -------------------^^^^^^^^^^^^ I smell an interpreter! >> This doesn't meet my criteria for what I'd call an interpreted >> language. For that, I'd assume that the interpreter reads the >> original source statements, or some sort of tokenized form that bears >> a close relation to the original source statements, while running the >> program. That's a pretty narrow view. Usually ppl talk of "interpreted" vs "native code execution". It would be incorrect IMO to call p-code natively executed code. Warren |