This is exactly what makes Rails a ghetto. A bunch of half-trained former PHP morons who never bother to sit down and really learn the computer science they were too good to study in college. BTW, this is true about Kevin as he’s an English major or something stupid (and it shows). http://web.archive.org/web/20080103072111/http://www.zedshaw.com/rants/rails_is_a_ghetto.html
Name:
Anonymous2012-02-23 0:50
All accusations towards Ruby are just ridiculous and are factually inaccurate! It is important that as a community we debunk these myths and unjustified criticisms. An even better road to take would be to provide examples of how computationally complex problems can be dealt with efficiently in Ruby, highlighting the best practices and the existing workarounds.
A religious community is emotionally easy to attack and may produce inopportune responses in defense of whatever has been questioned. Over the past three years I’ve heard a few bad things about Ruby and I’ve seen all sorts of responses, which in some cases were simply overreactions.
Ruby is a wonderfully designed language. The Ruby and Ruby on Rails communities have a lot of passion. We love our language, created by a very cool guy (and maestro of humbleness) in Japan. We love our framework authored by a Danish GAP model, and we really enjoy the spirit in the community. We have the best non-paid marketing department in the world. We started the revolution which is powering most of the new social websites out there.
Ruby on Rails is the single most important and valuable technical solution, language and tool for software problems.
Name:
Anonymous2012-02-23 0:58
Here's why one should be wise regarding 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 proc {|obj, *args| obj.send(self, *args)} or (0..127).each { |n| p n.chr }, considered beautiful. Another confusing Perl borrowing are postfix `if` and `while` (line = file.readline while line != "needle" if valid line) and quirky variable names (partially due to naive environment design): @instance_var, @@class_var, CONSTANT_VAR, $global_var, :sym, &proc, $~[1], $!, $>, $@, $&, $+, $0, $~, $’, $`, $:, $., $* and $?. 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]. If `a` and `b` are undefined, then "a = b" produces error, but "a = a" gives `nil`.
- Faulty syntax. Ruby cant distinguishing a method call from an operator: "a +b" can be both "a(+b)" and "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. Same with "puts s *10", which is parsed as puts(s(*10)). Ruby's expressions terminate by a newline and you have to implicitly state that the expression is not over, using trailing + or \. That makes it easy to make a dumb syntactic mistake by forgeting to continue line. It also encourages putting everything onto a single line, producing messy looking code. A good amount of your code will consist of "begin end begin begin end end..." noise.
- 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. 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.
- OOP: Matz had a bit too much of the "OOP is the light and the way" philosophy in him, in effect Ruby doesn't have stand-alone functions and Ruby's blocks can't be used in exactly the same way as usual closures. Even high-order functions are attached to objects and produce verbose code: "names.map { |name| name.upcase }", instead of simple "map upcase names".
- 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. Ruby introduces new variables by just parsing their assignements, meaning "a = 1 if false; a" wont raise an error. All that means Ruby can't detect even a trivial typo - it will produce a program, which will continue working for hours until it reaches the typo. Local and global scopes are unintuitive. Certain operations (like regular expression operator) create implicit local variables for even more confusion.
- "def method_missing(*args)" is a blackhole, it makes language semantic overly cryptic. Debugging code that uses method_missing is painful: at best you get a NoMethodError on an object that you didn't expect, and at worst you get SystemStackError.
- 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`. Some Ruby's features duplicate each other: print "Hello", puts "Hello", $stdout<<"Hello", printf "Hello", p "Hello", write "Hello" and putc "Hello" -- all output text to stdout; there is also sprintf, which duplicates functionality of printf and string splicing. begin/do/then/end, {} and `:` also play role in bloating syntax, however, in some cases, precedence issues cause do/end and {} to act differently ({} binds more tightly than a do/end). More bloat comes from || and `or`, which serve the same purpose.
- 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.
- Ruby was created "because there was no good scripting language that could handle Japanese text". Today it's mostly Rails hype and no outstanding feature, that makes the language, like the brevity of APL or simplicity and 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
Consider this: A pack of wild Rubyists.
Terrible, duck punching Rubyists nearing your webs. Trampling your hosts' CPUs. Raping your hosts' RAM.
And you can't do shit since they're terrible! The Rubyist leader grabs your LISP waifu and gives her his ActiveRecord.
The primal Rubyist finally dominate your webs. They throw gay parties at rails conferences and you are forced to read their language's comic book bible to find a job.
Such is the downfall of SICP.
Consider this: A pack of wild Lispers.
Autistic, lithping Lispers logging on your network. Trampling your CPUs with their interpreters. Raping your RAM with Emacs.
And you can't do shit since they're autists. The Sussman grabs your waifu and fucks her with his wizard cap.
The primal Lispers finally dominate your network. They watch 6.001 lectures on YouTube and you are forced to read their SICP.
Such is the downfall of K&R.
>>9
1. In 95% of cases, blocks are just single-shot callbacks, so the do ... end syntax is optimized for that at the expense of the minority case.
2. The proc keyword just lets you reify a block so you can pass it explicitly instead of implicitly. This is necessary if a method takes multiple block arguments. The weird part is that this isn't just a syntax change. Implicit blocks have a special calling convention and a special way of being passed on the stack that's inexplicably different from all other types of arguments.
3. Ruby doesn't really have functions. All values are objects and all objects have methods. The lambda keyword basically creates a singleton (anonymous class) object whose call method invokes a block. In practice this isn't different from proc in any useful way, except for certain edge cases involving Ruby's fucked up scope rules.
4. Curly braces are just alternative syntax for do ... end and the -> arrow is just an alternative for lambda.