Hacker News Reader

Comment by _pferreir_ | Hacker News Reader

> Ruby is amazingly primitive

What? In what sense in Ruby primitive?

When you're comparing MRI to GHC? Painfully simple GC. Simplistic green thread model (with recent changes, but still fundamentally crippled compared to GHC). Mixed metaphor abstractions in core and stdlib. A very ad-hoc development culture in core. Limited debugging and source-level warning support. No JIT or useful AOT compilation. A thrown-together syntax.

Some of these aren't weaknesses. Others are.

Then I guess he should have said "MRI is primitive", or "Ruby interpreters are primitive". As it is, it looks like a typical language fanboy rant more than an objective technical argument.

If he's making explicit reference to CoW unfriendliness, there's not much ambiguity there.

"primitive" is an awkwardly chosen word with negative connotations... I suppose it is in the sense that it doesn't do type inference (or reasoning about types at all, for that matter). Like a Lisp it simply executes what you write without any validation beyond syntax checking.

The idea is that Haskell's type-based, lazy approach allows for a more high-level approach of specifying what you want instead of how you want it executed. I'm not sure it always succeeds in that, but that's another matter. It's an interesting language nevertheless, with elegant code, but if I need to build something quickly I fall back to Python (which is "primitive" in the same sense as Ruby).

> Like a Lisp it simply executes what you write without any validation beyond syntax checking

But then in Common Lisp when something goes wrong you drop into the debugger and can look at your code's state. In python/ruby my program just goes poof! and I get a backtrace. Then I'll either have to add statements around the suspected cause of the bug to inspect the environment or restart with a debugger and retrigger the bug.

The Common Lisp Way(tm) is also available in Smalltalk; I think those systems give you the tools to deal with their dynamic nature, while python and ruby (and others as well) do not.

And then languages with more static type systems can give you the tools to deal with their static nature. In Haskell that would be powerful type inference and expressive type system.

Well, dropping to the interactive prompt is a statement or two in Python. You could do that when something goes wrong (for example, in the inner, or outer exception handler of your application).

There's also tools for Python where you can browse/modify state of a program remotely through a debugger, for example winpdb, others included in IDEs.

Overall, dynamic debugging support is quite good, if you are willing to search around a bit. But probably not as good as CL or SmallTalk, if they're especially engineered for these kind of things. I don't know enough about them to comment on that.

> Like a Lisp

You know about Typed Racked and possibly other efforts, right?

http://docs.racket-lang.org/ts-guide/

Well not really. I had a vague sense that there are extensions that add typing, but not more. My experiences with Lisp are mostly limited to SICP. Thanks for the link.

No problem. Generally, talking about Lisps in this context is not a very good idea - I couldn't find the link, but I remember that in the comments on lambda-the-ultimate someone demonstrated equivalence of static type systems and lisp macros by providing compile time guarantees that then-discussed static type system gave. I'll try to find this discussion later, or maybe someone has the link ready?

I'm just guessing here, but maybe he is not talking as much about the language itself but about the (default) VM? AFAIK, the VM of Ruby (but also Python and node.js) do not support parallel execution of threads (which is usually solved by starting multiple VMs and using an extra cache).

Compared to the VMs of Haskell, Erlang or the JVM one might call this primitive.

(I definitely wouldn't call it amazingly primitive and I am aware there is JRuby / Jython)

MRI 1.9 support parallel execution of threads.. It's using OS threads. No more green threads.

Even MRI 1.9 does not support parallel execution of Ruby code. JRuby and MacRuby do, however.

Reply on news.ycombinator.com