From: Niko Schwarz Date: 2001-11-10T00:47:55+09:00 Subject: [ruby-talk:24769] Re: Why is ruby slow (compared to perl) Sean Russell wrote: >> instead, id say the real performant solutions are generally a bit slower >> than their clean equivalents, but thats another topic. i wonder how you could understand that sentence correctly *g*, (of course i meant "with" their clean eq...) > The code may have had better > design, but it was slower. I often find that with this sort of "good > design," you tend to get memory bloat, as well. You ever programmed with Java? I dont mean applets or other bullshit, i mean the real java programming language, which is allows creating best-designed GUIs and programs combined with good speed. When creating the Java API, the developers asked: What do we wanna have, a well-designed slow gui or a hacked fast gui? and then they looked at how computers are used: like 98% of the time ur CPU spends in idle state. It doesnt do anything. And for the normal tasks of a user, which are: managing data of some type, painting pictures, handling texts, watching dirty movies and sending hoaxes throughout the world, current CPUs are way too strong. Theres hardly a reason to have *real* fast guis. So the Java Programmers said, theyd create a developer-friendly SDK, that makes code re-useable and easy to maintain, that makes programmers life easier. and believe it or not: when given the choice i prefer java programs (though theyre not numberous..), because theyre usually lots more reliable than the native ones. and fast enough? how would i care? (ok, java has a serious problem about the start-up time, but thats another topic..) Note that here I talked only about swing, swing is quite a slow thing, java instead is not, eventhough it usually is well-designed. Java server-applications are just fast, and have no problem with being compared to native ones, i dont think a native tomcat would be as fast as the java one. why is that? because java says: let the application developer make the design, the VM developer cares about speed; and it works great. hotspots dynamic optimizations simply rule, the new increditive garbage collection makes life even nicer, and life with java is only nice. and your point about redundant code is pointless with hotspot, hotspot automatically inlines methods when its useful, hotspot does a lot of neat stuff. this approach will imho make code generally both faster and more stable, and its the only true approach. regards, nick -- Quigley's Law: Whoever has any authority over you, no matter how small, will atttempt to use it.