3 ms·
That sounds more like, "its design interferes with fast implementation" to me. If there's a major difference between that and "it's slow language", I'm really c
by silentbicycle 17y ago
That sounds more like, "its design interferes with fast implementation" to me. If there's a major difference between that and "it's slow language", I'm really curious what it is.
- stcredzero 17y agoYou missed a meta-level. The design doesn't interfere with having a fast implementation. It interferes with implementing a fast implementation. "It's a slow language," implies that there's something special about Ruby that precludes (relatively) fast implementation. There's nothing special about Ruby like this. Ruby is a very nice remix of language features that existed before. Getting a language to be fast can require many iterations. Ruby's syntax is a high barrier to entry to implementers, so fewer eyeballs have been looking at the problem. Contrast this with Smalltalk. http://news.ycombinator.com/item?id=619398 http://news.ycombinator.com/item?id=619398 Smalltalk was designed to be quickly implemented by a single programmer. Implementing a "Bluebook VM" was treated as a rite of passage for support engineers for at least one of the vendors. As a result, people have implemented many, many variations on Smalltalk. (Including an VM with built-in OODB, another that can compile down to a C++ compatible DLL indistinguishable from one written in C++, another that ran on the old Palms, one with optional typing, and many others.) I think it's fair to say that writing a Ruby VM is probably an order of magnitude harder.
- silentbicycle 17y agoGot it. FWIW, I don't particularly care for Ruby; for that style of programming I usually use Lua, whose syntax and semantics are quite simple. The existence of LuaJIT (http://luajit.org/luajit.html http://luajit.org/luajit.html) supports your argument, I think.