Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
in [ADA]
|
From: Patrick Scheible on 23 Mar 2010 16:33 Pascal Obry <pascal(a)obry.net> writes: > Jim, > > > I included Pascal because once you get up into languages that do bounds > > checking, performance will degrade. 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. > > > > The choice of (a) will cost you a little bit of time developing. > > The choice of (b) is going to cost you in performance when done. > > > > If we were to add another language to our benchmarks, Pascal would be > > the logical choice. And we may do it at some point in the future. We're > > certainly going to add many more algorithms to the testing as time permits. > > I dont' know for Pascal, Ada does bound checking too. Nevertheless, in > some cases the checks can be removed automatically, for example: > > type Tab is array (1 .. 10) of Integer; > > T : Tab; > > for K in T'Range loop > T (K) := > end loop; > > Here "T (K)" won't trigger a runtime check as the compile can see at > compile time that K is always in the proper range. > > But anyway this is not even an issue. For performance you can always > remove the checks using the right compiler option. Then you have the > best of both worlds. During development the checks are really helpful, > in production you remove them. It's been said that this approach is like having lifeboats on an ocean liner while it is in sea trials, and then taking them out when it starts to carry passengers. -- Patrick
From: Patrick Scheible on 23 Mar 2010 16:34 jpwoodruff <jpwoodruff(a)gmail.com> writes: > On Mar 23, 10:54=A0am, Pascal Obry <pas...(a)obry.net> wrote: > > <jpw removed discussion of bounds checking> > > > But anyway this is not even an issue. For performance you can always > > remove the checks using the right compiler option. Then you have the > > best of both worlds. During development the checks are really helpful, > > in production you remove them. > > > > I hope I'm not the only old-timer who remembers: > > "This is the case of the sailor who wears his life jacket while > rigging his boat, > then leaves it ashore when he goes sailing." Not the only one. How many viruses spread by buffer overflow exploits that would be impossible in a bounds-checked language? -- Patrick
From: Pascal Obry on 23 Mar 2010 16:39 Patrick, > It's been said that this approach is like having lifeboats on an ocean > liner while it is in sea trials, and then taking them out when it > starts to carry passengers. Well don't get me wrong. I did not say that one MUST remove checks for production but that one CAN do that. In some cases, HPC come to mind, this can save quite some cycles. If the simulation is not critical (no life depend on it) then why not? At least this is a possibility, let's exploit it where and when it makes sense. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
From: Adam Beneschan on 23 Mar 2010 17:34 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. However, my recollection is that the pseudo-machine's instruction set really didn't have anything to do with Pascal and could have been used for any language. A few years later, Western Digital developed a machine that executed the P-machine's instructions directly (in microcode). The lab I worked for back in college (at UC Irvine) used this compiler, and we had one of the WD machines also, so this is something I'm quite familiar with, as far as the deteriorating brain cells of my memory permit. 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. I'd also assume that variables and other identifiers are stored by name, or by something equivalent such as a pointer into a string table, but that in any case the interpreter does things "by name". In contrast, I believe that UCSD Pascal allocated local stack variables pretty much the same way a native compiler would, referencing them via byte or word offsets from the top or bottom of a stack frame, although it's been a really long time so I could be wrong here. -- Adam
From: Mensanator on 23 Mar 2010 18:02
On Mar 23, 2:33 pm, Adam Beneschan <a...(a)irvine.com> wrote: > On Mar 23, 10:41 am, Jim Balson <lab...(a)cherrystonesoftware.com> > wrote: > > > > > > > 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. 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. > > > The choice of (a) will cost you a little bit of time developing. > > The choice of (b) is going to cost you in performance when done. > > Aside from the fact that (as Pascal Obry pointed out) compilers for > languages that do these checks for you usually provide a way to > suppress those checks, (a) is a little bit naïve. Or maybe a lot > naïve---I don't know. But it's like saying > > (c) The programmer writes code that just works perfectly all the time. > I asked a programmer once (after his program crashed immediately after he compiled it): "Didn't you run this?" His reply: "Why should I run it? I know how it works, I wrote it." |