On Thu, 16 Dec 1999, Pascal Obry wrote: > Robert A Duff a écrit dans le message : > wcchfhkxjeg.fsf@world.std.com... > > I do. A fast language is one for which it is feasible to build > > compilers that generate fast code. A slow language is one for which > > that is not feasible. > > I pretty well understand that, but we are then talking about implementation > in a compiler. > > > Also I prefer to put the burden of proof on the language advocates -- > > that is, a language should be considered "slow" until proven "fast" by > > the existence of at least one good production-quality compiler. > > > > By this definition, Smalltalk, for example, is slow -- I've never seen a > > Smalltalk compiler that can generate fast code. Furthermore, it seems I like Bob Duff's definition, though it probably needs a bit more elaboration. A few years ago Richard O'Keefe posted some interesting microbenchmarks to comp.lang.ada comparing Pascal, Scheme, and Ada programs for two dimensional integration using downward funargs, with the (GNAT) Ada code using generics to simulate this. The Scheme code was the fastest. The Scheme compiler was an aggressive whole-program optimizer called Stalin. Despite the success of this microbenchmark, and Stalin, I suspect that Scheme would be classified as a "slow" language, like Smalltalk, this compiler not proving itself "production quality" yet. So what's the litmus test for being production quality? > Ok, we have never seen one, but is it really impossible ? I do remember > something about IBM creating a Smalltalk compiler, is that true ? How > fast was it ? You can create compilers for any language. However, Smalltalk keeps a lot of info around at runtime, so for example, when doing integer arithmetic you get transparent overflow into bignums if you need them. That costs! If your Smalltalk were to make each element of a float or complex array a self identifying (tagged) object then I guarantee you Smalltalk numerical linear algebra will run much slower than Fortran or Ada! -- Brian