Alexander A. Stepanov (inventor of C++ STL): 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 horrendous 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 access of a relational database could be such a 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 features 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 – but 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. 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++. Ruby