I just looked at the syntax of RoR - it's possibly the worst programming language I've ever seen! It combines the worst of Java, VB, and Ada - specifically:

1. Jumbled abstract quasi-english commands like "puts" and "gsub" and other cryptic garbage.
2. Symbolic representations of actual language, like "<" instead of "extends" and "|..|" instead of "as".
3. Use of C-style braces {..} to represent command groups but VB-style line-break command terminators (instead of semicolon command terminators). WTH?
4. %w(one two three) = ["one", "two", "three"]. How do I shorthand ["one two", "three"]? Rubbish.
5. 12.5.integer? <-- great way to introduce ambiguity to the meaning of an unencased period.
6. 3.times {puts "Ruby sucks!"} <---- just in case you weren't confused by unencased period before...
7. ... you can also use it to reference methods: puts "Ruby sucks!".upper

That's enough for me... I got through about that much, threw up, and deleted that stupid free RoR tutorial.

This is one language that should be put out of its misery IMO.

Not to mention that as referenced above, the VALUES 12.5 and "Ruby sucks!" are inherently interpreted as OBJECTS.... WHOA NELLY talk about OVERHEAD!!!

I'm tempted to push this thread to the front page

I'm going to have to admit I never thought I'd see trolling on WDF... But ok. Let's address these as if they're reasonable complaints rather than an incredibly obvious case of different tastes.

If you really dislike those, no one's really stopping you from renaming them... In fact, Ruby supports that quite happily. gsub isn't the best-named method, true, but then again I use that rarely, and it's one of relatively few such methods. In fact, it's probably one of the worst-named methods. puts isn't particularly hard to figure out (put string... Is it really that tough for you?). In the end, this is the unfortunate Perl influence dribbling in. Much of the Ruby API is better thought out anyway. For renaming them, by the way:

It's less typing and it's used relatively infrequently. Not to mention the fact that just about any language that wants to support functions as first-class objects with minimal typing has to resort to some sort of shortening (function(param1, param2) {} for anonymous functions in Javascript, anyone?). But wait, let's look at your wonderful proposed syntax:

With separation between the parameters and the other stuff done how? Let's see the Smalltalk way:

But don't worry, it's okay, when you get closures in Java you get this pretty thing:

Oh how I look forward to it...

Plus if you know just about anything about inheritance, < makes perfect sense as an inheritance indicator.

Ah. You're one of those. i.e., those who speak without investigating. Try this on for size sometime:

As it turns out, curly braces aren't for all command groups, they're for blocks (aka anonymous functions). And typically they're used for single-line blocks, with multiline blocks delimited by a do..end. There's a more significant difference between {} and do..end (precedence), but it isn't relevant here.

In fact, the Ruby parser will let you break a statement over two lines if it's evident that the statement isn't over yet:

You... Don't. Shorthands are for common cases, you don't introduce them for every special case in the world. That would be idiotic language design...

Not terribly ambiguous. If it's followed by a number, then it's either a float or invalid. Makes sense, since identifiers can't start with a number in just about any language.

Also, do you find yourself using naked floating point numbers in your code often? That tends to be bad practice, which is why Checkstyle tends to catch magic numbers like that in the Java world. Personally, I can't think of a single instance where I've sent a message to any literal floats.

... That isn't particularly confusing. You're sending the `times' message to the `3' object. The block is just another parameter...

Also? That's what you were doing above, as well. Everything in Ruby, as in Smalltalk, involves sending messages to objects. That *is* Ruby. That is the paradigm. You came to Ruby looking for Java, I think, and found something else and were surprised. Apparently you don't react well to surprise...

Umm... Yes. Welcome to the world of *actual* object oriented languages. You can go back to C if you want, but you seem to more or less like Java, where "Ruby sucks!" would also be an object... Yeah, overhead. If I were writing myself an ultra-optimized differential equation solver, that would be a problem.

In short, your distinction between values and objects is invalid in a language like Ruby, Smalltalk, or even Python.

This'll throw you for a loop, though, if that annoys you: nil is also an object -- a singleton instance of NilClass. You can even add methods to it if you want.

EDIT: A quick point I forgot to make. Language design is just about always a matter of preference. Ruby has definitely borrowed some nasty aspects from Perl, but they're gradually being phased out as it develops. The stupid one-letter globals are the best example, but there's already a package to make them full English names. As with any language, there are problems with Ruby. It just so happens that most of the things you mentioned weren't problems, they were results of your completely misunderstanding the very paradigm of the language. If you don't understand that, there's no way you're going to like the language. That's like saying ML's syntax looks like garbage before you've understood how pattern matching works and what exactly the syntax facilitates -- what paradigm it supports.

Well at least one person loves RoR.

I'm only going t address 3 points... I concede that I haven't read enough about the language to be able to contradict the rest:

1. Renaming built-in methods?!?! OMFG that's even worse than having poorly named ones, like to_i (toInteger). Then, not only will your employees have to know Ruby's cryptic names, they'll have to learn your whole set of similar names and which map to which. And God forbid you get two developers using two separate renames for built-in methods!!! That's a nightmare waiting to happen. Grated, I know you don't have real-world experience working in an environment where you have to share code with dozens of other programmers, but you will one day, and you'll see then where I'm coming from.
   
   
2. The ability to create statements like 12.5.method is definitely poor architecture. It's ambiguous. In the very least, it should be (12.5).method, though I'm not a fan of the auto-objects, so I'd prefer something like Float(12.5).method, a verbose, yet unambiguous way of saying what you want your code to do.
   
   
3. Shorthands... I guess that's my primary issue with the whole language is the shorthand... if you can't shorthand every possible use of a method or construct, you shouldn't be able to shorthand it at all. And then, if you could shorthand any case, the shorthand should be the only way of doing something. This is my biggest issue with PHP. A programming language should be nothing if not consistent. Introducing various ways for people to do the same things only creates ambiguity and confusion in a larger scale project.

I have to admit I'm amused you think I haven't worked on larger projects, as I have... In fact, I've worked on a J2EE-based framework with a bunch of other people that was meant to be used by a bunch more other people. I don't dislike Java without having used it, I dislike it even though I program in it a fair amount

And yes, I'm very well aware of the potential for abuse in several of these features. This is why so many people feel liberated by Ruby, however: it puts trust in the programmer(s) that they know what they are doing, and that they know it well. This is a burden and a freedom we really aren't used to in the software world, because few languages put forth that trust. And yes, it's certainly dangerous in larger-scale projects where you have no guarantee that everyone is as good as you are. This is why you'll always hear me say that I don't like Java, but I know that it needs to exist in order to deal with the fact that not everyone is a good programmer. Java (more so than a lot of other languages, actually) is crippled intentionally -- things like the lack of operator overloading, for example -- for fear that it's `too dangerous'.

In the hands of a great programmer -- and there are many of them in the Ruby world -- Ruby can give you incredibly good results, because of all those features that make it `dangerous' and more. Placed in the hands of a poor programmer, it can give you disastrous results. But Matz (the creator of Ruby) decided that his philosophy would be to trust the programmer. After all, there are already plenty of other languages that don't.

Still, I should point out that the Ruby community in general puts a very large stress on readable code and on unit testing and on many other aspects of development that make it safer that often aren't stressed as heavily in other communities. Discipline is encouraged by the community, even if it isn't enforced by the language. The fact that three different levels of testing are included in Rails should be some testament to that.

If you're looking for another language that gives you nearly all the flexibility of Ruby and has the same `if you're a poor programmer, you can really mess things up' characteristic, but that hasn't been well used (i.e., used with discipline) until very recently, look at Javascript.

The biggest problem with this post is the title is incorrect! None of your complaints have anything to do with ruby on rails, everything you mention (be it wrong or right) is specific to ruby syntax, none of which has anything to do with ruby on rails in the slightest.

Your argument is equivalent to saying CakePHP sucks, and then proceeding to list a number of gripes you have with PHP syntax. The solution however is very simple, if you don't like ruby syntax, don't use ruby

I am going to come down on smoseley side here. This is just my opinion, but this quote of shadowfiend highlights why I don't even want to get into the depths of Ruby.

It reminds me of PERL. You can be so incredibly clever in PERL. But I have found that I end up being the person who has to come back to the code a year later and figure out whats going on.

Personally, I don't want a language to be clever. I don't want it to be liberating. I just want it to be simple! Symbols, redifining things, ambigious line endings. It reminds me of all the things I don't like about PERL.

It is just personal opinion of course; a matter of taste.

I rarely meet a coder who is happy working on another person's code. Everyone seems to like to rewrite things.

Slashdot recently linked a blog post about why Ruby will push Java to die of old age. It seems relevant to this discussion.
http://littletutorials.com/2008/05/2...a-die-old-age/

The last thing you will hear me argue is that Ruby is a silver bullet. I've picked up a couple of languages since Ruby, in fact, and I have no intent of stopping.

Your fears of Perlisms are, of course, quite justified -- this is indeed a danger of Ruby. But as I pointed out, the truly fascinating thing about Ruby is the community that has developed around it -- community which has gone to great lengths to integrate testing into their process (see autotest), to play with new ideas around testing (see rspec), to develop frameworks with testing baked in (see Rails), a community which does not hesitate to start anew if they feel something is getting too clever (see the motivations for the creation of merb). When you read books and blog posts (those of prominent bloggers, at least), you find pragmatism and maintainability is often at the core of their development. Ruby allows you to reach for readability and actually get close (not something specific to Ruby, mind you -- Python, amongst others, also does quite well in this domain).

The few posts I've made on my blog about Ruby have, amusingly enough, actually been about getting clever with the code. But I've tended to emphasize that my explorations were more for entertainment than for anything else.

Ruby can be dangerous, yes, but the community guides you towards avoiding most of the truly dangerous aspects, and it seems to be developing continuously away from the dangerous things.

I know very little about Ruby, having downloaded a PDF tutorial at one stage but having never had the time to peruse it... but what I would say is that aliasing commands etc. doesn't necessarily make things harder or less intuitive: it's all about ensuring that there's adequate documentation.

Those who've used Oracle's PL/SQL may have heard of an industry "guru" called Steven Feuerstein... I went to one of his seminars many years ago which advocated hiding the actual database design behind functions, enabling you to change the entire database design whilst leaving the application itself alone.

Steven's typical PL/SQL code might, therefore, be something akin to...

His argument was also that any PL/SQL developer could be taken on and become productive straight away because they didn't need to know anything about the database design, simply the business rules which could be in a reference manual.

Sean

I think the tool, in this case the language of ruby, is irrelevant. Its possible to write bad code in any language, it's also easy to pick holes in any language given some knowledge.

Sure some languages may make it easier to write bad code but I don't see that as a fault of the language, its a fault of the bad programmer who doesn't know when they are writing bad code. Its the job of the programmer to understand the language they are using and know how to use it well while avoiding any of the pitfalls of the language.

The thing about ruby is that it's much more like free-form poetry. There's few rules, endless options and relies on the creativity and intelligence of the author. Much of what makes ruby an amazing language is the ease of creating DSLs and the ease of metaprogramming. RSpec (a testing framework) is a great example of how the language can be transformed to your needs:

I've worked with a lot of development teams using .NET, J2EE, ColdFusion, PHP, and Ruby. From my experience, Ruby is a horrible choice for firms that hire less-than-the-best programmers. Mostly because it's so easy to go sour. J2EE and .NET are far better choices for this since it forces you to do things very explicitly (at the cost of productivity & creativity). However, in the hands of talented programmers, Ruby is like gold. Beautiful code can be written quickly and practically bug-free in comparison to "average" development teams using other langauges.

Also... Rails is not ruby. Not at all