From: Conrad Schneiker Date: 2001-01-28T01:10:02+09:00 Subject: [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 (maraist@hotmail.com) 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... ============================================================