cs450a03@uc780.umd.edu (03/20/91)
Dan Bernstein writes: >Of the languages that I've used much, I find Forth the most expressive. Do you, perhaps, write a lot of interface code? (Just curious) > ... >Expressiveness is nice. Anything syntactic is nice. But I don't need >niceties. I need portability. I need fast compile times and run times so >that the machine's turnaround time during testing and debugging doesn't >become a significant part of my turnaround time. I need language power: Ah yes, portability. Portability currently means: C, Fortran, COBOL, ADA, 8086 assembly, or maybe Pascal. This will change in the future, of course, and I'm working on making it change the way I want. (Also note that there are a number of efficiency problems with C, having to do with the semantics of C pointers. Thus any language which uses C as an intermediate language is going to have the same efficiency problems, no matter how tight the design. This will get worse as machine architectures migrate away from C's PDP-11 roots.) Compile times become less important in an interactive environment, but I will admit that the compiler I use is slow (most of the time spent in the optimizer). Part of that may be that I'm usually compiling on a machine that's barely 22MIPS, with usually above 100 users (and I usually keep my priority way down low, so I don't impact the system). On top of that, there are literally hundreds of improvements I'd like to see in the compiler. Maybe eventually... (Slow compilers have existed in all languages. That changes as customers demand more speed (or in the case of GNU, and probably the old AT&T C compiler, that changes with exposure).) Language power, now, hmm... say 20 slug micron lightyears per nanosecond per square year? Yeah, I need that sort of stuff too... >Actually, I have a reasonably good idea of what I'm talking about. My >comments on dynamically typed languages are based not only on my >experience but also on many objective and subjective articles by both >detractors from and proponents of such languages. As a matter of fact, >if you want to buck the establishment, it's your problem to prove that >dynamically typed languages aren't as inefficient as most experiments >have found them to be. Nahh... if I want to buck the establishment, it's my problem to make more money than them. But in any event, I never claimed to have used a dynamically typed language more efficient than a staticly typed language (part of that has to do with the kinds of machines I've worked on). What I have claimed is that I can solve problems faster in a dynamically typed language than in a statically typed language. Of course I picked a job where that is a significant factor... Of course, efficiency is also a matter of coding style. As is readability. And what is good in one language is grungy in another. (Thus throwing lots of free variables into any comparison of languages.) Hope you don't mind if I ignore your experiments and articles, eh? >Would you write a compressor in a dynamically typed language? As a matter of fact, one of the guys at work was doing that several weeks ago. I should ask him how it came out. Raul Rockwell
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/20/91)
In article <19MAR91.22493670@uc780.umd.edu> cs450a03@uc780.umd.edu writes: > Dan Bernstein writes: > >Of the languages that I've used much, I find Forth the most expressive. > Do you, perhaps, write a lot of interface code? (Just curious) I don't know what you mean by ``interface code.'' > (Also > note that there are a number of efficiency problems with C, having to > do with the semantics of C pointers. No. Aliasing is a problem for *optimizers*. Except on vector machines it does not create problems for code written efficiently. > What I have claimed is that I can solve problems faster > in a dynamically typed language than in a statically typed language. I firmly believe that the speed of problem-solving in any language is based mostly, if not almost entirely, on how much already-written code you can apply to the problem. There is no reason beyond religion to believe that dynamic typing helps reusability. > >Would you write a compressor in a dynamically typed language? > As a matter of fact, one of the guys at work was doing that several > weeks ago. I should ask him how it came out. Yes, please do. ---Dan
hoelzle@neon.Stanford.EDU (Urs Hoelzle) (03/21/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >> What I have claimed is that I can solve problems faster >> in a dynamically typed language than in a statically typed language. >I firmly believe that the speed of problem-solving in any language is >based mostly, if not almost entirely, on how much already-written code >you can apply to the problem. I absolutely agree. >There is no reason beyond religion to >believe that dynamic typing helps reusability. I absolutely disagree: The maximum reusability occurs in a system where every piece of functionality (you may call this "algorithm") is specified EXACTLY ONCE (i.e. there is no redundancy). This requires that every piece of code depends ONLY on the abstract interface of its arguments: for example, a sort routine would work on every collection whose elements understand < and =. Current type systems are too restricted to allow this, and so you end up duplicating functionality in many cases. However, in dynamically-typed languages such as Self you *can* write e.g. a sort routine which works for *every* kind of object which understands the comparison protocol. Thus, if you design your system correctly, ideal reusability can be achieved *today* in an untyped language but not in any typed language I know of. It can be achieved partially in languages with genericity. But only partially: as soon as you also use inheritance, you get lots of problems with static type systems. (For example, if T1 is a subtype of T, "collection of T1" is *not* a subtype of "collection of T".) So you have to give up on the "no duplication" goal with today's staically-typed languages and thus reduce reusability. [Many papers have been written on this, so I'll omit the details here. Pointers available on request.] In summary, the statement "typing helps reusability" has nothing to do with religious beliefs - it's a fact. Note that I'm not saying that the same reusability couldn't be achieved with "mostly-typed" languages, i.e. languages which use types for what they are good at (detecting trivial errors) but still allow you to use the flexibility of dynamic typing where it is required. -Urs -- ------------------------------------------------------------------------------ Urs Hoelzle hoelzle@cs.stanford.EDU Center for Integrated Systems, CIS 42, Stanford University, Stanford, CA 94305
ram+@cs.cmu.edu (Rob MacLachlan) (03/21/91)
>Newsgroups: comp.lang.misc,comp.object >Subject: Re: blip [Re: Dynamic typing -- To Have and Have Not ...] >Date: 20 Mar 91 13:06:03 GMT > >In article <1991Mar20.041716.4486@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes: >> I think that you overstate the case. Common Lisp is at least as portable as >> C, > >What world do you live in? [...] 95% of the machines I use do *not* support >Lisp even if they *could*. I live in a research-oriented computer science department. Nearly everything is done on technical workstations (Suns, DECstations, etc.) These systems all support Common Lisp. What world do you live in? Probably it is a world where Lisp programming doesn't make any sense (real time? operating systems?). Both my direct and indirect experience in this environment has lead me to believe that Lisp provides a better way of evolving solutions to complex problems than is offered by more conventional programming languages. I suspect (and have heard some claims that) Lisp is also helpful in industrial R&D and prototyping. >> and Lisp systems offer unsurpassed compile-debug turnaround times (through >> incremental compilation.) > >``Unsurpassed'' is exaggeration, and even if compile times were instant >I'd spend forever just waiting for most programs to run. Not really an exaggeration... Once you get down under a second, additional improvements become relatively unimportant. >> -- For some uses, efficiency isn't everything (research, prototyping, >> development.) > >In fact, I've been focusing on the prototyping and development stage of >a program, because that's when it's most important to get good compile >times *and* run times. I agree that good run-times are crucial in a protopying and development environment. This is the main reason why CMU CL goes to so much effort to minimize the overhead for dynamic type checking (doing as much checking as possible at compile time), and also why CMU CL has such good support for source-level debugging of optimized compiled code. In previous non-Lispm Lisp environments, in order to get safety and debuggability, you had to pay a big efficiency hit (5x or more) to get safe code. In CMU CL, the penalty never exceeds a factor of two, and is often down around 10%. This is in comparison to pull-out-all-the-stops benchmark mode optimized compilation. >In article <19MAR91.22493670@uc780.umd.edu> cs450a03@uc780.umd.edu writes: >> What I have claimed is that I can solve problems faster >> in a dynamically typed language than in a statically typed language. > >I firmly believe that the speed of problem-solving in any language is >based mostly, if not almost entirely, on how much already-written code >you can apply to the problem. In research and development, you are devising and perfecting new solutions. Reuse is important, but in R&D, this mostly takes the form of self-reuse (cannibalization or evolutionary programming), rather than glomming onto existing code. >There is no reason beyond religion to believe that dynamic typing helps >reusability. There is good reason to believe that polymorphism aids reuse, since you can program "generic" facilities. Dynamic typing makes polymorphism trivial, and Lisp was the first widely used polymorphic language. In recent years, other forms of polymorphism have become available outside of Lisp (including object oriented extensions.) Another aspect of Lisp that aids reuse, but which is poorly understood (even in the Lisp community) is meta-programming. The ease of adding new linguistic features (and their associated semantics) to Lisp is the main reason why Lisp systems were the first to offer "industrial strength" object oriented programming environments. Now that OOP is relatively well understood, it is trickling down into mainstream languages, but there is no reason to suppose that programming language development will stop with OOP. Using a language that supports meta-programming allows you to devise new languages for solving new problems. Rob MacLachlan (ram@cs.cmu.edu)
peter@ficc.ferranti.com (Peter da Silva) (03/21/91)
This is a bit of a digression here, but... In article <1991Mar21.003805.28496@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes: > Another aspect of Lisp that aids reuse, but which is poorly understood (even > in the Lisp community) is meta-programming. The ease of adding new linguistic > features (and their associated semantics) to Lisp is the main reason why Lisp > systems were the first to offer "industrial strength" object oriented > programming environments. Why is this seen as a strength of Lisp, but a shortcoming in Forth? I think largely because Forth typically runs on systems tens to hundreds of times slower than Lisp, and the dynamic typing and interpreter overhead (both in memory and wall-time) becomes more obvious. Certainly a dynamicly typed Forth is possible: look at Postscript. (personally, I don't see why there needs to be a debate. There are good reasons for using both types (heh) of language in appropriate contexts. What's appropriate for a small standalone utility or an embedded system and what's appropriate for a GUI-based program running on a workstation are completely different beasts... we need floor waxes *and* dessert toppings, and a single tool won't do for both jobs) -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
jls@rutabaga.Rational.COM (Jim Showalter) (03/22/91)
>The maximum reusability occurs in a system where every piece of >functionality (you may call this "algorithm") is specified EXACTLY >ONCE (i.e. there is no redundancy). This requires that every piece of >code depends ONLY on the abstract interface of its arguments: for >example, a sort routine would work on every collection whose elements >understand < and =. Agreed. >Current type systems are too restricted to allow this, and so you end >up duplicating functionality in many cases. Disagreed. In Ada, for example, you can dynamically instantiate a sort generic with the type and comparison desired, giving you a type model that supports what you want to be able to do. >However, in >dynamically-typed languages such as Self you *can* write e.g. a sort >routine which works for *every* kind of object which understands the >comparison protocol. And you can do this in Ada, too. >Thus, if you design your system correctly, ideal reusability can be >achieved *today* in an untyped language but not in any typed language I >know of. Ada. >It can be achieved partially in languages with genericity. Why only partially? -- ***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd ever be able to find a company (or, for that matter, very many people) with opinions like mine. -- "When I want your opinion, I'll read it in your entrails."
cs450a03@uc780.umd.edu (03/22/91)
Dan Bernstein's comments are > and >> > earlier comments of mine are >> >> >Of the languages that I've used much, I find Forth the most expressive. >> Do you, perhaps, write a lot of interface code? (Just curious) >I don't know what you mean by ``interface code.'' By 'interface code' I mean high-speed-real-time-state-machine type stuff. Examples include device drivers and editor screen/buffer management. >> (Also note that there are a number of efficiency problems with C, >> having to do with the semantics of C pointers. >No. Aliasing is a problem for *optimizers*. Except on vector machines it >does not create problems for code written efficiently. All languages have problems when they cannot express some basic operation of the underlying machine. Aliasing is a problem I find amusing, that's why I pointed it out. As for efficiency, I would claim that except for what I called interface code (lotsa small highly serial operations) dynamic typing does not create problems for code written efficiently. Of course, for many purposes pointers and dynamic typing are synonomous (or 'functionally equivalent'). I suppose that proves something... >> What I have claimed is that I can solve problems faster >> in a dynamically typed language than in a statically typed language. >I firmly believe that the speed of problem-solving in any language is >based mostly, if not almost entirely, on how much already-written code >you can apply to the problem. There is no reason beyond religion to >believe that dynamic typing helps reusability. Speed of problem solving also depends on how easily you can change the domain of the problem. And on how familiar you are with the programming language. And on how much work you lose when you find a problem (which is equivalent to how much more work you must do before you can 'pick up where you left off'). And on how fast the machinery is. And on the number of keystrokes you must type. And on how well you understand the problem. And on how fast you learn. The system I use allows me to restart with minimal backtracking. That means no recompilation, no reinitialization, no repeated file ops (unless, of course, that's what went sour). And since I never had to compile the program in the first place (compilation is a stage that we OCCASIONALLY use AFTER development), I think that's pretty fast. Is that religion? >> >Would you write a compressor in a dynamically typed language? >> As a matter of fact, one of the guys at work was doing that several >> weeks ago. I should ask him how it came out. >Yes, please do. Ok: That routine was intended to compress integers. He wrote several routines and found they all gave around a 2:1 compression ratio for typical data. So he picked the one that was usually the fastest. Turns out that compilation (even re-writing in the style that the compiler favors) does not significantly increase speed. He's going to try and get it hand-assembled. Meanwhile (today) we was working on how word-inversion data gets distributed to file. (Quote: "I'm running inversion on large numbers of documents for speed, but it's taking several hours to post the hits for a hundred fifty thousand words.") Since he hasn't solved that one yet, I don't know what the solution is. Incidentally, I gave him a copy of an article on text compression I found in gnu.misc.discuss. Article was by some guy named Dan Bernstein--ever hear of him ;-) Raul Rockwell
lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (03/24/91)
In article <1991Mar21.003805.28496@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes:
problems than is offered by more conventional programming languages. I
suspect (and have heard some claims that) Lisp is also helpful in industrial
R&D and prototyping.
See our group's paper, presented at the 1990 International Switching
Symposium in Stockholm and entitled, "Object Oriented Software
Technologies Applied to Switching System Architectures and Software
Development Processes."
Lawrence G. Mayka
AT&T Bell Laboratories
lgm@iexist.att.com
Standard disclaimer.