Xref: utzoo comp.lang.misc:6986 comp.object:2825 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!ni.umd.edu!uc780.umd.edu!cs450a03 From: cs450a03@uc780.umd.edu Newsgroups: comp.lang.misc,comp.object Subject: RE: blip [Re: Dynamic typing -- To Have and Have Not Message-ID: <21MAR91.23091547@uc780.umd.edu> Date: 21 Mar 91 23:09:15 GMT References: <22032@yunexus.YorkU.CA> <11820:Mar1923:59:3591@kramden.acf.nyu.edu> <19MAR91.22493670@uc780.umd.edu> <18271:Mar2013:19:1091@kramden.acf.nyu.edu> Sender: usenet@ni.umd.edu (USENET News System) Organization: The University of Maryland University College Lines: 74 Nntp-Posting-Host: uc780.umd.edu 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