Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Try Ruby (in your browser, now with 1.9) (tryruby.org)
72 points by jmonegro on Jan 8, 2010 | hide | past | favorite | 39 comments


_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.


Wouldn't it make more sense to use each rather than map for that example?

    %w{apple pear banana}.each {|f| puts "#{f} is a fruit."}
    => apple is a fruit
    => pear is a fruit
    => banana is a fruit
Map is for creating a new array with each of the results in it, like this:

    %w{apple pear banana}.map {|f| "#{f} is a fruit."}
    =>["apple is a fruit.", "pear is a fruit.", "banana is a fruit."]
which would return an array with each of the strings in it.


Quite right.

    puts  %w{apple pear banana}.map {|f| "#{f} is a fruit."}.join(' And ')


It was useful for me in an opposite way :)

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:

    % ruby
    count_str = "8"
    count = count_str.to_i
    puts count < 9
    puts count_str < 9
    ^D
    true
    -:4:in `<': comparison of String with 9 failed (ArgumentError)
Contrast that with, say, Perl:

    % perl
    use strict;
    my $count_str = "8";
    my $count = 0 + $count_str;
    print $count < 9; print "\n";
    print $count_str < 9; print "\n";
    ^D
    1
    1
Combine all of the above with good testing practices, and your bugs turn out to be quite detectable on the whole.


> 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.


Ruby seems similar to Python in this regard. (Though Python seems a bit more concerned about special stuff in strings.)


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.


Not being able to backspace (at least on my MacBook with 10.6) is a deal breaker here. As much as I'd like to be, I'm not a perfect typist.


Backspace works here on my 10.6 Macbook in both Safari and Firefox. Though, Command-w to close it doesn't work for me.


Yeah, for whatever reason the command key doesn't register on the page


The javascript key handlers are absorbing them. Outlook Web Access does this too (and it drives me crazy there).


Backspace doesn't work on Opera too. Up arrow should bring forward the last line typed ---- that doesn't happen here.


Doesn't work in Chromium for me.


Backspace works for me. Mac safari 4.0.4


Backspace doesn't work with Chrome on Windows 7. Firefox is ok though.


It appears to be a Chrome (and Opera) thing.


This is bizarre - works just peachy in Vista under IE7. Go figure!


I've got to admit that the 1.9 sticker and the "BETA" text don't really blend in with the existing look of the site.


Yeah, too many fonts.


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)


I believe a Ruby VM is already in the works, but my cold addled brain can't google fu right now.


That would be HotRuby, http://hotruby.yukoba.jp.


Try-javascript-emulated-ruby?


You forgot the '.org' :-D


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.


Interface acts odd on Debian+Webkit+Chrome4.


way too slow.. i'd rather just fire up irb


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: