Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
in [General Programming]
|
Prev: Pathfinding algorithm bugged?
Next: Counting lines of code produced as a metric of programmer quality
From: Andrew Haley on 25 Mar 2010 12:42 In comp.programming Adam Beneschan <adam(a)irvine.com> wrote: > 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." I think there's some confusion here. UCSD Pascal was not the origin of Pascal P-code: the compiler that generated P-code was the 1973 Zurich P-compiler, part of the P-kit. The idea was for the user either to write an interpeter or modify the source of the P-compiler and replace its code-generaring routines. However, according to Wirth, "the reluctance of many to proceed beyond the interpretive scheme also gave rise to Pascal's classification as a 'slow language,' restricted to use in teaching." Andrew. N. Wirth, Recollections about the development of Pascal HOPL-II Pages: 97-120 ISBN:0-201-89502-1
From: blmblm on 26 Mar 2010 11:54 (Setting follow-ups back to the original cross-posting, since I don't read comp.lang.ada .... ) In article <Xns9D4482A264D8BWarrensBlatherings(a)188.40.43.245>, Warren <ve3wwg(a)gmail.com> wrote: > 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. [ snip ] > > 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. > But each "tool" has its own place in the toolbox. Can't disagree with that, though! -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
From: Warren on 26 Mar 2010 15:18 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. 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: 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 |