Ruby 1.9.1 Released 226
Janwedekind writes "Yuki Sonoda yesterday announced the release of Ruby 1.9.1 (Ruby Inside coverage with lots of links). The VM of Ruby 1.9, formerly known as YARV, was initiated by Koichi Sasada and has been in the making for quite some time. Ruby's creator Yukihiro Matsumoto has already presented many of the upcoming features in his keynote at RubyConf 2007. Most notably, Ruby 1.9 now supports native threads and an implementation of fibers. A lot of work also went into encoding awareness of strings. The 1.9.1 version is said to be twice as fast as the stable 1.8.7. It will take some time though until the majority of existing Ruby extensions get ported to 1.9."
hmmm... (Score:3, Funny)
No wifi, garbage collection not as good as Lisp; Lame.
Re: (Score:2, Informative)
No wifi, garbage collection not as good as Lisp; Lame.
Why was this modded as flamebait? And what's that WOOSHing [slashdot.org] sound?
I am afraid, there is lack of direction for Ruby (Score:2, Insightful)
According to this video [confreaks.com], there is lack of direction. This is by Dave Thomas [wikipedia.org], and important figure in the Ruby world.
On a side note, I will use PHP on my servers before touching Ruby since I see no advantages for using it over PHP.
Re: (Score:2)
My company tried to make the switch and could find enough developers, could find enough module support and just couldn't get the same functionality for RUBY as with languages that have larger communities. Plus under large loads, it
Re: (Score:3, Interesting)
You do realize neither Ruby nor Rails is an acronym, right? Ok.
The only argument for it in the past for web dev is RAILs and there are plenty of MVC frameworks for PHP now including PHPulse, Cake and Codeigniter.
And those don't compare well [slideshare.net], even to Rails, certainly not to Merb.
And Merb is going to be merged into Rails.
under large loads, it buckled
Hardware is cheap. Couldn't you throw more at the problem?
Re: (Score:3, Insightful)
Hardware is only cheap if someone else is paying for it. Why spend money you don't have to? AMazon and other big companies have already come to that realization. When I worked there a year or so ago it was impossible to get new hardware- not because they were cheap, but to encourage you to use the hardware more efficiently. The end result- a lot more use of virtualization for small stuff, a lot more thought into efficiency of services, and millions saved. Smaller organizations won't save millions, bu
Re:I am afraid, there is lack of direction for Rub (Score:4, Insightful)
Hardware is only cheap if someone else is paying for it.
No, hardware is cheap, relative to programmer time. Moore's Law only reinforces this. In fact, you're making my argument for me:
Why spend money you don't have to?
Let's suppose it takes me half the time to code it in Rails than it does to code it in PHP, but requires twice the power to run. And let's suppose I make minimum wage.
Before it even comes close to costing more to run the hardware than it does to run my salary, you're already running six or seven extra-large instances. Go look up the specs for an extra-large instance. And keep in mind, that's additional -- that assumes the optimized version requires six or seven of those, and my inefficient version requires six or seven more.
You can run the numbers yourself, but it ultimately tends to work out the same. And all of that assumes the Ruby version is slower -- and, following my link above, it really isn't.
Smaller organizations won't save millions, but they'll save a significant chunk of cash.
Smaller organizations, I would think the "just throw hardware at it" argument makes even more sense. The speed of a nonworking app is irrelevant. The speed of an app serving a dozen programmers and testers, before public release, is similarly irrelevant. By the time you're getting hundreds or thousands of requests per second, you're probably making enough money from ads alone to cover the costs -- but while you're still "only" getting dozens of requests per second, a single Rails server might work just fine.
Now, I agree, throwing hardware at it is not a good long-term solution. The good long-term solution is to optimize the better systems. However, investing in a demonstrably worse architecture to gain a little performance -- maybe -- in the short term, does not seem like a good move.
Not if you're hosted! (Score:2)
But I really wanted to take issue with the insinuation by Foofoobar, which I have heard so many times, that Ruby is "not scalable". Even if he meant Rails, not just Ruby, he is just plain wrong. This scalability "issue" has never been a real issue at all... as long as you didn't mind getting your hands a little dirty in server configurations.
Look at some of the "top" 100 Ruby on Rails sites, and try to tell me again that Ruby "doesn't sca
Re: (Score:3, Insightful)
How do you know the tons of manhours put into optimization work won't cost you more than the added hardware?
Re: (Score:2)
Besides, inefficient code will add up almost exponentially as your load increases. So you could throw hardware as a stopgap, but eventually (if you get large enough) you would have saved a
Re:I am afraid, there is lack of direction for Rub (Score:4, Insightful)
> Besides, inefficient code will add up almost exponentially as your load increases.
Eh?
We're not talking about poor algorithm selection. We're talking about using a slower language rather than a faster language. Unless you deliberately adopt a "slower languages deserve slower algorithms" mentality, you're talking about a linear increase in hardware.
In that case, doubling the hardware requirements in exchange for even a 25% cut in coding time is going to be a huge boon for your company. If writing in a cleaner, more elegant language makes the code base smaller and easier to read, those senior developers are going to have a much easier time finding the bugs and the bottlenecks. Plus, if you can write the thing that much faster, your developers are going to have a lot more fun.
Since we're talking specifically about Rails here, the first optimization pass is usually A) finding pages and partials that can be cached, and B) tweaking your ActiveRecord queries so that the database grabs all the records it needs on the first pass. Both are simple to do, and once you've accomplished them it's going to be quite a while before a normal site is going to run into scaling issues.
Re: (Score:2)
We're not talking about poor algorithm selection. We're talking about using a slower language rather than a faster language.
You assume that the same algorithm used in two languages will have the same big-O characteristics for CPU and memory consumption. That is not true.
For instance, some languages can optimize tail recursion into a loop, and some cannot. For those that can, the memory consumption for a given algorithm may be constant. For those that cannot, the memory consumption may be O(n).
Re: (Score:2)
I hear that answer alot from the RUBY community. Why would I as a business be expected to switch to a language that requires twice as much hardware? What you MAY save with software dev speed, you now lose with day to day server maintenance.
The key to good engineering is to simplify because the more parts, the more chance of failure. So throwing more hardware at the issue when similar languages such as PHP, PERL and PYTHON can do it with far less
Re:I am afraid, there is lack of direction for Rub (Score:5, Insightful)
Choice of programming language actually matters, and dismissing languages you haven't used much is foolhardy. If this isn't obvious to you, this article [paulgraham.com] may prove enlightening.
Re:I am afraid, there is lack of direction for Rub (Score:5, Insightful)
No, it really doesn't. What matter is availability of libraries, and your personal profficiency with the language. Given C and a regex library, I'll write better, cleaner, and faster doing string parsing than I would in perl. Why? Because I've used C and C++ every day for the past 8 years. Even though I use and know perl and regex is built into the language, I make more mistakes in it due to using it only a few times a year. And yes, I've actually tried this- I was 5x faster in C with the regex library. Do the test again with a perl maven, and I'm sure the opposite result would occur, even if you gave a problem that's more traditionally a C thing.
Now there are some languages that better suit individual people than other languages, due to the way they approach problems. Lisp is good for people who think very mathematically. C is good for those who think in a very step by step manner. OOP is good for people who think in terms of models and interactions. But you'll always be more efficient in a language you know well than one thats new to you.
Which isn't to say there's no reason to learn a new language- you may find one that fits you a bit better, especially if you learn a new paradigm like functional. But you'll never solve a problem quicker by using a language you aren't as familiar with, unless a library for a major piece of functionality exists in that language but not yours.
Re: (Score:3, Insightful)
That approach makes sense for small jobs, but for projects that take more than (say) two months, it makes more sense to choose a roughly suitable language, even if your proficiency is lower.
Also, for any code that isn't throwaway code, you have to assume that some unknown person will eventually inherit and maintain your code. Under that assumption, it's more important for the language to be appropriate for the task than for the language to be convenient for the initial programmer. You wouldn't want to inh
Re: (Score:3, Insightful)
Your maintenance point is good. For that reason alone I wouldn't use C for a web front end (back end service sure, not a front end), because the vast majority of people they'd hire to maintain it wouldn't be experts in it. And for any team project its not your best language that matters, but the best language of the team as a whole.
I disagree with your time argument though. If anything, the time just makes it more important to use what you're familiar with. If you're talking about something taking 1 hr
Re: (Score:2)
I agree with your points. That said, the PCRE library seems quite sweet and I could probably live quite happily with it. Sure, Perl has advantages because regexps are built into the language and don't need quoting etc.
(-: And that from someone totally opposite of you; I wss never really happy with C++ but do Perl for fun. :-).
Re: (Score:2)
Lisp is good for people who think very mathematically.
Which aspects of mathematical thinking is it that is well aligned with Lisp?
What I think characterizes mathematical thinking (as opposed to programming thinking) is the declarative and/or pure nature of math: variables don't change, and there's no notion of time.
I think a pure functional language, such as Haskell (or at least pure code) would fit better with mathematical thinking, because it has the same unchanging nature that math has.
I'm guessing that a pure logic programming language would also make a go
Re: (Score:2)
Question for you:
Which is greater:
I think you will find that the answer is "it depends". Specifically, it depends on how long it takes to learn the new language, how much more productive that makes you, and how many projects you do. Assuming that a new language makes you more productive, if you do
Re: (Score:2)
Not at all. You're assuming that it really will be faster to do a project in $newLanguage. I disagree- unless there's some library that doesn't exist in $oldLanguage, the productivity of languages at equal levels of experience are equal. I have never in my life seen a problem made simpler by changing languages rather than downloading a library. If you want to dispure my point you need to prove the assertion that it isn't so, not just throw some pseudomath in a post.
Re: (Score:3, Interesting)
To date for alot of people and companies, RUBY was hype (and this has alot to do with the community that hyped it). Now th
Re: (Score:2)
On a side note, I will use PHP on my servers before touching Ruby since I see no advantages for using it over PHP.
If you see no advantages to using it over PHP, you obviously haven't looked very hard.
Off the top of my head: Ruby has better syntax, a better object model, runs faster (really [slideshare.net]), better standard libraries -- Rails aside, Ruby tends not to pollute the global namespace with bullshit like mysql_escape_magic_quotes_no_really_I_mean_it_this_time...
PHP's advantage? Lots of unimaginative programmers like you know it, and it's slightly better at mixing code and data, since it's really just a Turing-complete templat
Re: (Score:2)
The old tales about being able to do things faster and with many fewer lines of code in Ruby are not just fluff. For example being able, in RoR, to take the submission from a 40-element form on a page, and put it in your database with just "my_object.create(params)" is pretty sligging frick, if you ask
Re: (Score:2)
Well, in Cake it's '$this->Model->create(); $this->Model->save($this->data);'. As examples go, that's not very convincing.
Re: (Score:2)
I have now seen the video you linked to, and I can't noticed where he said Ruby lack direction. He said in fact that Ruby is great as it is, what he want to see however, is that new ideas for Ruby experimented on as forks rather than tried within the mainline Ruby. I think the video was quite good and worth seeing even though it last 47 minutes!
The parent I believe is incorrect in using that video to claim there is a lack of direction.
Why does it need a "direction" anyway? (Score:2)
The evolution of Ruby has been extraordinarily fast, considering that the whole language is only around 12 years or so old, and only became somewhat popular 3 or 4 years ago!
Sure, certain additions to the language might be welcome. Compiler and speed improvements would be welcome. But I don't get this whole talk of "direction". WTF?!
Now, if that discussion is abo
Re: (Score:2)
If you look at the languages with "direction" that you mentioned... what are the directions? You said it yourself. BASIC -> wastebasket. Object Pascal -> wastebasket (Which, IMHO, is really sad because Delphi was worlds ahead of Visual Basic until they dropped the ball. But where has it gone since?)
I think my point is: C did not have "direction", and it is doing fine. Ruby may not have "direction", but it's doing fine. The ones with direction are all propr
Unicode? (Score:5, Interesting)
A lot of work also went into encoding awareness of strings
That's quite a fancy way to say "a lot of work went into making dealing with strings and encodings as messy as possible".
So far, Ruby 1.9/2.0 is the only high-level language I know of which allows strings within the same program to be in different encodings (attaching a reference to encoding to every string). For double fun, the encodings need not be compatible with each other (not even with Unicode). This might also make Ruby the first language in which string comparison and concatenation are not well-defined for two arbitrary strings (as you get an exception if encodings are incompatible). Just wonderful - imagine writing a well-behaved library which does any sort of string processing with input parameters with these constraints...
Re: (Score:2)
Cocoa and CoreFoundation, though not as high level, do something similar.
Re: (Score:2)
Yeah, but all Cocoa and CoreFondation string encodings can be mapped to Unicode, it's possible to access any string object as Unicode characters, and all comparisons are effectively done in the Unicode character set. You never end up with two strings for which the comparison results are undefined, which I think was the GP's point. (The GP may or may not actually be correct - Ruby could be just as good as Cocoa/CF for all I know - I'm a C/C++/Objective-C guy and don't really know much about Ruby.)
So? (Score:2)
How should your string compare work? All similar characters in all popular encodings should map to each other? Hmmmm... that would be a pretty damned big code base to handle all those permutations. Maybe as big as the rest of Ruby.
Re: (Score:2)
Well that's what Unicode is for - you can map all* characters from all text encodings to it, do your processing in one universal character set, and convert to the required encoding for output. That's how Java, .NET, Cocoa, CoreFoundation and even Windows CE and NewtonOS do things.
*yes, I know there are a few characters from Big5-HKSCS that aren't in Unicode, and the Apple logo from legacy Macintosh text encodings isn't there, either. But for 99.999% of cases, Unicode contains the character.
Re: (Score:2)
Of course, what kind of strings you "normally" use could be handled in your internationalization configur
Re: (Score:2)
, etc. is how it should have read.
Re:So? (Score:4, Interesting)
An ASCII string can be mapped to a Unicode string. For each byte in an ASCII string there is a matching Unicode symbol.
How should string compare work? Well for simple ==, I think it should fail if the encodings are different, as they really are different. It can also fail if the two strings encode the same Unicode but in different ways (this is possible in some encodings).
There can however be a more complex call that converts both strings to Unicode and compares them. One huge problem with most current imlementations, including Python, is absolutely brain-dead (and "politically correct") handling of invalid UTF-8, where invalid encodings throw errors, which makes use of UTF-8 actually impossible for non-trivial programs. Instead it should never throw errors. Error bytes should represent something unique in Unicode, one popular proposal is U+D8xx (which is also an "error" in UTF-16).
A problem Python (and a lot of other programs have) is that they think "Unicode" means "some sort of encoding where each Unicode symbol takes the same space". This requires 21 bits per symbol, the only practical way to support this to use 32 bits. Almost immediatly they run into difficulty in that Windows uses UTF-16, so they punt and use UTF-16, basically abandoning their entire idea. They should instead use UTF-8 which has enormous advantages: UTF-8 errors are not lost and can be translated differently when finally used (ie for display turning them into CP1252 is better, but for a filename turning them into the above error codes is better), all other encodings (which are byte based) can be stored in the same object, and no translation is needed when you load UTF-8 data. Also UTF-16 (including invalid UTF-16) can be losslessly translated to UTF-8 and back, so there is no problem supporting Windows backends either.
Re: (Score:2)
Re: (Score:2)
Ruby is not limited to UTF-8, though that is the default. But that is my point. If you wanted to implement a "universal" string compare that would map all valid characters in Unicode to every encoding available to your system, you would have a monster on your hands. Not all Kanji character encodings are Unicode.
Re: (Score:3, Interesting)
Perhaps you need to spend time trying more languages; you'd learn not only that other languages have done this, but that many of them later rejected the idea and moved to, typically, a pure Unicode string type with a separate non-string type for working with sequences of bytes in particular encodings.
Re: (Score:2)
Perhaps you need to spend time trying more languages; you'd learn not only that other languages have done this, but that many of them later rejected the idea and moved to, typically, a pure Unicode string type with a separate non-string type for working with sequences of bytes in particular encodings.
One of my hobby is research of the history of PLs, but I guess I never ventured that far back to stumble into it. If you could give any examples of languages that did the same thing, I would be grateful.
Otherwise, I agree that the only thing that makes sense today from a pragmatic perspective is an all-Unicode string type.
Re:Unicode? (Score:5, Funny)
Php also allows strings to use different encodings within the same program. With the extra twist that php don't keep track of the encoding, so if you want to find the number of characters in a string, you the developer must know the current encoding of the string, and then call the right method, based on which encoding the string has.
Sometimes I think that the developers of php just take all the bad things in other languages, and say "I can make a worse implementation of this."
Re: (Score:2)
Php also allows strings to use different encodings within the same program. With the extra twist that php don't keep track of the encoding, so if you want to find the number of characters in a string, you the developer must know the current encoding of the string, and then call the right method, based on which encoding the string has.
That's rather different, and it's also how C/C++ work. On low-level, that's how anything works, really - a java.lang.String, for example, is really just an array of 16-bit ints at heart. Where the difference appears is when you start performing encoding-aware operations on strings - case-insensitive comparisons, lowercase & uppercase, and so on. At that point, the language operator (or the library functions) that do that have to decide how to figure out the encoding of the string. The most common one to
Re: (Score:3, Insightful)
I think 90% of users will end up with Unicode, and different encodings are importand only in some countries and in some usages (like Japan).
As I used 1.9 a little, and also strings, I can't see this is being a mess or introduces incompatibility.
The whole multi-encoding system was introduced into Ruby, supposedly, to handle those "some countries and some usages". The problem is that it is very hard to write reusable libraries which actually live up to it when there's no guarantee about any input encodings. Say my function gets a string; what operations can it safely do with it? What if it gets two strings from different sources? What if it also gets a text stream? If you've read the Ruby 1.9 mailing list, you'd probably seen Tim Bray's complaints a
Re:Twice as fast... (Score:5, Funny)
They don't need to be compettive on performance. They just need to improve performance to "barely tolerable slow" as opposed to "intolerably slow".
Re:Twice as fast... (Score:5, Informative)
Here is jRuby [codehaus.org] using java VM , Maglev [gemstone.com] using Smalltalk VM , IronRuby [ironruby.net] using MS
Re: (Score:2)
Re:Twice as fast... (Score:5, Informative)
Re: (Score:2)
No.. just it's last SEVERAL incarnations that have been slow. That and a bunch of empty promises of how it will be faster and more scalable. One of these days they may deliver but by that time the other languages will most likely hav doubled THEIR speeds.
Re: (Score:2)
... This is how Java is fast.
Java people always say Java is fast, but if Java is fast, why does EVERYTHING written in Java seem so slow? Do Java people just look at benchmarks and not ever look at real-world uses? This is a serious question. I'm constantly hearing that java is fast, and consistently seeing only (OpenOffice, Eclipse, ANY Java "applet" online) java being hideously slow?
"If it walks like a very very slow duck..", etc.
Re:Twice as fast... (Score:5, Informative)
JRuby is an interpreter, written in Java. It does not compile Ruby to Java bytecode.
Incorrect. I certainly DOES compile Ruby to Java bytecode. Read the blogs of Charles Nutter, John Rose and Ola Bini for more information.
Re: (Score:2)
...and currently modded "Informative." Yay Slashdot.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
So in other words... if you want something decent and fast, use Java???
Pretty much, yes. Welcome to the 21st century.
Ruby/Python in JVM/CLR not a Silver Bullet (Score:4, Informative)
The typical situation is that something like JRuby or Jython are implementations of a dynamic language in Java/C#/etc. instead of in C/C++, but they have the same architecture as the C/C++ engines. This leads to about the same performance - the Java VM does excellent JITing, but as we know, it brings Java into about the same area as C/C++, not faster.
So, these implementations end up being about as fast as the original C/C++ ones (but they have various other advantages, which are their real value).
The latest-generation JavaScript engines - and we are talking about the last 6 months here! - are very different in their architecture. They use techniques like trace trees and hidden classes, along with native code generation using JITs specializing in JavaScript, to generate performance that can, in some cases, be closer to C/C++ than to Python/Ruby.
The PyPy project has been saying this all along, in fact - that to make dynamic languages fast, you can't just implement them in the JVM or such and expect 'magic' to happen with that VM's JIT. It doesn't work that way. Even if you JIT an architecture that does hash table lookups or type checking for each assignment, performance will be poor; the JIT can't fix your algorithm. Fixing the algorithm is exactly what latest-generation Javascript engines like V8 and TraceMonkey do.
Re: (Score:2)
I'm no compiler/interpreter expert, but AIUI the JRuby folks (some of whom are now with Sun) are actively working with the JVM folks inside Sun to add dynamic-language optimizations to the JVM.
I don't know if this extends to "fixing the algorithm", but it seems like it could. It's early days.
Re: (Score:2)
It isn't even clear how to create a generic JIT for all dynamic languages. For example, the latest JavaScript engines are great for JavaScript, but as Python and Ruby are even more dynamic, a different approach might be needed for them.
Re: (Score:2)
You can use C with JRuby too, using the exact same interface [headius.com] as MRI and Rubinius.
Re:Twice as fast... (Score:4, Insightful)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=yarv&lang2=php [debian.org]
Re:Twice as fast... (Score:4, Funny)
Being "roughly competitive" with PHP isn't saying much...
Like saying "I'm basically as knowledgable as Joe the Plumber"
Re: (Score:2)
I think the reason for the comparison is:
1) both are scripting languages.
2) People just assume that PHP is scalable. It runs Wikipedia, and lots of other huge sites. If Ruby can be compared favorably to PHP, then it's hard to argue that it's "too slow" to base a usable framework off of.
3) Rails people tend to have a bit of a grudge against PHP people. Play nice, children!
Re: (Score:2)
It means that people who rely on PHP can no longer use speed as a reason for continuing to use it.
How about this, then? (Score:2)
It's roughly competitive with Python 3
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=yarv&lang2=python3 [debian.org]
Re:Twice as fast... (Score:4, Informative)
You know, you have a point. I think all dynamic languages could probably learn something from the recent Javascript speed-up projects...
Except Ruby isn't slow [slideshare.net].
And yes, I am happy about it being twice as fast, because it was already fast enough.
Re:Twice as fast... (Score:5, Insightful)
Except that slideshow is comparing the performance of popular frameworks for different languages. So they're showing that Rails is an efficient framework. That's a perfectly valid point to make (the language makes it easy to write a better algorithm, or maybe the framework is just more efficient), but it doesn't say anything about how fast the code is executed.
I switched from Perl to Ruby as my everyday sysadmin and glue language, and I use it pretty extensively. I love Ruby, but I won't try to handwave away its faults. In my usage, it's undeniably, dramatically, slower than Perl. We're talking order of magnitude here, not marginal stuff that only shows up in benchmarking.
A script to parse a huge, complex data file sucks ten times as many CPU cycles to do the same work. For what I do, that's OK, because the ten minutes to run the job is completely dwarfed by the development time saved by using a sane language.
Re:Twice as fast... (Score:5, Informative)
I still do Perl.
Half the reason is that Perl is a bit insane and breaks all language design rules -- but still works. That makes it fun. The other half is that the community is so good; CPAN is a result of that and, also, you don't have so much of that disgusting hype (like you just commented on); like you, I'd rather not be identified with a community doing that.
Ruby do look sweet and Python seems usable (if a bit boring). But with the "Perl Best Practices" book becoming so popular and Moose (et al), I can't motivate a switch. The largest problem with Perl today IMHO is that it takes a bit more time and energy to learn.
Re: (Score:2)
We don't really disagree, but I'd quibble with a few points (In OO, the Moose/Mouse stuff seems to beat OO for all mainstream languages as of today; what a twist! Closures are cool and useful. Also, Perl 6 -- at last -- seems to grow into something really, really exciting.)
As I wrote, a good part of the reason I like Perl are the smart and interesting people in the community; I'd be plain embarrassed to stand with a crowd that do that kind of hype. (I'm not really sure it's the Rubyists that are those bor
Re: (Score:3, Interesting)
Except that slideshow is comparing the performance of popular frameworks for different languages.
I believe it also does a comparison of a raw Rack request versus a non-cake PHP page.
I won't try to handwave away its faults.
Neither than I -- only pointing out that most people aren't even doing benchmarks. It's just accepted that "Ruby is Slow". I'm not saying it's fast, but I am saying that when you say things like this:
We're talking order of magnitude here, not marginal stuff that only shows up in benchmarking.
It might be nice to have some simple examples and numbers to back that up -- besides just factorial. They'd also be great to establish this point:
For what I do, that's OK, because the ten minutes to run the job is completely dwarfed by the development time saved by using a sane language.
If you're comparing a ten-line Ruby script with a hundred-line Perl script, and t
Re:Twice as fast... (Score:5, Insightful)
It has always been 'fast enough' for appropriate programming problems. If Ruby is too slow, you're in the wrong problem domain to use Ruby.
Note that there is, and can never be, OneTrueLanguage(TM).
Efficient development is all about playing to the advantages of the development tools available to you. Complaining about weaknesses is usually indicative of a lack of understanding.
Re: (Score:2)
It has always been 'fast enough' for appropriate programming problems. If Ruby is too slow, you're in the wrong problem domain to use Ruby.
Note that there is, and can never be, OneTrueLanguage(TM).
Efficient development is all about playing to the advantages of the development tools available to you. Complaining about weaknesses is usually indicative of a lack of understanding.
Very true. Should not stop you working on them, (weaknesses) tho'. A lot of progress is driven by criticism - constructive or otherwise.
Re: (Score:2)
Re: (Score:2)
So now it's only "really slow" as opposed to "really really slow"?
It's really really simple: a speed improvement of a factor x means you multiply the number of "really"s by 1/x.
Had it been three times as fast, it would have been merely "real slow".
If you're ever reduced (hah!) to fractions of a single letter, just scale the ASCII value of that letter. So if it was 24 (=2*12) times as fast, it would be half an r, or "8 slow".
Re: (Score:2)
Um, it's pretty competitive against Python and PHP. I guess they're pretty much doomed against Smalltalk and JS too? Oh, wait..
Vala is the new high-level language benchmark (Score:2)
Javascript, Smalltalk, or things like microsoft's CLR are not a good comparison for high-level languages' performance these days. That's because Vala manages to do everything that the CLR/JVM does, only with performance somewhere between C and C++.
Re: (Score:2, Funny)
all of them?
Re: (Score:2)
``speed (while highly welcome) has not been the most important problem in the 1.8 versions.''
Actually, for me it is. Speed, unpredictable performance, and the huge memory overhead of (what should be) small objects. Note that these are all implementation issues; all can be improved without having to change the language proper.
Re:Ruby vs Python (Score:4, Insightful)
What about C? (Score:5, Funny)
Python is skiing and ruby is snow boarding.
I guess that makes C drunk driving. Much faster and more crash-prone.
--*car_analogy_quota("jonaskoelker");
Re: (Score:2, Funny)
Re: (Score:2)
Re:Ruby vs Python (Score:5, Funny)
you know, bad analogies are like a wooden banana.
Re: (Score:2, Funny)
they're hard to eat?
Re:Ruby vs Python (Score:5, Insightful)
One has to wonder if you actually ski or snowboard. Other than the fact that they are both done on snowy downhill slopes, there is no similarity.
Re: (Score:2)
Yeah, other than the fact that they're both winter-time leisure activities involving strapping one or more long pieces of fiberglass to your feet, in order to make your way down a snowy slope, they're nothing alike!
And the parent got modded "insightful"? Sheesh.
Re: (Score:2)
Wow, what does line noise look like in your reality?
Nope, I'm pretty sure neither of those look like line noise.
Re: (Score:3, Informative)
Re: (Score:2)
That doesn't do the same thing at all, and won't do the same thing in the incompatible Python 3 as in Python 2. The Python equivalent to that Ruby would be:
for i in range(1,11): print i
The Python is more readable, but the operation of Python's range(1,11) is a bit less obvious than Ruby's (1..10).each IMO.
Re: (Score:2)
Ruby uses explicit 'end' to mark blocks, Python doesn't. Ruby uses OOP for pretty much everything while Python doesn't (i.e. [].length vs len([], [1,2,3].each{|i| ...} vs for i in [1,2,3]:). Python follows a philosophy of doing something exactly one way, while Ruby doesn't have a problem allowing multiple ways to accomplish the same thing. Ruby uses $ to mark global variables, @ to mark member variables, Python uses explicit 'self.' to do it.
Overall however they look and feel pretty similar.
Re: (Score:2)
Big disclaimer: Perl does as well. Ruby differentiates itself here by disallowing infinite ways.
So does Perl (Score:2)
--
Now, write that 100 times by sunrise or I'll cut your balls off.
Re: (Score:3, Insightful)
[ruby is more OOP than python:] [].length vs len([]), [1, 2, 3].each vs for i in [1, 2, 3]
Given my understanding of OOP, those are not particularly good examples.
len([]) is equivalent to [].__len__, a method invocation on the object in question. Different classes can define different __len__ methods.
for i in some_object calls some_object.__iter__ behind the scenes; same thing again: a method with different definitions across different classes.
What defines OOP is not where you put the dot, but what the dot means, which roughly speaking is the method lookup in a vtable. Ruby and Python both do t
Re: (Score:2)
If you still believe Ruby is more OOP than Python, could you point out either (1) another example, or (2) why you disagree with my thinking?
The difference is that Ruby is OOP from the start and through and through, while Python get stuff patched in a little bit at a time with every new version. See Pythons print-statement vs Ruby puts for example.
OOP aside, another difference worth mentioning between Ruby and Python is that in Ruby the () for function calls are optional. So [].length works just as well as [].length().
Re: (Score:2)
You really need to work on your form; this is at best a 2 out of 10 on the Ruby/Python trolling scale. Generally, you want to pick something that's subtly false, or which requires deep knowledge of the topic to expose the problem with the assertion, not something which is known to be false by folks
Re: (Score:2)
This line of reasoning is moot. Kernel is automatically required in Ruby, so the Kernel method calls are similarly included in the language syntax. Not to mention that a lot of methods Kernel has are put in separate modules in Python (exec, system, sleep, rand) or are methods of objects (split, chomp), so you could argue that Ruby is less OO than Python.
But either way, as I said, t
Re:Ruby vs Python (Score:5, Informative)
...snip...
Well, actually understanding what's going on does require a bit of knowledge of the way the languages work, but my point was that it's irresponsible to go from an assertion like "up until Python 3.0 print was a statement" to "Python isn't really object-oriented" or "Python's OO is just bolted on", because even a basic understanding of how Python works shows that to be false. Let's consider an easy example, a simple function which adds two numbers (Slashdot's comment system will eat the indentation of the function body, but that's neither here nor there):
You might call this function by writing add(2, 3), which would return 5. That turns into a method invocation, delegating to the __call__ method of the function, which is an object: add.__call__(2, 3). And that, in turn, expands into an invocation of the __call__ method of the class of the function object, with the function object passed as the first argument to get the self reference, and the rest of the arguments following: types.FunctionType.__call__(add, 2, 3) (all functions in Python are instances of FunctionType, which is accessible through the types module if you ever have a need to do things manually without resorting to Python's function-definition syntax).
From just this simple example it's clear that the object-orientation really does go all the way down, and that the existence of the print statement in older Pythons was a "bolted-on" wart of an OO language rather than being the other way around. The same is true for the other "special" statements in Python; these are not vestigial remnants of some non-OO language which got an object system tacked on, they are bits which were added on to an OO language for pragmatic reasons (print was turned into a function in Python 3.0, but assert and del, remain as special cases).
This also reveals a few interesting points of Python/Ruby comparison:
Re: (Score:2)
I agree with you, except that :
len() is a shortcut for the __len__ method, which you can redefine.
>> [].__len__()
0
there is not do() method on iterables, however. (I think in this case it's more readable, but it can be debated)
Re:Ruby vs Python (Score:5, Interesting)
Ruby is meant to be more comfortable and expressive in the hands of a programmer than Python. That means more power and more elegance, but also less regularity, more features, and more emphasis on conciseness instead of readability and learnability. (Python is surprisingly readable for non-Python programmers, which I have found handy more than once.)
Personally, I use Python at work because I'm terrible at remembering linguistic features and syntax. At work almost every neuron in my brain is devoted to C++, so for everything else I need a nice, simple, even stupidly simple language that complements C++. Plus if someone inherits my Python code and says *gasp* "But I don't know Python!" I can honestly say, "Don't worry, you have nothing to worry about. You can learn it in a couple of days."
People tell me Ruby is more natural and expressive, and I believe them, but if Python ever lets me down I'm skipping straight to the Red Pill, aka Lisp, which I have enjoyed recreationally on occasion. (I keep some spare neurons for myself for fun. Don't tell my boss.)
Re:Ruby vs Python (Score:5, Interesting)
Here's my take, having used both languages in anger. First off, let me call out a number of similarities between these languages. They're both OO, dynamic, and provide reflection capabilities (useful for meta-programming). They've both been influenced by functional languages. They both have active, vibrant user communities. Both have many open-source and shipping commercial applications that leverage or are fully built on these languages. While there are notable syntactic differences, I find that there's a certain shared "feel" between Python and Ruby.
Now I'll call out the differences I find interesting. Python's import model (akin to #include for you C folk) is stronger than Ruby's require when it comes to larger applications. By "stronger", I mean that it's more explicit and therefore provides greater assurance against unintended effects from referencing a different module/class/object than you intended. This is a two-edged sword, since Ruby's code loading approach is less verbose and affords the construction of tools like Rails' Dependencies module which automatically finds code via a convention-over-configuration model. (e.g. calling require is never needed for the main application code of a Rails application if you just follow the file vs. class naming conventions -- this is *very* handy, IMO.)
I'm big on powerful abstractions in programming languages. On this count, I find that Ruby wins hands down. The Python community has had a muddled approach to some key areas that Ruby had early clarity on via lessons learned from Smalltalk. Specifically, Ruby blocks are a single great primitive that covers the ground of a number of separate, less powerful entities in Python. Blocks are nothing more or less than anonymous functions, aka "lambdas", but their beauty lies in their syntatic integration. Consider the Ruby iterator pattern:
... end construct is a block. a is a Ruby Array object. The conventional iterator method each calls the block once for every element in order, as you'd expect. The neat thing here is that it's easy and natural to implement your own custom version of each for your classes. By defining this one method, and including the mixin module Enumerable [ruby-doc.org] on your class, you get definitions for a bunch of other useful standard collection methods such as map, find, select/reject and so on.
a = [3,4,5]
a.each do |x|
puts x
end
The do
Now, Python provides for the special __iter__ method to allow user-defined classes to support iteration. But Ruby's block-based mechanism is fully general and available to the Ruby programmer. Blocks' utility goes beyond iteration, into a wide variety of other cases where anonymous functions are useful. Some motivating examples may be helpful. Another one from Ruby's standard library:
File.open('foo.txt','w') do |f|
f.write(some_content)
end
This illustrates the Ruby idiom for resource cleanup. Here we're guaranteed that the file will be closed after the block runs. The implementation of open isn't magic, it can be expressed (**simplified slightly) as:
class File
def File.open(name,mode)
file = File.new(name,mode)
if block_given?
begin
yield
ensure
file.close
end
else
return file
end
end
end
And the list of uses goes on and on. Blocks are a foundation component that makes Ruby well-suited for writi
Re: (Score:2)
Consider the Ruby iterator pattern:
Having not used Ruby, I've never quite gotten why this is so special. The Python equivalent would be:
It's not creating an anonymous function, but it's doing the same work otherwise. Can you give an example of why the Ruby way is better? I'm asking genuinely; I'd really like to see what makes this cool.
The neat thing here is that it's easy and natural to implement your own custom version of each for your classes. By defining this one method, and including the mixin module Enumerable on your class, you get definitions for a bunch of other useful standard collection methods such as map, find, select/reject and so on.
What does that buy you over Python's list comprehensions or generator expressions?
Re: (Score:2)
IMO, Ruby's use of blocks is simpler, cleaner, and more elegant than the variety of Python techniques that cover different parts of what Ruby does with blocks. But, largely, its subjective.
Re: (Score:2)
Specifically, Ruby blocks are a single great primitive that covers the ground of a number of separate, less powerful entities in Python.
Blocks are covered by generators and with-statement. They are separate, but certainly not less powerful (and most Python fans would argue they are more intuitive).
a = [3,4,5]
a.each do |x|
Yeah,
for x in a:
print x
is so much less readble ;-).
The neat thing here is that it's easy and natural to implement your own custom version of each for your classes.
Yeah, and it's every bit as natural to implement python generators.
Now, Python provides for the special __iter__ method to allow user-defined classes to support iteration. But Ruby's block-based mechanism is fully general and available to the Ruby programmer.
... generators again ...
Blocks' utility goes beyond iteration, into a wide variety of other cases where anonymous functions are useful. Some motivating examples may be helpful. Another one from Ruby's standard library:
File.open('foo.txt','w') do |f|
f.write(some_content)
end
This illustrates the Ruby idiom for resource cleanup. Here we're guaranteed that the file will be closed after the block runs. The implementation of open isn't magic, it can be expressed (**simplified slightly) as:
This is why Python has "with" statement now. Can you bring up something that is *not* covered by with statement or generators? No?
I know this is a bad idea on ruby fanb