Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
in [ADA]
|
From: Adam Beneschan on 24 Mar 2010 12:57 On Mar 24, 8:23 am, Warren <ve3...(a)gmail.com> wrote: > John B. Matthews expounded in news:nospam-E19D5A.22083823032010 > @news.aioe.org: > > > > > > > In article > > <3b3f991b-8fcd-435c-83f6-e1a1a5e8f...(a)a31g2000prd.googlegroups.com>, > > Adam Beneschan <a...(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. So it's executed by an interpreter. That doesn't make the *language* compiled into p-code an INTERPRETED LANGUAGE, which is what we were talking about---not any old "interpreter". -- Adam
From: Warren on 24 Mar 2010 16:00 Adam Beneschan expounded in news:bf27602c-09c5-45e4-97c1-608bf9729cbb(a)s2g2000prd.googlegroups.com: > On Mar 24, 8:23�am, Warren <ve3...(a)gmail.com> wrote: >> John B. Matthews expounded in news:nospam-E19D5A.22083823032010 >> @news.aioe.org: >> >> >> >> >> >> > In article >> > <3b3f991b-8fcd-435c-83f6-e1a1a5e8f...(a)a31g2000prd.googlegroups.com>, >> > �Adam Beneschan <a...(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.co >> >> > m>, >> >> >> > �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. > > So it's executed by an interpreter. That doesn't make the *language* > compiled into p-code an INTERPRETED LANGUAGE, which is what we were > talking about---not any old "interpreter". > > -- Adam So by your definition, my "tokenized basic" isn't interpreted either? It saves as an intermediate byte code also. So did GWBASIC IIRC. But nobody would say that GWBASIC wasn't interpreted. Sorry, but if any "execution" requires the help of an interpreter, it is "interpreted" at some level(s), even in Java's case. Now if the O/S could load and hand control over control to the loaded code (exec) without involving a separate process, then that would be different. Otherwise, I still smell an interpreted "language". Warren
From: Adam Beneschan on 24 Mar 2010 16:48 On Mar 24, 1:00 pm, Warren <ve3...(a)gmail.com> wrote: > Adam Beneschan expounded innews:bf27602c-09c5-45e4-97c1-608bf9729cbb(a)s2g2000prd.googlegroups.com: > >> 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. > > > So it's executed by an interpreter. That doesn't make the *language* > > compiled into p-code an INTERPRETED LANGUAGE, which is what we were > > talking about---not any old "interpreter". > > > -- Adam > > So by your definition, my "tokenized basic" isn't interpreted either? > It saves as an intermediate byte code also. So did GWBASIC IIRC. But > nobody would say that GWBASIC wasn't interpreted. Please read carefully what I wrote earlier: "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." I don't know what GWBASIC's intermediate byte code looked like. But if it was, in essence, an encoded representation of the source---"that bears a close relation to the original source statements", to quote myself---then it's an interpreted language. p-code does not bear any such relation to the Pascal source. I know that the question of "how close is the byte code to the source" is a fuzzy one. > Sorry, but if any "execution" requires the help of an interpreter, > it is "interpreted" at some level(s), even in Java's case. > > Now if the O/S could load and hand control over control to the > loaded code (exec) without involving a separate process, then > that would be different. Otherwise, I still smell an interpreted > "language". I think your definition of "interpreted language" is too broad to be meaningful. Suppose I had a Pascal compiler that generated code for a processor that is no longer manufactured. So I write a program that emulates that processor. That's effectively an interpreter, but does that make Pascal an interpreted language? Not in any meaningful sense. And what's the difference if the interpreter is for a processor that no longer exists, or for a processor that never existed such as the p-machine? To relate it back to the topic of discussion: I think it was you that claimed that it was meaningless to compare C/C++ results to Java, C#, or Pascal (variants) because the latter were "largely interpreted languages". To be meaningful, a statement like that has to be talking about the language as a whole, not just one or a few idiosyncratic implementations of a language. Some languages are definitely designed to be interpreted---APL, Perl, and Lisp all allow you to build strings or list structures at runtime that can be executed, and then execute them. Also, all of those languages support variables whose types can change during execution, making it difficult to generate efficient machine code. I don't know much about Java, but I believe it was designed to be interpreted (by a virtual Java machine) on different platforms, although apparently it can be compiled; I don't know whether the language design prevents it from being compiled into code that's as efficient as other languages. I don't know anything about C#. Pascal, on the other hand, doesn't have any of the characteristics that make "interpreted languages" what they are. Its variables are statically typed, and there is no built-in facility for parsing and executing a Pascal statement at runtime. Whatever other features there may be that are interesting about "interpreted languages", Pascal doesn't have them. In short, Pascal, as a *language*, is a traditional compiled language and there is absolutely no basis for putting it into the "interpreted language" category, period. The fact that one popular implementation of this language used a virtual machine and an interpreter for that machine is irrelevant. -- Adam
From: Patrick Scheible on 24 Mar 2010 17:11 Warren <ve3wwg(a)gmail.com> writes: > 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. True. But P-code was for student use, not production, especially not production in an application where execution time was critical. -- Patrick
From: Pascal J. Bourguignon on 24 Mar 2010 17:27
Patrick Scheible <kkt(a)zipcon.net> writes: > Warren <ve3wwg(a)gmail.com> writes: > >> 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. This is wrong. The most common implementations of these languages are all compilers. The fact that the compiled code is later executed by a hardware processor or a software processor (a "virtual machine") is irrelevant to the workings of the implementation of the language. >> > 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. > > True. But P-code was for student use, not production, especially not > production in an application where execution time was critical. This is wrong. P-code was designed, and used, exactly like the JVM is today. There even were developed processors that executed directly P-code, natively, like we have JVM implemented in hardware too. -- __Pascal Bourguignon__ |