[ruby-talk:9980] Ruby refs on Slashdot

FYI. See the original for much better formatting and to see the links.

Conrad

http://slashdot.org/article.pl?sid=01/01/23/1315220&mode=thread

    LWN Interviews Larry Wall
    Posted by michael on Tuesday January 23, @08:12AM
    from the laziness-impatience-and-hubris dept.

============================================================
Ruby on Slashdot.. neat. (Score:2, Interesting)
by helixblue on Tuesday January 23, @09:14AM EST (#38)
(User #231601 Info)
Nice to see a link that talks about Ruby on Slashdot, hasn't got much press
in America, but a lot outside of it. Check it out in any case, it's got this
4 year perl veteran swearing he will never write perl code again. Very
smooth OO, very clean syntax. Like, perl, but more professional, and like
python but less anal. From a perl perspective, it's got all the great quick
hack features, but a lot less clumsy to make the transition to a huge hack.
And a lot easier to maintain due to a consistent style and readibility.
Default local scope helps too. If your ever bored, checkout the link on Ruby
compared to some other popular languages on
http://www.ruby-lang.org/en/compar.html Not saying it's the end all be all,
but it's a great thing to try. The Pickaxe book is recommended as a lot of
the better documentation isn't in English yet. -- idling in #ruby on EFnet.
/ Thomas Stromberg
[ Reply to This | Parent ]

Re:Ruby on Slashdot.. neat. by helixblue (Score:1) Tuesday January 23,
@09:14AM EST
Ruby - great, but ultimately doomed by Ars-Fartsica (Score:3) Tuesday
January 23, @10:02AM EST
Re:Ruby - alive and kicking. by helixblue (Score:1) Tuesday January 23,
@10:48AM EST
1 reply beneath your current threshold.
Re:Ruby - great, but ultimately doomed by scrytch (Score:3) Tuesday January
23, @10:50AM EST
Re:Ruby - great, but ultimately doomed by Ars-Fartsica (Score:2) Tuesday
January 23, @11:37AM EST
I would say that Ruby and Python overlap greatly by renoX (Score:1) Tuesday
January 23, @12:04PM EST
Re:I would say that Ruby and Python overlap greatl by J. J. Ramsey (Score:1)
Wednesday January 24, @12:45AM EST
Re:Ruby - great, but ultimately doomed by kindofblue (Score:1) Tuesday
January 23, @01:51PM EST
Is it time to initiate a dialogue on Ruby? by kriemar (Score:1) Tuesday
January 23, @12:29PM EST
Re:Is it time to initiate a dialogue on Ruby? (Score:4, Insightful)
by maraist ([e-mail]) on Tuesday January 23, @02:29PM EST (#97)
(User #68387 Info) http://udel.edu/~maraist

I haven't used it yet (except to download and type out the quick examples).
Things I've noticed that I'm not crazy about:

I haven't found a decent debugging mode for it yet. It mimics perl in many
ways, but -d isn't the same.

They use "begin / end" instead of the uniform {}. This pisses me off because
of lack of emacs / vi matching.

Numbers are all objects, which hints at slower performance. In fact,
performance is said to be above that of python, but one can deduce it as
being slower than perl.

It is said to have a much more convinient C / C++ API, but that additionally
suggests that it'll have additional layers of abstraction, meaning slower
interface code (pure speculation). I have the same issue with the Perl6
direction.

It's supports multi-threading even if the OS doesn't, which obviously
requires interpreter threads. Depending on how they do this, it could be a
negative. (additional checks per ruby-op)

It uses mark-and-sweep memory, which is great for memory leaks, but my
initial impression is that it'll be slower than reference counting (since I
believe it requires wasteful periodic passes through memory.. Probably
through one of it's interpreter threads).

Being a perl advocate, I have no room to speak on this, but some of the
syntax seems odd - making use of punctuation marks, etc.

It's heavily OOP, and that isn't always the best solution to problems.
Granted, it's useful for things like x.length, but sometimes you want to
just length( @{ $some_gloal_name } ) to get the job done. I'll have delve
deeper to see how well they copied the TMTOWTDI philosophy.

They made a nice attempt to duplicate perl's interpolating strings through
the use of "xxxx #{var_name} xxxxx", which I definately like better than
python's c-like method: "xxxxx %s xxxxx" % var_name. Since if I wanted the
latter I could just use prints. Still, I can see the extra characters geting
annoying. (though there might be a compiler speed-up, since fewer variations
need be accounted for).

One of my favorite features of perl is it's code's searchability.. Want to
find a function, search on "sub xxxx". Want to find a variable: "$xxx".
(Though mangled perl variables can be a pain-sometimes). If nothing else,
it's a key for emacs to color on (which remarkably aids reading code). C,
Java, Python, and now ruby give this up. (Note: ruby does use $ and @, but
only for globals / member-vars, which only has minimal usage. Local's are
prefix-less).

I'm definately going to try it out. I dabbled with Python for a while, but
couldn't find a compelling reason to move over (poor use of anonymous
functions, couldn't find a way to functionalize 'use strict', etc ). I'm
expecting a similar final result with ruby, but you never know.

Lastly, I don't believe it's as tried and true as Perl. Ignoring for a
moment it's small but growing size 3rd party support compared to CPAN, it
was a devil for us to convince our bosses to continue doing web development
purely in Perl (as opposed to the more popular but less coder friendly
servlets). A good manager would most likely not entrust their clientelle to
such a bleeding edge technology. Perl's been on most every platform that
I've ever heard of (still waiting for palm). It is the epitomy of robustness
as far as I'm concerned. The only times I've ever core'd had to do with
c-libraries (which you can _always_ avoid; even if it means resorting to
IPC). I'd trust perl-code to c-code any day (assuming you had actual
developers on the job). Still ruby's defintaely got future potential.. The
trick is how do they differentiate themselves today so that they can grow
into tomorrow. They're not defining their own niche, they're piggy-backing
existing ones.

What they could do to really bolster acceptance is provide porting scripts
fom raw perl. They seem to mimic enough of the rough syntax (like reg-ex,
qq(..), etc), so it's bound to be possible. Due to the divergent memory
archetectures, it's doubtful tha
Read the rest of this comment...
============================================================