Performance matters, but for whom?
By user12610627 on Dec 27, 2008
Computers that were able to deal just with numbers evolved into computers with byte-addressable memory, flat address spaces, and pointers. This was a natural evolution reflecting the growing set of problems that people were solving. C, reflecting the genius of Dennis Ritchie, provided a minimal model of the computer that had evolved over 30 years. C was not a quick hack. As computers evolved to handle all kinds of problems, C, being the minimal model of such a computer, became a very powerful language to solve all kinds of problems in different domains very effectively. This is the secret of C's portability: it is the best representation of an abstract computer that we have. Of course, the abstraction is done over the set of real computers, not some imaginary computational devices. Moreover, people could understand the machine model behind C. It is much easier for an average engineer to understand the machine model behind C than the machine model behind Ada or even Scheme. C succeeded because it was doing the right thing, not because of AT&T promoting it or Unix being written with it.
Yukihiro Matsumoto (inventor of Ruby):
In my point of view, efficiency and productivity are the same thing, because we focus on programming efficiency, not runtime efficiency. I don't care about runtime efficiency. The computer goes faster and faster every year, so I don't really care about performance. Actually, I care about performance when I'm implementing the Ruby interpreter, but not when I'm designing Ruby. The implementer should care about performance, but the designer shouldn't. If you care about performance, you will focus on machines in design instead of on humans. So you shouldn't focus on performance in design.
Stepanov definitely influenced me at the time (early/mid nineties) and I got plenty of mileage out of STL (in spite of c++ compiler limitations) and I found (and still find) STL amazing. I actually never used Java professionally until 2000, tbh - like Stepanov I felt it was unusably slow for my purposes (and it was). However, by 2000 Hotspot had achieved a very impressive level of performance.
Although I can't say the same for Matz and Ruby, I think it's interesting to juxtapose their points of view.
Although I've never actually written a Ruby program, the processing requirements for such must be quite low - since Ruby's runtime performance is unconscionably poor by Stepanov's standards. I guess I can imagine a web server application which is supported by mostly static cached documents and dominated by the file system synchronization of a transactional database could be such a low-performance use case, and that is where Ruby seems to have found a niche.
Programming language compilers are "translators", which we require to translate from human expression to that of the machine.
In my opinion, designing a programming language is always a "mediation" between the needs of the human programmer and those of the machine - contrary to Matz.
Now, given the fact that runtime performance is a factor to the end user (i.e the customer - and the customer always comes first), it cannot simply be sacrificed when required to make the programmer's job easier.
OTOH, if the programmer's burden is too high, runtime performance may never come into question, since you'll fail to even deliver a product.
The design of F3 (now JavaFX script) was largely based on the concept that many perceived programmer ease-of-use features are not primarily related to the typical implementation techniques of so-called scripting languages, but rather to their purely linguistic characteristics - i.e. their correspondence to the language of the mind, rather than that of the machine - and that such features could be provided thanks to the Java platform without severely compromising runtime performance.
Object-orientation is one such feature - it corresponds to the way we conceptualize the world around us and allows us to navigate such concepts in a way that is natural to us.
Interestingly, Stepanov completely rejects this, focusing instead completely on the "generic" processing that applies across collections of objects at very high levels of abstraction.
Admirably in my opinion, Stepanov steadfastly refused to sacrifice the needs of the machine, yet nevertheless produced with STL a level of programming expression which was quite lovely to the human programmer (given that former constraint and those of the C++ language).
The beauty of the Java platform in my opinion has been that it does the best job of mediating these needs, overall, and that largely explains its success.
Java has many detractors on both sides - the C/C++ world thinks it's too slow, the Ruby-and-various-other-scripting-languages world that it's too hard to use. And everybody knows it's long been too big and monolithic.
Now, no one language or platform can be all things to all people. However, it's my belief that the Java platform - in spite of its wide use - is actually still under-utilized for many important use-cases - given current available alternatives.
Obviously, it's clear that I think one of those is the world of high-performance graphics and multimedia, which is currently still dominated by C and C++.
Surprisingly (or maybe not?) a similar tension exists among my colleagues here at Sun with respect to JavaFX script. There are those who actually think they're designing a language to serve (from their point of view) some lesser form of "web scripter" for whom they (incorrectly) perceive performance doesn't matter. Conversely, there are those who are acutely aware of the performance requirements of graphics and multimedia, who are dubious of the necessity and viability of JavaFX script (although they tend not to be forthcoming with any credible alternative, other than "just use Java" - but the fact is that's been done, and the barrier to entry is still too high).
Since I happen to think both points of view are wrong, it's my job to prove that, and to bring us together, and that's what I'm currently working on.
Although its scope is limited, in terms of finding something closer to the right level of "mediation" of performance/programmer-ease-of-use/functionality for this problem domain (and based on the Java platform), a good place to start is here.