There has been a lot of buzz about the seeming rise of dymanic languages. Here is an article and interview with some of the top people in their respective language field (even more here).
Dynamic Languages on the rise
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
All these new fancy languages may be nice, but the father (or mother) of all programming languages is still Common Lisp.
If all you see is parentheses, something is wrong with your eyes (or programming mind).
Yup, dynamic languages sure are great. Me likes my python and I’m currently acclimatizing to ruby. Can’t understand why they didn’t interview Matz for Ruby and Wall for Perl but hey, they have jobs, can’t jump for every Interview.
But Guidos comment about how dynamic languages are encroaching on >>standard<, languages is dead on. Lots o python apps are cropping up in gnome and even a few Ruby apps (notice the announcement of Alexandria on Gnomedesktop).
Before the DEs started taking of there where lots of Perl and Tcl apps on most Unix desktops even Dos had its basic interpreters. It’s a rather pleasant way to write code if you ask me and I’ll stick with it.
The problem with Lisp (and with Scheme) is not that it has lots O parentheses (you get used to that it about 5 minutes) but that there are so many fractured implementations of Scheme and that Common was developed by basically cramming all other versions of Lisp into one big old bloated system. Now Dylen, that’s more interesting to me.
Would D programming language by Mars be a dynamic language ?
Why isn’t there a visual basic clone ?
I can’t wait for parrot to unite all those languishes in one VM.
No, D is not a dynamic language, the dynamic in dynamic language refers to typing.
And as to Visual Basic, why would anybody want to clone that? Visual Basic aint that pretty, so even MS threw it out and started over with VB.NET, if you want a VB like language try Gambas.
Python, Ruby and Dylan (if only it wasn’t on life support) are the answer. No matter what the Smug Lisp Weenies (TM) think, prefix notation is a problem
Many of the things said in this interview about the main compiled languages as being misleading, but I will pick on one here:
Will someone please explain to me why static typing is so bad and no scripting language does it? I don’t buy the argument that problems that would be caught by doing static type checking “just don’t happen”. As I read through the docs for python or perl classes you find that docs specify the types in prose, instead of in code. The first is hidden (or non-existent), but the later is clear and explicit. And I don’t see what the productivity gains from not specifying types are. Please enlighten me.
To replicate the expressive power of dynamic languages, static languages generally use dangerous tools like pointers. If you Joe Coder mis-interprets what “type” your pointer is currently pointing at – Boom.
I’m a big fan of dynamic environments and dynamic typing, however I don’t like Ruby, Perl, PHP, Python, etc. Why? They are forever limited to being ‘scripting’ languages. Are any of these languages written in themselves? No, they have huge runtimes in C. This reduces flexibility and reflection capabilities, and also lessens incentive to improve performance and write compilers. Also, these scripting languages usually have complicated, ambiguous grammars and poor development environments. Can you write PHP code that manipulates PHP code as a syntax tree? Probably not, since the PHP parser is inflexible and hidden behind layers of C. Also note that PHP and Perl are among the slowest of all language implementations. Only shell script is slower. There is no excuse for this kind of sloppy coding — Sun Research’s Self language back in the mid-90’s showed that a dynamic language can be almost as fast as C, if the compiler has enough sophistication. If you want to see good dynamic languages, I suggest checking out Smalltalk, Lisp or Slate, not the scripting language disasters currently popular in the Unix community.
reading about the cell processors, i think that nobody will dare to use low level languages to program it.
may be they could bring back to life lisp machines (or python machines)
Static typing isn’t bad per se. It’s mostly just annoying.
For big projects with libraries and the like, static typing is useful (especially if you aren’t the original coder) as obvious errors can be picked up at compile time.
However its a huge drain on time. Most scripting languages have a “just works” philosophy. It’s more about being productive rather than anally correct all the time. I generally spend an enormous amount of time rote typing and compiling in Java and then still spend a lot of time doing runtime debugging, just like I would in a dynamically typed language. Admittedly in many cases actual programming errors are far easier to location in Java than scripted languages.
And lastly in a dynamically typed language there isn’t any casting. Casting is evil and annoying and makes the same dumb assumptions about the type of an object as a dynamic language does (If the object is of the wrong type then they both die horribly.) And the dynamic version is a lot quicker to produce.
There are pros and cons to both approaches, but static typing doesn’t really solve all the problems. You still get runtime errors due to bad function calls and bad data.
That said I’m still glad my current project uses Java.
“All these new fancy languages may be nice, but the father (or mother) of all programming languages is still Common Lisp.”
Lisp is “never gets things done”‘s best friend.
There are some languages in which you can have 20 simultaneous projects. I guess Lisp is not very good for project explosions like that. When some people open their Subversion repositories, you can take a look at what they work. I myself have many projects going on, and I use Ruby.
I’ve seen enough Lisp people that just want to use the “king of the languages” because Paul Graham said so… People follow others blindly… Python anyone? 🙂
1) It’s not so much that the errors static typing prevents “just don’t happen”, but rather that static typing can only prevent a small class of errors, and those errors are usually caught very early in the development process. This is particularly true if you adhere to the standard development style for dynamic languages: writing and testing one function at a time in an interactive toplevel. If you follow this, you’ll weed out type errors immediately.
Now, this point is really only applicable to languages with primitive static type systems like C++, C#, or Java. More sophisticated static type systems, like those found in ML, can find a much larger class of errors, including semantic ones, and that can be valuable.
I’ve been programming for awhile, and after the first couple of years, I rarely made type errors. When I did, it was almost always because I was trying to abuse the type system in the first place. On the other hand, I make fencepost errors all the time, but static typing generally doesn’t prevent that. So I’m unconvinced about the benefits of static typing.
2) The benefits of static typing are two fold. First, they make writing the code faster. You can concentrate on expressing your algorithm, instead of worrying about details. If your logic is sound, not only will the details about typing work out properly, but so will other details (eg: boundary conditions) that a static compiler wouldn’t be able to catch. The more the language let’s you concentrate solely on your algorithm the less the strain on your attention and the higher the chance your logic will indeed be sound.
Second, they make maintaining and extending the code faster. Dynamic languages engender a very specific way of building programs. You start with a kernel — a simple, small, prototype that demonstrates the underlying concept of the program. At this stage, you only care about correctness, so you use the simplest types and structures possible. Then, you enter an iterative process, gradually refining and testing the prototype until you arrive at a final program. When a program needs to be extended, you simply continue this process until you arrive at what you want.
Static languages hinder the type of development I described. Fundementally, types are contracts. In iterative development, static languages force you to specify contracts before you know what they should be (indeed, before you even know if your idea will work), and force you to modify them on every iteration. You’re forced to either overengineer the initial concept (this is why Java code tends to be so gothic) or perform lot’s of busywork if you didn’t.
Slate is interesting and I look forward to it, since it will also be the first time for me to experiment around with some of the nice Self ideas it incorporates. But Smalltalk has one big problem (that slate doesn’t address if I remember right) the idea of the image is a bit of an irritant to me. Sure nice for packaging and all, but not so nice for sharing as text files and when you corrupt your core image you better know how to fix it. I always found this odd in a language designed for children.
But back to some of the problems of dynamic language, the fist big one being speed. Parrot with any luck will address this, parrot is a really interesting playground for dynamic languages and I got myself a copy to poke around with till it gets finished. Did you know there is a Python implementation for parrot being worked on named Pirate and that it is implemented in python? Some parts of the python libs are implemented in Python and have c equivalencies for speed reasons. If parrot is fast enough most, maybe all of the libs could be implemented in Python. Parrot makes it easier to make bindings for external libs for all scripting languages based on Parrot, less work spent on wrapping GTK+, SDL and so on 25 time for Pyhton, Perl, Ruby, TCL, Scheme, PHP and so on will give us more time to work on nicer things.
Sure some things still have to be addressed, there shoed be a nice FOSS IDE for dynamic languages, (I spent all day searching for a good refactoring browser for python all day just to find out that the one I found doesn’t work on XP) not half a doesn’t mediocre ones for each language. And there should be a good packaging tool for parrot + dynamic language of your choice. After that I don’t think that Smalltalk would have to much up on python, ruby and the like.
But hey that’s only my opinion. Some people like to program in BrainFuck and participate in code obfuscation contests.
First, this parentheses:
((entrou)) slava [[email protected]]
slava> All your base are belong to us!
((saiu)) slava [[email protected]]
SeaForth> night slava
SeaForth>
I’m too slow
Second, check out this article by Hal Fulton on Ruby uses:
http://www.devsource.com/article2/0,1759,1778695,00.asp
In most of the semi-dynamic typed structures out there, a ridiculous amount of time seems to be spent making sure that a given object is of the class you think it is.
That’s because you have to – in a multi-programmer environment, you can’t trust anyone, including yourself.
Static typing doesn’t really help -that much-, but it helps. It’s no panacea, but it sure does stop some classes of errors. There are few things more frustrating than having your language automatically converting one type to another during a comparison, and doing the Wrong Thing because of it.
Dynamic languages are great, but most of the time their flexibility just adds confusion and complexity. I think for some problem spaces they’re a good solution, but most of the benefits of OODLs seem to be centered around RAD/prototyping. The problem with that is, well, everyone knows what you’re supposed to do with a prototype.
Dynamic languages will influence the future, but at Middleware, they really dont have the performance or the maturity. Dynamic languages on VMs (like IronPython on CLR) are the way to go. I hope once the power of CLR(or for that matter JVM) is harnessed by dynamic languages, they would gracefully become main-stream without disrupting the existing Enterprise technologies like Java and .Net. and one of them would very well end-up with popularity akin with VB(easy and productive) at the sametime piggy-backing on proven existing technologies by reusing existing systems/libraries/components.
Me thinks dynamic languages on JVM/CLR are the way to go.
That’s where they are going, without the help from Sun or Microsoft.
It’s like the last frontier.
But few people have noticed this, compared to what people use in their jobs.
The Dynamic Languages are bringing with them much more than Dynamic Typing and a good syntax. They are bringing lots of programs, libraries and hackers. Stay tunned!
Meanwhile, JVM is Java and Visual Tools. CLR is C# and ASP.Net. And I don’t see that changing in the near future. Because the same companies that like to use “static typing” are the same that aren’t in a hush to have the Dynamic Languages dominating the developments.
But though they prefer “static typing”, they have fallen in love with the Runtime Environment, just like Dynamic Languages do. Which means that they are close enough to the top techs. 🙂 hehehe
I agree with your point that languages should have their engine written in themselves.
Luckily, this should become true for Python (PyPy,Pirate), Ruby (Rubydium,MetaRuby/Ruby2C), Perl (parrot).
Anyway I don’t see why you’d need a full runtime written in X language to allow language X to have complete reflection.
Also, I’m not sure that directly accessing the AST is a needed or even good thing. Yes, you can make some nice things with that, but I won’t bet this is the /right/ way.
@Usario Clave:
In most of the semi-dynamic typed structures out there, a ridiculous amount of time seems to be spent making sure that a given object is of the class you think it is.
If you’re having to do that, you’re doing it wrong. You don’t (and shouldn’t) care what class the object is. All you should care about is what methods it supports. If an object doesn’t support the methods you think it supports, then you’re not thinking as you’re writing the code. If you use the static type system as a crutch to avoid thinking, then it’ll save you from 1% of mistakes, but you’ll still make the other 99% of possible mistakes.
That’s because you have to – in a multi-programmer environment, you can’t trust anyone, including yourself.
You’ve got to have protocols in place. Static typing doesn’t prevent you from returning 1 instead of 0 on an error, but nobody considers them unusable for that reason…
There are few things more frustrating than having your language automatically converting one type to another during a comparison
No dynamic languages I know of automatically convert types. Only C++ is braindead enough to do that…
The problem with that is, well, everyone knows what you’re supposed to do with a prototype.
Develop it into the final product? There is no reason that you need to throw away a prototype program — it’s a working program that is (if you do it right), “correct”. It’s the fundemental piece of your program, the 10% that does 90% of the work and takes 99.9% of the thinking. Adding all the bells and whistles after that shouldn’t require you to throw away that important work!
Me thinks dynamic languages on JVM/CLR are the way to go.
Why, oh God, why? JVM and CLR are horrible for dynamic languages — they take the 20 years of research that has been put into getting dynamic language compilers to emit fast code, throws it out the window, and puts up lot’s of static-typing inspired roadblocks in the process.
I am actively coding in Java, PHP and Python. Recently I did some Java coding that requests testing on-site. Strong types and syntax rules of Java saved me a lot of time spent on-site.
Compiler caught a lot of mistakes in the very begining.
On the other hand, larger PHP project needs literaly months to
be debugged properly. I have some aplications in PHP, and I wonder if they will ever be debugged completly.
DG
“… The research firm reports that over 41 percent of the 666 developers…”
Why 666 ?
It has something to do with marketing, we all now marketing is evil…
At least day didn’t tell us how many chickens and goats hat do be sacrificed.
Ok, I understand.
Bar code and all this.
Perl/Python/Ruby and Lisp/Smalltalk/Self are really of two kinds of dynamic languages. The former are scripting languages. The latter have the ambition to put together the language, the memory ( disk and Ram ) and the whole system. The reproach over Smalltalk image file doesn’t apply if the Smalltalk VM encompasses the whole system, like Lisp Machines did.
The ambition of dynamic programming language is well beyond replacing C# or Java by an implicit typing syntax. The ultimate goal is to have fully exploratory systems and get rid of the concept of monolithic software like a “Word Processor” or a “Drawing Tool” ( Maybe also getting rid of closed source not reuseable modules )
( Try Squeak as a proof-of-concept )
Think about that : The language IS the operating system !
The ultimate goal is to have fully exploratory systems and get rid of the concept of monolithic software..
Ruby isn’t image based like Smalltalk. But you can certainly interact with it at runtime using tools like ‘irb’ (Interactive Ruby), or a ruby debugger. You can try out arbitrary new code, fix bugs, and add new methods or classes as your program is running. That’s the big difference between ruby and statically typed compiled languages like Java or C#. With java you might as well be punching cards and sending them off to be compiled – not quite as advanced as interacting with a lisp interpreter via a teletype 30 years ago.
Oh, don’t worry. I’ve long ago gotten the idea that >>the language is the operating system<<. It’s an idea you can’t help but understand when you look at smalltalk, slate and tunes.org. The problem is that the only language available would be smalltalk/slate.
That’s why I’m rather fond of Parrot, a cross language open system for multiple languages. What I’d like to see (but probably won’t) is slate on Parrot.
To put it the simplest way I can, what I like about Ruby, Python and co. is that they are all pragmatic. They know there are other languages out there and they have to interact with them. Lisp/Smalltalk/Self and co. are idealistic. They hope they are the only language out there, but aren’t. Since I like language diversity it’s easy for me to chose my languages of choice.
“Also note that PHP and Perl are among the slowest of all language implementations.”
Where do you get this? I am just curious if you just pull it out of thin air or you have something to back it up.
> > Me thinks dynamic languages on JVM/CLR are the way to go.
>
> Why, oh God, why? JVM and CLR are horrible for dynamic
> languages — they take the 20 years of research that has
> been put into getting dynamic language compilers to emit
> fast code, throws it out the window, and puts up lot’s of
> static-typing inspired roadblocks in the process.
Yes and no. Intentionally, JVM and CLR do not pose restrictions on the code they run. They are just there to make sure that the code doesn’t violate certain rules, namely rules that may not be violated by compiled dynamic languages or a dynamic language interpreter either (example: mistake an integer for a pointer). What I try to say here is that the compiled code from a dynamic language does abide to many static typing rules. The real problem is that these rules cannot be bent to match the static typing rules that the JVM or CLR demand.
The problem is not a general one, but shows how limited the typing system of JVM and CLR are.
Ruby is the (final?) evolution of what scripting/dynamic languages really want to be. Consistent near-intuitive grammar, flexible and powerful. Even Perl 6 and http://www.onjava.com/pub/a/onjava/2004/09/29/groovy.html“>Groov… (hm. I wonder why that wasn’t profiled) are trying to be Ruby clones.
No, I disagree. Perl 6 doesn’t want to be like Ruby. Larry Wall stated so at the beginning of development. He wants better object orientation and a cleaner syntax, but that doesn’t make it like Ruby.
Python is evolving in a direction that is different from the direction of Ruby and that is good so. True, Ruby is a nice language, but I still prefer Pyhton. Imagine how boring things would get if all languages would start to look alike.
eh, you should consider this:
http://c2.com/cgi/wiki?PythonAndRubyAreConverging
anyway, perl6 has some rubyish features, but it is definitely different, just think of multiple dispatch and Grammars.
I’d say it is at most a Dylan clone
Personaly I was thinking more along the line Python Lambdas Vs. Ruby blocks. And Since GvR wants to remove Lambdas ands some other stuff from Python (see here)
http://lambda-the-ultimate.org/
I think they are diverging more. But since I started learning Ruby only a short time ago, I will know for sure soon.
By the way, this was one of the most sociable discussions on OSNews in a long time, I could do with more of this, even if it not really OS related.
You totally missed Rayiner Hashem’s point. Consider a language where you can call a method on any object. If you run this language on the JVM, there will be a reflection lookup each time the method is called. Java reflection is terribly slow. Another example is langauges using closures. Closures must be simulated on the JVM or CLR, so again, it will be slow.
It is a clear fact that the JVM and CLR suck for dynamic languages. I know, because I tried implementing a dynamic language on the JVM. Even with a bytecode compiler, it was slow. I achieved a phenominal speedup by rewriting the runtime in C, along with a native x86 compiler. So please, don’t give me the marketing hype about the JVM and CLR being multi-language. They are not. Maybe they allow minor variation of syntax (eg, VB.net -vs- C#) but they do not allow languages with radically different semantics to be implemented, without a huge performance penalty.
About the performance of scripting languages (PHP, Tcl, Perl, Python, Ruby). Look at http://shootout.alioth.debian.org/benchmark.php?test=ackermann&lang…, for example. PHP is a whopping 400 times slower than CMUCL, a Common Lisp implementation. On every single other benchmark, these languages rank near the bottom, always hundreds of times slower than good runtimes.
Don’t believe those benchmarks? Write your own. I can guarantee that these scripting languages will get their ass whopped every single time. This must be why their implementors are too scared to write the library in the language itself, and instead just have a huge interpreter written in C.
One reason these languages are slow is that they use reference counting for memory management. I’m not sure why, since a good garbage collector is not that difficult to implement. Consider a numerical loop in Python — the cost of incrementing/decrementing reference counts, and heap-allocating all those boxed integers, overshadows the numerical computation itself. A good dynamic language implementation should at the very least use tagged representation of integers to avoid heap allocations, or even have the compiler infer types and use untagged representations where possible.
If you want to push dynamic languages, that’s great, but if you start talking about toys like Python and Perl, you won’t be taken seriously… I mean, come on, look at those benchmarks.
“Think about that : The language IS the operating system ! ”
Forth has been that as well.
I’m not intending to write a FPS, OS or Database with Python, which would be totally insane. But they are fast enough for most normal apps and some games, and I don’t think c, c++ or java are as nice there. For bigger, heavier apps that need the speed I still have c, c++ and java.
But I’m not sure what you are trying to prove. Interpreted languages are slower then compiled languages? I wouldn’t expect anything else. But with parrot I do believe that Python, Ruby and co. will be applicable to more types of apps. Dose that mean I want to code only in dynamic languages? No, but man, Python and Ruby are fun like nothing else out there.
One reason these languages are slow is that they use reference counting for memory management.
No, ruby uses mark and sweep garbage collection.
It is slow though, but then usability is far more important than premature optimization anyway. Just code anything which is really time critical in C, and wrap that code so you can call it from ruby. The ruby C api makes that really easy to do.
John, first, if you prefer to use Python or Java or whatever, that is your choice, and there’s nothing wrong with that.
As for performance measurements, I was responding Bob’s post:
“”Also note that PHP and Perl are among the slowest of all language implementations.”
Where do you get this? I am just curious if you just pull it out of thin air or you have something to back it up. ”
I certainly never pull things out of ‘thin air’, and it was kind of rude for Bob to assume I did.
“No, ruby uses mark and sweep garbage collection.”
Is it a generational collector, like SBCL and CMUCL on x86?
“It is slow though, but then usability is far more important than premature optimization anyway. Just code anything which is really time critical in C, and wrap that code so you can call it from ruby. The ruby C api makes that really easy to do.”
You see, its possible to have a language that is high level *and* offesr good performance. It is quite sad that the scripting languages ignore the *decades* of research that went into making this possible.
A Lisp or Smalltalk programmer never has to write C and “wrap it”, they just write everything in the friendly high level language, without having to worry about a C library interface, C memory management, etc.
Beat that with a self contained platform.
Is it a generational collector, like SBCL and CMUCL on x86?
No, just straight mark and sweep. But it is well integrated with the C api, so you can mark any C structures which are still in use in the C wrapper code, during the mark phase.
A Lisp or Smalltalk programmer never has to write C and “wrap it”, they just write everything in the friendly high level language..
I maintain ruby bindings for the Qt and KDE apis. Would you propose re-writing both Qt and KDE (c. 1000 C++ classes, 25k methods) in lisp? For ‘real world’, non academic use it’s very important to be able to integrate a scripting language like ruby or python with C or C++ libraries.
Dynamic languages are productive and cool, but they have one major flaw. There is no way to put any intelligent intelli-sense to the object unless you actually run the application. And running the program might make everything a bit slower, and what happens if the program has an error? Then the intellisense is wrong.
I read somewhere back where someone does not make any typing errors. Well, cool, all the power to you. HOWEVER, for the millions of other coders intelli-sense has become a “must have” feature.
Java, and C# tend to be be good compromises between the pure dynamic languages, and pure compiled languages.
Check this out:
http://discuss.joelonsoftware.com/default.asp?biz.5.99489.4
There is no way to put any intelligent intelli-sense to the object unless you actually run the application..
You only need all that intelli-sense stuff because languages like C++/C#/Java are way too verbose. Why not design the language to be succinct and powerful in the first place, rather than bolt on a load of stuff after the event. The less you have to type, the fewer typing errors you’ll make.
There is no way to put any intelligent intelli-sense to the object unless you actually run the application
What’s wrong with working on a program while it’s running? It’s much quicker to fix errors if you don’t have to compile the code every time you make some minor change.
Java, and C# tend to be be good compromises between the pure dynamic languages, and pure compiled languages.
Java and C# aren’t dynamic languages. They have a fairly broken class model. For instance, no dynamic despatch on static methods, no open classes so you can’t add/change the behaviour of an instance once it’s instantiated, no equivalent of ruby’s method_missing or Smalltalk’s #doesNotUnderstand, classes aren’t first class types and so on..
What I try to say here is that the compiled code from a dynamic language does abide to many static typing rules.
Not necessarily. A lot of performance optimizations in dynamic languages come from type inference. Consider the following pseudo-code loop:
sum = 0
lst = fill_list()
for elt in list:
sum += elt
A good compiler could run an analysis, and realize that in this particular case, ‘elt’ would always be an integer, and so could replace the type-check and generic dispatch on the ‘+=” method with an integer-add instruction. However, the compiler has no way of passing that information to the JVM or CLR. If “sum” is typed as an integer, and ‘lst’ is a list of objects, the compiler will have to insert the type-check.
There are numerous other optimizations that you can’t do under the CLR or JVM. Many Smalltalk compilers perform an optimization where they cache the results of a generic dispatch at the callsite. The JVM and CLR don’t allow this sort of self-modifying code, and eliminate this rather important optimization.
If Perl is a toy language, cool. I can get things done quicker, and probably better for 80% (or more) of the stuff you would use Java for. I like Java, I use it at work. However, when it came time to create a web app to pull data from our Oracle database, I had it done in Perl in no time at all. If I need a change, it is a 5 minute tweak and I just surf to the page again to make sure I did it right. For small to medium sites, I would take Perl over Java anytime.
Not only that but I can do everything I need from A-Z for the systems I admin as well. One language that does it all for me. A toy? Cool, I play with it all the time. While Java is in my toy bin gathering dust.
Perl+Apache+Template Toolkit rules.
Well, since Slava said it, it must be true. Wait, I am reading an article about creating large scale e-commerce sites in Perl.
During the 2000 x-mas season the stats were:
200,000+ sessions/hour
2.5 million+ page views/hour
20,000+ orders/hour
It was the 3rd highest traffic site behind eBay and Amazon.
They used:
Perl
Apache
Oracle
Template Toolkit
Yeah baby!
And lest you think I am some Perl maniac, I like Tcl just as much (if not more) and use it for many things.
I never said dynamic languages are slow and toys. I was talking about *certain* scripting languages, which definately are slow, compared to *good* dynamic language implementations. But, you seem to be a Perl fanboy who can’t admit his tool sucks, so I won’t press the point further.
Wrong. I would be the first to admit Perl has problem, as all language implementations do.
You misread my post. You, in fact mentioned, Perl and Python as being toy languages and that is what I was addressing and not dynamic languages on the whole.
And I like Tcl better than Perl so that would make me a “Tcl fanboy” and I would happily take that “slur”.
RE: Slava Pestov
> You totally missed Rayiner Hashem’s point. Consider a
> language where you can call a method on any object. If you
> run this language on the JVM, there will be a reflection
> lookup each time the method is called. Java reflection is
> terribly slow. Another example is langauges using closures.
> Closures must be simulated on the JVM or CLR, so again, it
> will be slow.
I think *you* missed *my* point. I agree that the JVM and CLR totally suck on this. However, I think that this is a specific problem of the JVM and CLR, not of virtual machines in general.
RE: Rayiner Hashem
> sum = 0
> lst = fill_list()
> for elt in list:
> sum += elt
>
> A good compiler could run an analysis, and realize that in
> this particular case, ‘elt’ would always be an integer,
> and so could replace the type-check and generic dispatch
> on the ‘+=” method with an integer-add instruction.
> However, the compiler has no way of passing that
> information to the JVM or CLR. If “sum” is typed as an
> integer, and ‘lst’ is a list of objects, the compiler will
> have to insert the type-check.
Again, a specific weakness of JVM and CLR. A better general-purpose VM would allow the list to be typed as a list of integers, so the runtime type check could be ommitted.
I’m sepaking of a *really* powerful type system here, i.e. one that is much closer to a formal proof of correctness. You would have to be able to express Java-like types, parameterized types, null-ness of references, value ranges, and even expected results of functions on a value as the ‘type’ of that value.
The fundemental problem remains that the compiler knows things that it can’t always tell the VM. In a dynamic language, this is a problem. For example:
k = do_foo()
if(bar())
do_baz(k)
else
wumpus(k)
The question is: what do you type foo? If do_baz() and wumpus() both expect different targets (eg: one of type ‘a’ the other of type ‘b’), you have to type ‘k’ as a generic object. However, what if the compiler can prove that if bar() is true, k will always be of type ‘a’, and otherwise it will be of type ‘b’? It could then omit a typecheck and a generic dispatch in both cases. However, there is no way to convey this information in a static type system. The only way for the VM to allow this sort of optimization would be to allow unsafe casts, which is a major security problem. Further, you haven’t addressed the fact that the VM still dissallows self-modifying code (it has to — for security), which prevents some important optimizations.
All of this rigamarole, and to what end? What really is the purpose of a VM? In the best case, you’ll get the same capabilities as a static compiler (except you have to recompile for different architectures), only it will be slower and more complex.