The latest that I have endeavored to use, is Ruby. More specifically, a website-creation framework known as Ruby-on-Rails.
This language and platform takes the prize: It has been the greatest black-hole of time, the greatest source of frustration I have ever associated with a programming platform.
Not least amongst the frustrations, is the plethora of people who say they like it. Perhaps that is a phenomenon that results when a technology becomes fashionable for whatever reason – enough so such that everyone using it, is already sitting next to someone else who is well-used to it. I’m only being half-serious of course. I believe it is partly because I come from a systems-level software engineering background, with no small amount of experience with full-bore capable languages like C++, C#, Ada, and Java. I think perhaps I have developed a mental outlook whereby I depend upon the language to be well-defined, explicit and clear. With C#, for example, I can also look up where a given class or method comes from, how it expects to be used, and what it gives me. Always; even if it is poorly commented – I can at least find out how it is defined at the syntactic level.
Not so with Ruby. Variables may not exist until they are assigned to, and it is rarely clear where they come from. My toolset has no ability to jump from usage to definition, as you do in Microsoft’s Visual Studio. The definition of the language itself, is bizarre. And I don’t mean that in a good way. It’s not just a different syntax: the design of the language itself seems disjointed and ugly. What books I have found, what bits of online tutorials — are all leaving out huge portions of the story.
attr_accessible :variable1, :variable2
What does that do? Does it declare two instance variables? Or does it say that, if those two variables ever did happen to exist, that they would be assignable?
That looks ugly as shit. Compare that with how you declare three instance-variables in C#:
public int _count = 0;
protected string _name;
Here, I have used a convention whereby you can instantly know that something is indeed an instance variable because it starts with an underscore (not a requirement, just one popular convention). Your variables have a type. They always have that type (unless it’s a dynamic variable, but that’s a different story). The best feature of static typing is that if you misspell it somewhere when you attempt to use it, or just neglected to declare it at all – the compiler immediately tells you. What the compiler does not do, is watch you fumble and tinker and fumble and google and get frustrated, while it chuckles smugly.
With C#, you can see where these come from. What type they are. What value they’ll have if not assigned yet. And there is no question of how to refer to them.
With Ruby, how do you use an instance variable? Say you are inside of a class MyClass instance method. Do you use variable1 ? self.variable1 ? @variable1 ? @@variable1? self#variable1 ? :variable1 ? or self[:variable1] ?
Yes, I did find some clues to some of those – but not a consistent, clear answer that worked without a lot of trial-and-error.
The syntax is horribly counter-intuitive. If you have an instance variable, denoted by @name, and within a method you assign a value to it but neglect the leading at-symbol, you have instead created an entirely new, local variable. No warning is giving – you simply have a bug that you will hopefully discover in your runtime testing.
You can create programs with Ruby. But I would suggest, Ruby (nor Rails) is not a tool for creating programs that need to actually work reliably.
Very important tip: Use a virtual machine (VM) !
Since I needed to use Linux as the development platform anyway, I created a virtual machine for this purpose. This is a good policy in general, for development. I use VMware Workstation 10, and in this case loaded it with Ubuntu 13.04. I used Sublime Text 2 for the text editor, and Thin for the development web server (Webrick evidently is broken).
I believe one reason Ruby-on-Rails (RoR) became popular was because it does provide some nifty generators for creating a minimally-functional CRUD program based upon some model. That is a good feature, because it jump-starts you with a working (although no-where near a presentable solution of course) website, that you can use as a starting point. You enter a command in the Linux shell, and it makes it for you. That was the only way I could create a program: I ran their scaffold generator to create an initial cut. Several times. Started over. Searched for other tutorials that actually worked (most don’t!!!). Then once I had a program that run without error, I took a Snapshop (VMware’s term for capturing the exact state of the virtual-machine) of my VM at each stage when things did work, so that I could revert back to it. Whenever things became a hopeless dead-end, I took notes, dumped the freak’n thing and reverted back to the most recent (working) Snapshot.
With such a vague, unclear language-definition at the core, how does a system survive? But wait – there’s more!
There are many parts with RoR. The tool-stack seems quite large, and then you must bring in plugins and gems to accomplish anything. With RoR you have to be very conscious of versions. Most parts do not work with the latest versions of the other parts. So you have bundles, or gemsets, or environments, or sandboxes. That is cool, to have the idea of a Gemset file which specifies what to bring into your project, and exactly which version. That, of itself, is more than just a nice feature – it’s essential to do anything. After you have spent weeks of long hours trying to discover what works with what (and which of the many parts simply do not work, never will, and perhaps never did) – the Gemset file saves you by freezing in place your selection of gems and versions of those gems.
That seems to be the essence of RoR. It is a stack of parts, each and every one of which has it’s own personal project and community of developers behind it. If you are extremely lucky, enough of those parts will work, to arrive at a working solution. The language itself is very terse. And if you like concise definitions – that might please you at first, until you realize it is so unclear and vague that it makes no subjective sense unless you are intimately familiar with this specific platform.
I found that everything I coded, was basically copy-pasting snippets from samples. Which, although occasionally useful, were also the greatest source of frustration. For example, Stackoverflow has a lot of Q&A. Most of the Answers did not work. Or were flat-out typed incorrectly. Not a few — MOST. On that website I do not see how to down-vote an answer, which is a shame because most are clearly shit. That is a whole separate story: why anyone would consider it acceptable to respond to someone’s technical question, by typing up code-snippet without seeing whether it works yet, is beyond me.
Another problem might be in the nature of open-source software. There are too many script-kiddies shoving gobs of code into the project – code of very crappy quality. They often don’t document anything. Or they write incorrect documentation. And it’s frequently not compatible with each other. Perhaps because they have no skin in the game, – they’re throwing it in for free anyway — there’s little incentive to invest time to make it a quality product. There is no software engineering — it’s just gobs of junk code.
That phrase “You get what you pay for” is not always true. But with RoR I believe it does apply. This is not a toolset you want to employ just because it is free. I highly recommend you explore something like ASP.NET-MVC with C# and Microsoft’s Visual Studio: it is finely engineered and you acquire skills with a fine state-of-the-art programming language that handles many roles with aplomb. Or Java, or Python on Django.
With C#, for example, you’ll type more characters on the keyboard. The language is not as concise as Ruby. You have to declare your variables, and decide which data-type they’ll be. But only a fool bases his comparison on that alone. It’s better to type a few more characters, and have a programming construct that is clear and unambiguous, that you can come back to later and maintain and change and make use of, than to have a terse little set of characters that mysteriously works because you spent an obscene amount of time tinkering and googling to get it to.
I have noticed that there are websites claiming to measure the popularity of programming languages, based upon the amount of Google traffic or number of questions on Q&A sites. I would suggest this is misleading. When I was first learning Java, or C#, I found it very easy to pick up a book, play around with the tutorials, and dig into creating stuff. With a clear syntax, clear semantics, and a little bit of Googling – it wasn’t long before I was quite comfortable with every aspect of the language and could create fairly complex software. With RoR the opposite situation prevails: a massive amount of googling is necessary for virtually every step of the way. I cannot overstate this point — RoR is so unclear and confusing that you will spend an obscene amount of time googling, trying tips and techniques that are incorrect, before making any headway.
So, Ruby-on-Rails: the worst possible choice for a web-development platform. The scenario where it can work, I would say, is where you already have someone who is already quite familiar with it (preferably more than one, so that they can team up on it). I’m guessing that would probably be someone who starting learning programming with Ruby as their first language, so that they did not start out with a mental outlook that resisted Ruby’s quirky syntax and lack of solid parts. If you’re more than just a small one-project startup — if, for example, you have multiple software products to build or maintain, you may find that your RoR developers are worthless for your other projects – because RoR is all they know. With Java, or C# you have a language and toolstack that you can redeploy for a lot of other needs. This is not an authoritative assessment of course — it’s just an impression from a first experience with it.