Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
in [ADA]
|
From: Warren on 26 Mar 2010 15:24 Martin Krischik expounded in news:op.u950lqpyz25lew(a)macpro-eth1.krischik.com: > Am 24.03.2010, 17:57 Uhr, schrieb Adam Beneschan <adam(a)irvine.com>: > >> 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". > > My personal definition is that a language is interpreted if the > majority of implementations use an interpreter. And Pascal would not > be among the list. > > Martin I still maintain you need to be specific about it. I will agree that they all were not interpreted. But at the same time it is equally wrong to imply that they were all compiled. Warren
From: Pascal J. Bourguignon on 26 Mar 2010 19:54 Adam Beneschan <adam(a)irvine.com> writes: > On Mar 24, 2:27�pm, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: > >> > 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. > > I think Patrick is essentially correct; the Wikipedia entry for "UCSD > Pascal" says: > > "The University of California, San Diego Institute for Information > Systems developed it in 1978 to provide students with a common > operating system that could run on any of the then available > microcomputers as well as campus DEC PDP-11 minicomputers." [This was > before the IBM PC came out, so I think "then available microcomputers" > meant Terak and maybe Apple II; perhaps there were some others.] > > So, yes, it was originally designed for student use; I don't believe > the original designers had any commercial use in mind. But its use > spread after that. Sure, but that's unfortunately the case of a lot of systems designed by researchers: they test bed them with their students. And that's the case of a lot of non academic systems including Java too, whose use spread badly beyond their original intend. -- __Pascal Bourguignon__
From: Pascal J. Bourguignon on 26 Mar 2010 20:03 Warren <ve3wwg(a)gmail.com> writes: > blmblm(a)myrealbox.com expounded in news:8143krF7lhU1(a)mid.individual.net: > .. >>> > 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. >> >> It's my impression that most/all current implementations of Java >> do "just-in-time" compiling (of the compiled intermediate code) >> to native code, and if that's true (certainly true of some of >> them), does the language really count as "interpreted"? Just >> sayin', maybe. > > The "JIT" business is just a distraction IMO. Before any > "compilation" occurs, something else (the interpreter) is > orchestrating things. Even the JIT "sections of code" are > invoked on the behalf of byte code by the "monitoring" > process (i.e. the interpreter). > > So unless you can get rid of that "managing process", you still > have what used to be called a "monitor process", that is outside > of the O/S. IOW, an interpreter. In CP/M, the monitor was the > O/S ;) but I digress. JIT or not JIT, this has nothing to do with the programming language, but with the processor. Therefore "interpreter" or "compiler" have nothing to do in a sentence with "JIT". Even a hardware processor such as an x86 processor could be doing JIT (eg. the Transmeta processors, or some high end Intel processors). -- __Pascal Bourguignon__
From: Andrea Taverna on 26 Mar 2010 20:53 On 23 Mar, 13:31, balson <lab...(a)cherrystonesoftware.com> wrote: > > > Where's performance on this list? Do you not care how fast the > applications run? Yes, I do, but there's a somewhat famouse quote I'd tend to agree with: /While hardware computing horsepower increases at roughly 60%/year, compiler optimizations contribute only 4%. Basically, compiler optimization work makes only marginal contributions. This means Programming Language Research should be concentrating on something other than optimizations. Perhaps programmer productivity is a more fruitful arena. (Probesting's Law)./ > Look at the following white paper to see if > performance should or shoild not be high on your list if you are > considering changing development languages: > > http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf With respect to that paper, it fails to account that Java and C# are quite different from the other alternatives I listed. More precisely, C#/Java may be required to perform a lot of checks to ensure "safety" in a very high level sense and both strive to offer a C-like alternative to C++ for some kinds of applications. Ada, CL, M3 and Pascal were designed with quite different goals that are likely to make them easier to optimize than the former two. As an example, I run your insertion-sort benchmark with the following implementations: - C with gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) - Ada with gcc GNAT, compiled with flags -gnatp and -O2 - Common Lisp SBCL 1.0.33, compiler directives are in the source code, the "usual" (speed 3) (space 0) (safety 0) on an Acer Aspire 3000 with 500MB RAM and processor AMD Sempron 3100+ 1.6GHz with Fedora Core 11 installed. Source for Ada and Lisp benchmark can be found here http://pastebin.org/125192 and here http://pastebin.org/125194 respectively. (ALERT: I'm a noob, at least in Ada and Lisp, so the code might be ugly has hell, but, hopefully, correct) The results: [Size] 100'000 200'000 400'000 /Lang] C 23.36 144.90 521.38 Lisp 40.74 147.97 692.51 Ada 22.88 112.92 488.69 [secs] [...] > I included Pascal because once you get up into languages that do bounds > checking, performance will degrade. Being a student, I'm almost ignorant on how coding is supposed to work outside academia, still I'm not convinced on this. For one, some of the languages I listed encourage the use of special idioms for accessing arrays s.t. such accesses are provably correct and efficient, e.g. Ada: for I in V'Range loop .... Lisp: (loop :with n := (length v) :for i :from 0 :below n :do.... ; not sure about this idiom ... and, as other have said, most of the implementation of those languages, with, IIRC, the exception of Java and C#, allow you to turn off those or all of the run-time checks for production code. > Pascal is one of those languages > that does bounds checking. It comes down to this: > > a) Either the programmer writes code to not exceed array bounds, or > b) Use a language that does it for you. But, well, there are other options! c) use a language that help you write correct code seems a viable one. Historically Pascal and the likes cared about providing the programmer a good deal of elementary tools, such as *true arrays*, C/C++ never provided that. Pascal-like languages have had *optional* run-time checks on array access for a long time. But I have seen lot of C/C++ code written by "experts" that followed the Greenspun's 10th rule. They wrote string/number munching code and invented their own run-time checks, so there's also d) write your own checks in a language that provides none Andrea
From: Martin Krischik on 28 Mar 2010 11:07
Am 26.03.2010, 19:21 Uhr, schrieb Warren <ve3wwg(a)gmail.com>: > Martin Krischik expounded in > news:op.u951g6eyz25lew(a)macpro-eth1.krischik.com: > >> Am 25.03.2010, 14:45 Uhr, schrieb Warren <ve3wwg(a)gmail.com>: >> >>> The fact that it was _popular_ means you have to deal with it >>> when making statements about the language's performance. >> >> It was never as popular as Turbo Pascal. I can think of 2 p-code >> pascals: The original With pascal and USCS Pascal. I can think of >> five which compile native... >> >> Martin > > It was never a popularity contest ;-) The fact that people > see it as "popular" (whether first place or last), means that > a mention of Pascal needs to be a qualified one. That would be "saw" it as popular. UCSD Pascal is dead long ago. You are clinging on the very last straw here to keep your argument up! Martin -- Martin Krischik |