>>3
Ruby
- Ruby indulges obfuscation: Ruby has no keyword/optional arguments, so you'll have to use hash parameters as a substitute. This is an idiom that comes from Perl. Ugly, Perl-looking code, like 12.5.integer? or (0..127).each { |n| p n.chr }, considered beautiful. Quirky variable names (because of bad scoping design): @instance_var @@class_var CONSTANT_VAR $global_var &proc $~[1]. If A is [1,2,3] and B is [10,20,30], then A+B is [1,2,3,10,20,30], when you probably wanted [11,22,33]. A good amount of your code will consist of begin end begin begin end end...
- Defective syntax. Ruby cant distinguishing a method call from operator: "a +b" can be both "a(+b)" and "a + b".
- Slow: JIT-compiling implementations exist, but they're still slow and incomplete, due to Ruby's complexity and bad design, which make Ruby difficult to optimize compared to other dynamic languages, like Lisp or Smalltalk. For example, Ruby has to accomodate for somebody in another thread changing the definition of a class spontaneously, forcing compiler to be very conservative. Compiler hints, like `int X` from C/C++ or `declare (int X)` from Lisp, arent possible either.
- Ruby's GC is a naive mark-and-sweep implementation, which stores the mark bit directly inside objects, a GC cycle will thus result in all objects being written to, making their memory pages `dirty` and Ruby's speed proportional to the number of allocated objects. Ruby simply was not designed to support hundred thousand objects allocation per second. Unfortunately, that’s exactly what frameworks like Ruby on Rails do. The more objects you allocate, the more time you "lose" at code execution. For instance something as simple as 100.times{ ‘foo’ } allocates 100 string objects, because strings are mutable and therefore each version requires its own copy. A simple Ruby on Rails ‘hello world’ already uses around 332000 objects.
- Non-othogonal: {|bar| bar.foo}, proc {|bar| bar.foo}, lambda {|bar| bar.foo}, def baz(bar) bar.foo end - all copy the same functionality, where Lisp gets along with only `lambda`
- Ruby (like most other scripting languages) does not require variables to be declared, as (let (x 123) ...) in Lisp or int x = 123 in C/C++. If you want a variable private to a block, you need to pick an unique variable name, holding the entire symbol table in your head. This also means that Ruby can't even detect a trivial typo - it will produce a program, which will continue working for hours until it reaches the typo - THEN go boom and you lost all unsaved data. Local and global scopes are unintuitive. Certain operations (like regular expression operator) create implicit local variables for even more confusion.
- Ruby as a language supports continuations via callcc keyword. Ruby's callcc is incredibly slow, implemented via stack copying. JRuby and IronRuby don't have continuations at all, and it's quite unlikely they will ever get them. There were also support breaches in mainline Ruby, where Ruby 1.9 has not supported continuations for a while. If you want your code to be portable, I'd suggest not using Ruby.
- Syntax problems: Ruby works hard to distinguish method calls from operators, and variable names from method names. Unfortunately, there's no way it can get it right all the time. In this case, "a +b" is parsed as "a(+b)". Remove the space to the left of "+" or add a space to the right of "+," and it will be parsed as an addition. This has nothing to do with indentation. And for what it's worth, Ruby now parses "a +b" the way you'd expect. Which way is that?
- Mostly Rails hype and no outstanding feature, that makes the language, like the brevity of APL or macros of Lisp. "There is some truth in the claim that Ruby doesn’t really give us anything that wasn’t there long ago in Lisp and Smalltalk, but they weren’t bad languages." -- Matthew Huntbach