Getting used to Rails

Every new language is rough; you always view it through a filter of your past experience and that perspective is fundamentally unfair. My experience with other scripting languages are defined by Node/JavaScript and PHP. Those languages are imperfect in their own right but there are a few things about Ruby that strike me as unfortunate at best. 

The good part: Rails

Rails is very very well put together. It has become the standard of MVC and for good reason. The ability to layer interpreters, filters and the healthy suite of view helpers and a solid model pattern. Rails and Ruby is built with development in mind. The versioning system of Gems and the version manager/RVM is quite efficient and easy to maintain. The database migration system for keeping databases up to date is pretty solid and there are very few peers for migrations in other systems. 

The PHP systems in this space are Zend Framework and Drupal. Zend Framework is known in the PHP sphere to be too fussy and tempermental, and Drupal is rough and so overwrought in the internals that it forces you to stay at the admin level, and to accept a large and very opinionated set of conventions that are quirky at best. 

Rails stays at the code level, which I much prefer, but doesn't demand as much of an upfront investment as Zend Framework. 

Ruby

Ruby strikes me as a language that tries to do far too much at the linguistic level; it goes the Pearl route of adding a lot of language options in some places while remaining notation heavy at other places. One place this sticks out is the logic flow - the fact that you can use if and unless, and these clauses come in before OR after the blocks they filter, encourages very sloppy syntax. I really don't like seeing these clauses as suffixes to the clauses they modify. 

Also, the qualifier/end patter is very difficult for IDE's to parse well. (So far NetBeans is the best one I've seen which is sad, because NetBeans no longer supports Ruby/Rails.) Ruby takes DRY as far as it can go, eliminating semicolons, block braces and parantheses, further making parsing difficult. There is no visual indicator whether you are pulling a subproperty from an object, or a function that returns an object; user.id could be a variable that returns an object with an ID property, or an object with an ID property. Where, then, is it purdent to put try/catches? You can call this encapsulation - I call this obfuscation. 

But like a tube of toothpaste, after simplifying one part of the language, they complicate others; case in point, strings and tokens. is 'foo' equal to :foo? mostly not, but sometimes yes. One thing is for sure, it's wierd syntax. And while they use the simple dot notation for object properties, user.id, accessing hash properties uses clunky pearlish hash notation, as in user[:id] and {:id => 3}.

While I understand that :tokens help the parser optimize code, it feels extremely retrograde. trading 'id' for :id feels like trading a single saved character for a host of opportunities for obscuration. 

On the plus side, Ruby's class system is thoroughly modern, with inheritance, mixins, lambdas, etc.  I do think the @class_var syntax feels like yet another case of using funny characters where they are not helpful. Reinterpreting "this" into a character token is another example of inventing a convention that doesn't move the language forward. I also don't think locking instance variables into the private scope is a very developer friendly way of handling scope. While the practice of accessor methods is ideal, it forces premature formalism which discourages OOP adoption. But this isn't a large proportion of the whole OOP system. 

So in sum, as thorugh as Ruby is, it feels to me like it tries too hard, and unnnecessarily leans on special tokens like @, : and => or verbalisms like end where convention like dots, braces and JSON syntax alreay exist, and feel a lot less heavy.