_why's version of this site was my first exposure to Ruby. I was a convert (from Java) as soon as I got to map.
%w{apple pear banana}.map {|f| puts "#{f} is a fruit."}
This experience shows one of the fundamental truths of software marketing, incidentally: anything you can do to reduce the barriers to trying the software out increases uptake dramatically. Eliminating the install is powerful, powerful stuff.
It showed me why I hate Ruby syntax. The above just looks horribly ugly. A mishmash of special characters. Not to mention special characters in strings (eugh).
The probability of an undetectable typo in the code you paste is pretty high.
Sure, it's not quite up there with regexp syntax, but it's getting close.
FWIW, I've been coding Ruby going on 7 years now (well over 100,000 lines of Ruby across all projects, I'd wager), and my memory estimates fewer than 5 instances of "undetectable typo". Generally, the typos I made and tried to run produced very obvious, visible and traceable symptoms (i.e. a precise and accurate stack trace).
I was asked in an interview once (by a skeptic that didn't know Ruby) if it weren't a problem that mistyping a variable name could produce a bug that would be difficult to detect and debug. I informed him that, in practice, it is essentially a non-issue.
There are two aspects of Ruby (among others, I'm sure) that help protect against the sort of hidden bugs you're worried about:
1) You cannot reference a variable that has not been defined yet. Example:
% ruby
supercalifragilisticexpialidocious = "something quite attrocious"
puts "I'm thinking of #{supercalifragilisticexpialodocious}."
^D
-:2: undefined local variable or method `supercalifragilisticexpialodocious' for main:Object (NameError)
2) Ruby will not silently or automatically convert or cast data types. (Where it seems to do so, in actual fact underlying library code is explicitly calling the conversion methods (#to_s, #to_i, #to_f, etc.)) Example:
> You cannot reference a variable that has not been defined yet.
That helps somewhat, but you can certainly assign to a variable you haven't defined. Detect that.
> Contrast that with, say, Perl....
If you'd used the warnings pragma, Perl would happily have warned you about any problems numifying the string. In this case, there are no problems numifying the string, so there's no warning.
(As Perl is an operator-oriented language, the use of syntax which provides numeric or boolean or string context on values indicates programmer intent.)
It's not just about potential bugs though. It's readability, maintainability etc. For me, the original code pasted is horrible in terms of readability. Sure, it's concise, but it's lots of small characters that you could misread etc.
"Sure, it's concise, but it's lots of small characters that you could misread etc."
To each his own, but have you spent much time coding Ruby and encountering this problem?
I ask because it's not a problem I've had or hear from people who have been using the language. It seems to be be an issue expected by people who have not yet spent much time using Ruby (much like concerns over the lack of static typing).
From a distance it may seems as though things would get confusing, but in actual practice this seems not to be the case.
Could be a selection bias, but I would like to hear from people who have truly used Ruby in earnest and stopped because of repeated annoyances.
Can you provide example code written in another language that accomplishes the same (element mapping) which you find easier to read or looks better? I'm not sure Java, PHP, Perl, C# or Python could offer an improvement, besides catering to a preference of keywords ("begin", "end", etc.) over non-letter tokens (parentheses, set braces, etc.). And string interpolation doesn't seem like it would be the source of either more or fewer bugs than string/variable concatenation.
Also bear in mind that, in Ruby, almost all blocks can be delimited with a "do/end" pair rather than set braces.
It's interesting because ruby is designed to be easy to read, and in my experience it's the programming language where I have less syntax errors compared to other languages like c, clojure, lisp, etc (which can be prevented 99% of times with an editor)
It doesn't look any easier to read that any other language to me. Looks harder to read than many. So if it is indeed 'designed to be easy to read', I think the failed.
Clever! But in all honesty, I was a little disappointed when I discovered that Ruby was not being emulated in JavaScript or something similar. Just bouncing the entered text back to a server-side instance of IRB instead...
Well, an official spec for Ruby is in the works and there's already one for JavaScript (ECMAScript). Someone is bound to build a Ruby VM in JS at some point and then it'll be trivial to build a site like this.
The performance will be horrible, of course, but once that happens some other person will come along and run a subset of Rails (or some other Ruby web framework) with an evented db backend on it (for async callbacks to the server over HTTP) to run an app in the browser.
Which would be pretty cool, though not useful. (But don't let that stop you, whoever you are!)
I can imagine a fairly clean mapping between languages. If the result of compilation was JavaScript code, to be passed on to the browser using eval(), the code would perform quite well.
So, assuming that I'm correct, what you would be left with is the one-time cost of parsing. And how costly is parsing generally? (I am keeping in mind that Ruby may not be general)
It would be possible to have a JRuby applet so everything would run within the browser but.. that'd involve having a multi megabyte applet to activate on the page and they kinda freak people out nowadays.
Some sort of Flash based Ruby VM that you can interact with through JavaScript would make it rather interesting though..
The problem with using a javascript-emulated version is that it'd be way too limited, unless the dev went out of his way to cover much of the ruby language. This way, you can try the whole thing.
JS emulated would be good if it was just a tutorial, but it's a bit more than that.
Type in "help", the tutorial that gets kicked off from that is pretty impressive. My Dad has been curious about programming and I think this is what I'm going to point him to.
That is not the point AT ALL. This isn't about knocking out one-off scripts to do useful things, it's about trying out the language to see if it's worth installing at all.
_why the lucky stiff did a lot for Ruby evangelism. This site combined with the Poignant Guide turned a lot of curious folks into converts.
I know this stuff despite being a Python fanatic. I have great respect for what _why did for the Ruby and programming communities in general.
I read somewhere that the problem of "syntax design", that is choosing how a language requires you to write it, is regarded as "solved", that is we don't need any more constructs or abilities in languages. Whoever it was said that the real problems remaining are speed and size and the other stuff.
I agree that this is the case, but only because Ruby exists. If you haven't tried it then really, please do, I think you'll like it.
Language design isn't a solved problem until we have a language that enables the average programmer to add any syntax they need. Lisp only comes close by punting and rubbing everyone's nose in the raw parse tree, and the average programmer ritually shuns it anyway.
Ruby doesn't even attempt to solve this problem. You can tell because if it didn't already have try/catch or begin/rescue or case/when, adding them yourself would be impossible.
%w{apple pear banana}.map {|f| puts "#{f} is a fruit."}
This experience shows one of the fundamental truths of software marketing, incidentally: anything you can do to reduce the barriers to trying the software out increases uptake dramatically. Eliminating the install is powerful, powerful stuff.