Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!microsoft!jimad From: jimad@microsoft.UUCP (JAMES ADCOCK) Newsgroups: comp.object Subject: Re: Evaluating "Object-Oriented" Programming Languages Keywords: object-oriented, programming languages, evaluation, bibliography Message-ID: <10157@microsoft.UUCP> Date: 5 Jan 90 18:09:29 GMT References: <638@ajpo.sei.cmu.edu> <10132@microsoft.UUCP> <2626@tukki.jyu.fi> Reply-To: jimad@microsoft.UUCP (JAMES ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 72 In article <2626@tukki.jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) SAKKINEN@FINJYU.bitnet (alternative) writes: > >>-> Specify "hello world" minimum stand-alone run-time executable size, >> where that size would be the total number of bytes that must be transported >> to a system that never saw anything in this language before. Compare >> to a minimal C or Pascal "hello world" executable on that system >> for comparison. > >Since a "hello world" program has no importance, neither has its size. >OOP is mostly there to help the building of large and complicated programs. >A fully-fledged OO language typically needs a rather large run-time >system, independently of the size of the "main program". >I think that the condition, "a system that never saw anything >in this language before", is especially pointless. I use the "hello world" example as one which almost everyone has experience with -- and almost everyone has some interest in knowing the minimum executable size associated with a language. I don't use C++ just for large projects. I use C++ for virtually every everyday programming task. Knowing how small an executable a language can produce can tell you how small a programming task a language can handle. It can also tell you how small a machine the language can use -- if the minimum executable a language can produce is four megs, its not going to run on many home machines or low end PCs. Its probably not going to be used for many commercial application developments either -- because the language is going to require a whole bunch more floppies or tapes to be shipped so the purchaser can load the product. Also, in my experience, software developers create all kinds of little or medium size tools for internal consumption -- loading many of these on a machine is prohibitive if they take a couple megs a shot. And if I choose to program in Gwhizl, its unreasonable to expect all my cohorts to also install a 4-meg $900 copy of Gwhizl on their machine just so they can run my 2-person/days tool. Even among languages that do require substantial runtime support, it is still useful to be able to compare a language that requires 2 megs of runtime support to one that requires 4 megs of runtime support. Also, being informed of large runtime support requirements warns one to be suspicious that probably everyone running programs developed in this language is going to be forced by license agreement to buy a copy of the language -- or that there is going to be some other major licensing restrictions. Not always -- but forewarned is fore-armed. >>-> Include at least some simple common timing and size comparisons that >> people have experience with -- such as an "Object-Oriented" version >> of Ackerman's function. [..] > >This looks to me as another highly irrelevant criterion. >Ackerman's function is simply not the kind of thing that abounds >in ordinary applications. I suspect it would be unfavourable to >most OO languages, too. My intent here is to demand that OOPLs have *some* responsibility for reporting performance numbers. Ackerman's function is the simplest, grungiest, most commonly found example which one sees *everywhere* Publish your favorite language's performance on Ackerman's or some other better common spec, and *then* defend why your language is *good* is spite of this performance. Is Gwhizl a factor of 2X slower than C or Pascal on this simple stuff? -- Hey doesn't sound bad to me -- this language is worth looking into! Is Gwhizl a factor of 10X slower than C or Pascal? Sounds like a pain to me. Come back when you have a good optimizing compiler! Is Gwhizl a factor of 100X slower than C or Pascal? Don't call me, I'll call you! My claim is that most of programming in any language is made of pretty simple straightforward stuff -- assignments, flow of control, method dispatches, etc -- hence the whole RISC revolution to do simple stuff well. Thus I claim it *is* fair to ask OOPLs to show some performance numbers indicative of how they do on this kind of simple stuff. And even if it *isn't* fair, it still doesn't mean that OOPLs should avoid publishing these numbers. Because a large number of potential users are *still* going to insist on these numbers before they plunk down their hard earned $$$ [Or worse, before they go try to convince their bosses to switch from C to Gwhizl]