On Fri, Sep 28, 2007 at 12:37:11PM +0900, M. Edward (Ed) Borasky wrote:
Which is why they teach data structures in computer science class. It’s
all about fast search, I think. That’s one of the big gripes I have with
“lazy” interpretation. If you don’t do stuff until you have to do it, it
only pays off if you end up never having to do it.
My understanding is that lazy evaluation can actually be of distinct
benefit to simplifying attempts to code for concurrency. I haven’t
really investigated the matter personally, having little call to write
software that would benefit from concurrency, but I imagine that will
change in time. That being the case, I will surely enjoy the benefits
lazy evaluation at that time, should my understanding of its benefits to
concurrency not prove to be based on faulty information.
subjects. People have “always” prototyped in “slow but productive”
completely in a compiled language or going bankrupt buying hardware.
There are a great many use cases for Ruby where there will never come
time that runtime performance is that important. Probably 80% of the
code I write, minimum, falls into that category. Under such
circumstances, a reasonably quick startup time and a decent algorithm
make much more of a difference than long-running performance and a
or bytecode compiled language with a reputation for performance.
That doesn’t mean I wouldn’t like to see Ruby’s performance improved
significantly in the future. It just means that if Ruby never
the performance of C, or the long-running performance characteristics of
an optimizing VM like Java’s, it will in no way hamper my ability to put
Ruby to good use without having to plan for the day when I have to
rewrite everything – because that day will never come in at least the
vast majority of cases.
In fact, in cases where rapid coding up front in a way that requires a
high level language is very important, and high performance software
become very important given time, my preference would not be to
in Ruby (or Perl, or UCBLogo, or whatever) anyway. It’d be to use
something like OCaml, with excellent performance characteristics in
binary compiled form, decent long-running performance in bytecode
compiled form running on its VM, and convenient source code access using
the interpreter with the ability to test stuff on the fly using its
“toplevel” interactive interpreter. Use a tool to suit the job at hand.
A lot of the time, in my work and play, that tool is Ruby – and will
never require a rewrite in a “faster” language.