Well, they could have added a nearly-canonical "...this is primarily a bug-fix release."
It goes without saying that an open source project is always fixing bugs, hopefully at a slightly higher rate than they are introduced.
Well, it seems that Ruby 1.9.0 is the fastest implementation available,
it also is reflects the newest version of the language... but I would
really like to see benchmarks based on real apps based on things like
Mephisto,Radiant CMS and/or Mongrel.
Also, does someone have a list with the most important features? The summary
is way too poor.
According to Chu Yeow [codefront.net], Mongrel doesn't run on 1.9.0 yet. Neither does Rails. The release of 1.9.0 coincided with the API freeze for 1.9.x, so hopefully projects that were holding off on porting to 1.9 will do so now. The situation is complicated by 1.9's transitional nature; you should stick with 1.8 if you absolutely need stability.
Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)? Basically, I've been using Python for quite a while and work with a largish codebase at the office. Is there any reason why I should give Ruby a try other than the standard - and very valid - "because it's there"? From what I've heard it seems that the two languages occupy roughly the same niche and are
by Anonymous Coward
on Tuesday December 25 2007, @11:02PM (#21818760)
Is there any reason why I should give Ruby a try?
Speaking as a ruby developer, if you're happy with python - not really! Python's also great. It's just a matter of which suits your style. Personally, I couldn't get over Python's syntactically significant whitespace - many people would laugh at that, but for me it's just unthinkable. So Python was just ruled out for me totally because of that.
Python and Ruby are both competing to be the most beautiful next-gen languages.. but beauty's in the eye of the beholder. I've found mine, and it sounds a lot like you've found yours. So.. that was the long way to say, again, "not really" ! : )
Yeah, same here for why I don't like Python. I find myself adding additional if/loop statements around a block of code often enough that I just couldn't imagine working with python where it isn't trivial to automatically indent the block of code, since the indent is the block of code. Copying/pasting code is another case where the indentation is not necessairly correct. I am not talking about duplicating code here, but something like taking a chunk of code and making it into a function call. I really like how
The emacs rectangular editing features make 'sculpting' text a no-brainer:
(here is the C-h a rectangle output, noting that registers are a really powerful emacs feature):
calc-grab-rectangle M-x... RET Command: Parse a rectangle as a matrix of numbers and push it on the Calculator stack. clear-rectangle C-x r c Command: Blank out the region-rectangle. close-rectangle M-x... RET Command: Delete all whitespace following a specified column in each line. copy-rectangle-to-register C-x r r Comm
I think that the rather vast body of python code freely available moves the design choice out of "WTF" territory.
Love it or hate it, it's simply not a show-stopper.
Haskell, too, has significant whitespace, though, unlike Python, you can relax the whitespace significance in Haskell.
That definitely falls under "WTF where they thinking?!?" where a single, invisible, space can bork up your code.
OK, does anyone really write significant amounts of code in Notepad? That's the only editor I'm aware of that doesn't have any form of Python syntax highlighting available. Emacs or Vim or Kate or Eclipse will cheerfully steer you around that single, invisible space so this only seems to be a problem in the minds of people who want to invent reasons to dislike it.
Back then Ruby's C interface appeared much easier to use than Python's reference-counting mess (I don't know about recent developments). Apart from that, both are good as far as scripting languages go.
As someone in the same general situation as you -- I also work on Python code -- my conclusion when I asked myself the same question, was an emphatic no. There's little Ruby can do that Python cannot, and vice versa. As well, I looked through a Ruby tutorial; it can be a really strange language. I'm sure it works for people who put in the time to learn it, but it didn't click with my Pythonic mindset. I think Ruby is really an evolution of Perl. There are a lot of Perlisms in its syntax, and I bet it'd be ve
Answer: No. Ruby doesn't scale as well as PHP, Python, or PERL. The number of responses per second it can handle quickly drops off in comparison to the other languages; tack on Rails and it's even worse. Honestly, any MVC framework in Perl, PHP or Python is going to be more scalable and faster than RUBY; it may have a bit steeper of a learning curve for a newbie but so what.
I'd like to see some statistics backing up this claim with code samples. I have never seen a performance problem in Ruby or any other language that was not fixed within an hour by generally simple code improvements. The developer is the cause of 99% of performance problems in any mainstream language today.
Ruby is a neat language. Basically imagine a language that can do all of the great hacks you can do in perl (and then some) but with a sane syntax. Python is a very very good language, I've written quite a bit of code in it. Ruby is nicer, at least from a syntax standpoint. It's just SO expressive, even beating python. But, at least until now, the speed always SUCKED balls. Maybe this new release will get it roughly on par with python.
If performance is an issue, don't you move the code to something in a compiled langauge once a) the requirements are settled and b) you're sure you actually need to do so?
Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)?
Take a glance at Ruby from other languages [ruby-lang.org]. This page highlights some of the things that make Ruby Ruby.
Try it if you can find the time, and maybe pick up a copy of Ruby for Rails [amazon.com].
Python currently has larger library support.
Personally I see no need for you to reinvent your wheel, but you'll probably not be gratified as to the validity of your decision until you dig a little.
Ruby has some differences that are important to some people.
* The built-in classes support functional-style programming. That is, the default action is generally to return a modified copy of the object being acted upon, so you can chain method calls together. This doesn't work well in Python, because methods frequently act like "procedures", modifying the object and returning nothing. Sometimes, Python programmers work around this by explicitly copying objects and then calling such methods. Other times, modifying the persistent object is just what they wanted; in Ruby, you would use a method which ends in "?", which is how Ruby identifies (by convention) methods that modify the object.
Thus, to combine two dictionaries in Python, without modifying either of them:
dcombined = d1.copy()
dcombined.update(d2)
In Ruby:
dcombined = d1.merge(d2)
Obviously the Python code is fine, but from a functional programming viewpoint, it looks awkward.
* It's entirely predictable whether a built-in class's method will modify the object, because of the "?" suffix convention. In Python, you don't have such an explicit convention, which can sometimes make more work for the programmer. * Ruby doesn't rely on global functions as much, or "builtins" as they're called in Python. If you want to know the length of something, or convert a string into a list of characters, you call a method of the object rather than a global function. Some people find this to be easier, given that you only need to focus on one paradigm (object-oriented) and not two (e.g., object-oriented and imperative). * The print statement in Ruby prints only what you tell it to, rather than adding whitespace in various cases. Since this is the behavior of print or printf in most languages, this is nice. Ruby offers the puts method for those times you want whitespace helpfully added (like Perl 5.10's say). * regular expressions are more tightly integrated. Some people consider this a disadvantage of Ruby though, because you can write less explicit code. * Ruby gives you fewer types of quotes to learn, because ' and " are multiline.
I thought that the ? suffix meant "this makes no modifications and only returns a certain property, usually boolean" and ! meant "this modifies the "self" object. Example: foo.gsub!(/f/, 'g') would modify 'foo' directly, where foo.gsub(/f/, 'g') would return a new string but leave the old one unmodified.
The built-in classes support functional-style programming. That is, the default action is generally to return a modified copy of the object being acted upon, so you can chain method calls together. [...] Obviously the Python code is fine, but from a functional programming viewpoint, it looks awkward.
This is indeed a useful feature, but it's not really functional programming, just a different style of object oriented design. The complete absence of any functions in your example might have served as a clue.:)
Not true. Hash#clear and Hash#delete modify the object, but contain no suffix. I hate this about Ruby: you can't skim the method list for methods ending in "!". You have to also know if there exists a nondestructive version of it, and if you knew that, you'd already know its name.
You've got me there. Ruby could stand to clean up its act and be more consistent here. It still has quite an advantage, though.
Python: list(foo) Ruby: Array(foo) The real difference is that Rubyists will say "oh, but Array here is a
The thing that makes Ruby stand out above the languages I'm well versed in (unfortunately Python isn't one of them) is its metaprogramming abilities. For lack of a better way to describe it: You don't write Ruby programs. You write Ruby programs that write Ruby programs. If Python is the same in this regard, then I guess probably nothing.
Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)?
If you look at it from a features and libraries perspective, then you really won't find much different. But you shouldn't look at it that way.
There's a significant programming style difference between the Python and Ruby communities. Python programmers, as a general rule, tend to be more inclined towar
To actually do any given thing, no. To program in for fun, yes. To do things you'd never have thought of doing, yes.
Blocks and iterators: [1,2,3].collect {|x| x ** 3 }.each {|x| puts x.to_i }
It's like specifying arguments that contain code. Functions you otherwise would have to pass a ton of arguments to, or provide a call-back function for, take an anonymous block.
Ruby's a very quick language. You can get something done quickly like Perl, and it has nice shortcuts like "foobar" =~/Foo/i for regexps, et
I don't know Python, and I don't want to try to compare Ruby with it. And I'm not a real programmer, just an amateur, so take this with a big grain of salt. I could be completely wrong here.
The heart of Ruby is its use of idiom. It's a difficult thing to describe, and I don't know how you'd find some metric to measure it, or to compare it to another language. But it's very clean, and very sensible, and surprisingly simple, at least on the surface.
There's a kind of aesthetic pleasure to be had in the syntax of Ruby. I was about to write that in that sense it's kind of an anti-perl, but that's flame bait, and I never connected with perl, and lots of people probably find perl beautiful. But Ruby is really great.
You can do things like:
1.upto(10) {|x| puts x }
Which does:
1 2 3...
This thing looks a lot like an old fashioned for/each loop, but it's an iterator, and the code in the curly brackets is a closure. So under the hood, it's fairly different from a for/each loop.
There are a few things to mention about this.
First, because there are lots of iterators on the shelf, and because you can write your own iterators if you want, this thing is a lot more powerful than looping constructs in many other languages.
Second -- and this is the sort of thing I was trying to get at above -- the syntax for closures is tweaked so it makes human intuitive sense when you're using closures with iterators. In your head, you might be thinking in for/each terms, and the syntax colludes with you if you want to hang on to that useful fiction.
In Lisp, you can never forget about the lambdas. In Ruby, you just sort of do what you want, and the lambdas are there under the hood, but they're not jumping out at you in the same way. Ruby's syntax fits the way a lot of people think, and it hides the stuff that it makes sense to hide, and exposes the stuff that it makes sense to expose.
And when you write out that line of code, its meaning is very clear and easy to grab a hold of, and it turns out that it's usually very concise and compact as well.
This is a little redundant, but I want to stress it, that line of code really is a pretty thing, in a sense. It's not so remarkable if you think of it as a for/each loop, but it's not a for/each loop -- it's an iterator and a closure, and that's a somewhat complicated thing, but here it isn't complicated, or opaque. It's clean, and it makes sense, and it's concise, but most of all, the shape of the code conforms to the shape of the idea in your head. That's what Ruby is all about, and you see that over and over and over again.
Third, this approach to idiom is a real dual edged blade for me, because there's a culture in Ruby books that sort of says, "You know what this line of code is doing, so don't worry too much about the lambdas." For a long time, I felt lost in Ruby -- like, I kind of knew what the code was going to do, but I wasn't exactly sure what was going to happen under the hood. That's a really uncomfortable place to be. I had to watch the SICP lectures to really grab hold of Ruby.
It's always dangerous to talk about some other culture -- I could be way off base here, and I hope I don't say anything really dumb. But it feels Japanese to me -- it reminds me of a drawing where there aren't many lines, but all the lines are kind of perfect and clean. It's got that same sense of elegance to it. Let's boil this big thing down to its essence, and make it beautiful and sparse.
I can't tell you that Ruby is better than some other language. But I can tell you that it's very beautiful, and that the beauty lives in lots of small little details. The experience of learning and using Ruby is one of noticing these little things and saying, "Wow, how great is that?"
I used to live in an apartment building that had been designed by a famous architect -- Mies van der Rohe. The design made a difference -- I can't tell you why or how, exactly, but it d
Faster is good, but faster is not enough. Parallelization, these days, involves multi-LAN, multi-node, multi-CPU, multi-core systems where each core may or may not also be a vector processor. Modern libraries for handling such code tends to be usually too primitive to effectively handle anything but simple cases of even very narrowly-focussed software. If you want to parallelize across a combination of types, forget it. There are ways to do it - such as CORBA - but they're too slow and/or too complex. There are also languages modified to handle the complexities of parallelization, such as Unified Parallel C, Parlog or Occam, but they're usually much too complex to use in practice.
Is parallelization the only niche that isn't supported well? No. There are other areas languages generally do badly in. There are very few languages which handle internationalization efficiently. There are very few languages which handle graphical interfaces efficiently or logically. Languages are typically either good at handling very complicated data structures OR handling structures that are defined just-in-time, typically not both.
My interest in Ruby would be greatly increased if I saw it do something that very few other languages could do, preferably no language that was in mainstream use.
My BSc was over 16 years ago, my MPhil was over 11 years ago. Much of my professional career has involved client/server systems, distributed computing, grid computing, embedded computing and high-performance computing. My open source contributions include a MIPS port of an open source MPI package, work on clustering and multicast-based CORBA technology. My protocol standards contributions include work on using scalable reliable multicast alongside RDMA to do efficient one-to-all and all-to-all operations (ie: not sequentially, as is implemented in most open source MPI implementations). My hardware experience has included programming meshes of T800 Transputers, UltraSPARC clusters, Broadcom BCM1250 clusters and high-end multi-core x86 processors. Amateur projects have included using distributed computing to perform signal processing and data analysis from ground-penetrating RADAR and magnetometers being used by an archaeological group.
If you want the evidence, the data, the background, I've no objections to stating it. Well, with the exception of commercial projects still covered by non-disclosure agreements. Even if the company betrayed not only me but also the other software engineers there, resulting in engineers being deprived of rightful wages, forced out or removed under false pretenses. I have ethics, even if they do not. The bulk of my experience is NOT covered by any NDA, but is a little on the lengthy side. People get paid good money for writing books with less content. If you actually want to know, I have no objections, but it's not something anyone would be willing to read on Slashdot as a reply or even as a main article.
Erlang is good, and is an example of a language that is very usable in some of the niches that are under-developed. There are a few projects written in Erlang, and I would expect that to increase over time as Erlang technology improves and as more people become aware of it. It would probably help if there was more reference to it on Slashdot, LWN and Freshmeat.
Erlang is good, and is an example of a language that is very usable in some of the niches that are under-developed. There are a few projects written in Erlang, and I would expect that to increase over time as Erlang technology improves and as more people become aware of it. It would probably help if there was more reference to it on Slashdot, LWN and Freshmeat.
All that takes is writing good articles about news that people want to read. Really.
I will. I, for one, would be more aware of the brilliant features in Haskell programs (and Haskell in general) if information on it was a little better circulated. (A few of the records on Freshmeat had gathered so many cobwebs and so much dust that they looked like something from a 60s horror movie.) The same is true of Erlang, and many other "obscure" languages - obscure because it's below the radar of many who would be interested.
Now, I would not call myself remotely qualified to write an article (or a
I can't help but notice that there's nothing mentioned about unicode. I don't see how a major web development language, especially one made by Japanese designers, can go so long without adding comprehensive unicode support. After all, it's not like only English speaking people use rails websites...
There is support for Unicode in Ruby 1.9. An encoding is now associated to a string and you can also perform transcoding, therefore converting a given string amongst different formats (e.g. UTF-8 and ASCII).
It's nice to see that Ruby interpreter speed is improving. Performance and compile time checking (think static types) are about the only areas in which I find Ruby lacking. Looking at the table on the shootout page, though, I find that performance has only improved by a factor 2. That's impressive...but it's not enough. Last I measured, Ruby was about a factor 300 slower than C on low-level code (measuring the performance of high-level functionality implemented in the interpreter is not so interesting, becau
So while it may have improved upon speed, the question still is whether it can scale without having to rely upon PHP and JAVA and PYTHON consistently to help it out in this regard.
You seem to be thinking of Rails, which is a framework for Ruby used for making web apps.
Ruby itself is quite nice for general development work.
No, talking about the language not the MVC architecture. RUBY itself has trouble scaling; RAILS makes the problem a bit worse but if the problem wasn't there to begin with, it wouldn't be that noticeable with a good MVC framework.
But RUBY always seems to have to rely upon other languages to scale. The RUBY website uses PHP. The Rails website uses PHP.Seems every place that RUBY has to scale requires it to use another language and the RUBY maintainers have not tried to excuse this but the RUBY community ha
Ruby is not a web development language. It is a general scripting language, like Perl or Python. You still seem to conflate the language with the specific use case of Rails - dynamic website scripting.
I use it heavily as my general scripting language; where I would have used Perl for small utilities, file munging or what have you before, I now use Ruby. Not because Perl is bad - it isn't - but Ruby really is in many respects Perl done right, with many of the benefits and without the syntactic quirkiness. Scaling just isn't a factor for most uses of a script language.
It seems like far too many people think that Ruby is just for web stuff because of Rails. They don't realize that it's a really good general purpose scripting language. I think my two favorite things about Ruby when compared to Perl (which, like you, I used to use for scripting) are: 1) I can actually *read* it because it doesn't look like I rolled my head around on the keyboard 2) It behaves in Windows the same way it does in Linux (with the obvious exception of having to change any hard-coded filenames you
1) Depends on what you're writing. big_array.collect {|x| x.expensive_file_io }.sort_by {|x| x.to_s } is going to be stuck in library code far more than interpreting Ruby. 2) Granted. Yet the Ruby community seems more cohesive than other languages. JRuby and Rubinius are intentionally staying close to Ruby. Of course, in JRuby, much of what you do wouldn't work without the J, so it's not back-portable, but technically would be.
3) See 1. A ruby process only wastes the time interpreting and garbage collectin
Scalability today means using the multiple cores that my processor has. Ruby provides no real means for doing this (e.g., native threads). Sure, you can launch multiple ruby processes, and chat between them with IPC, but look at the overhead of a ruby process...
Umm, you seem to be confusing performance with scalability here.
I'd say that a program based on processes communicating via IPC is far far more scalable that a program based on threads sharing memory.
The processes + IPC program can be distributed across several machines; the threaded program cannot. The fact that the threaded application is slightly faster is irrelevant since it cannot scale beyond a certain point.
It's easy to forget that hardware costs very little compared to developers' time.
You must be a troll or never used Ruby. In all languages today, Ruby, or Python, etc., performance is a problem with the developer, not the language. Also, languages are not by themselves slow, the virtual machines or interpreters are, so saying a language is slow is nonsensical.
Also, languages are not by themselves slow, the virtual machines or interpreters are, so saying a language is slow is nonsensical.
Well, yes and no. One can meaningfully say that "Language Foo is harder for an implementation to optimise than language Bar". In practice "harder" will often been completely infeasible.
Here's some examples I've plucked out of the air:
32-bit integers with silent wrap-around (e.g. Java) generally map much closer to the hardware than do unbounded integers (e.g. Tcl 8.5).
A compiler / interpreter can infer many things about a C++ function (whether it has side-effects, names and types of all the local v
Since you don't begin to define what you mean by scalability, I'll take that as FUD. However, scalability is one of the problems Ruby is trying to tackle
Um... so you agree that scalability is a problem but you say it's FUD?? By scalability, you must have a pretty good idea of what I am talking about to be able to agree with me and say it's a problem as well.
Firehose blurp (Score:2)
Re: (Score:2)
It goes without saying that an open source project is always fixing bugs, hopefully at a slightly higher rate than they are introduced.
Benchmarks mean nothing, specially these ones. (Score:2, Insightful)
Re:Benchmarks mean nothing, specially these ones. (Score:5, Informative)
Parent
Why Ruby? (Score:2)
Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)? Basically, I've been using Python for quite a while and work with a largish codebase at the office. Is there any reason why I should give Ruby a try other than the standard - and very valid - "because it's there"? From what I've heard it seems that the two languages occupy roughly the same niche and are
Re:Why Ruby? (Score:4, Insightful)
Speaking as a ruby developer, if you're happy with python - not really! Python's also great. It's just a matter of which suits your style. Personally, I couldn't get over Python's syntactically significant whitespace - many people would laugh at that, but for me it's just unthinkable. So Python was just ruled out for me totally because of that.
Python and Ruby are both competing to be the most beautiful next-gen languages
Parent
Re: (Score:2)
I find myself adding additional if/loop statements around a block of code often enough that I just couldn't imagine working with python where it isn't trivial to automatically indent the block of code, since the indent is the block of code. Copying/pasting code is another case where the indentation is not necessairly correct. I am not talking about duplicating code here, but something like taking a chunk of code and making it into a function call.
I really like how
Re: (Score:2)
Re: (Score:2)
Love it or hate it, it's simply not a show-stopper.
Haskell, too, has significant whitespace, though, unlike Python, you can relax the whitespace significance in Haskell.
Re: (Score:2)
That definitely falls under "WTF where they thinking?!?" where a single, invisible, space can bork up your code.
OK, does anyone really write significant amounts of code in Notepad? That's the only editor I'm aware of that doesn't have any form of Python syntax highlighting available. Emacs or Vim or Kate or Eclipse will cheerfully steer you around that single, invisible space so this only seems to be a problem in the minds of people who want to invent reasons to dislike it.
FFI (Score:3, Funny)
Re: (Score:2, Insightful)
I think Ruby is really an evolution of Perl. There are a lot of Perlisms in its syntax, and I bet it'd be ve
Re: (Score:2)
Re: (Score:2)
Re:Why Ruby? (Score:5, Interesting)
Parent
Re: (Score:2)
Re:Why Ruby? (Score:4, Informative)
Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)?
Parent
Re: (Score:2)
Python currently has larger library support.
Personally I see no need for you to reinvent your wheel, but you'll probably not be gratified as to the validity of your decision until you dig a little.
Re:Why Ruby? (Score:4, Interesting)
* The built-in classes support functional-style programming. That is, the default action is generally to return a modified copy of the object being acted upon, so you can chain method calls together. This doesn't work well in Python, because methods frequently act like "procedures", modifying the object and returning nothing. Sometimes, Python programmers work around this by explicitly copying objects and then calling such methods. Other times, modifying the persistent object is just what they wanted; in Ruby, you would use a method which ends in "?", which is how Ruby identifies (by convention) methods that modify the object.
Thus, to combine two dictionaries in Python, without modifying either of them:
dcombined = d1.copy()
dcombined.update(d2)
In Ruby:
dcombined = d1.merge(d2)
Obviously the Python code is fine, but from a functional programming viewpoint, it looks awkward.
* It's entirely predictable whether a built-in class's method will modify the object, because of the "?" suffix convention. In Python, you don't have such an explicit convention, which can sometimes make more work for the programmer.
* Ruby doesn't rely on global functions as much, or "builtins" as they're called in Python. If you want to know the length of something, or convert a string into a list of characters, you call a method of the object rather than a global function. Some people find this to be easier, given that you only need to focus on one paradigm (object-oriented) and not two (e.g., object-oriented and imperative).
* The print statement in Ruby prints only what you tell it to, rather than adding whitespace in various cases. Since this is the behavior of print or printf in most languages, this is nice. Ruby offers the puts method for those times you want whitespace helpfully added (like Perl 5.10's say).
* regular expressions are more tightly integrated. Some people consider this a disadvantage of Ruby though, because you can write less explicit code.
* Ruby gives you fewer types of quotes to learn, because ' and " are multiline.
Parent
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
This is indeed a useful feature, but it's not really functional programming, just a different style of object oriented design. The complete absence of any functions in your example might have served as a clue. :)
Re: (Score:2)
Re: (Score:2)
Sorry.
Re:Why Ruby? (Score:4, Insightful)
Ouch. Try this one:
It scales easily (add "+ c.items()" to mix in another dict) and doesn't have any restriction's on the keys' datatypes.
Parent
Re: (Score:3, Insightful)
You've got me there. Ruby could stand to clean up its act and be more consistent here. It still has quite an advantage, though.
Re: (Score:3, Interesting)
Different style of programming (Score:3, Insightful)
If you look at it from a features and libraries perspective, then you really won't find much different. But you shouldn't look at it that way.
There's a significant programming style difference between the Python and Ruby communities. Python programmers, as a general rule, tend to be more inclined towar
Re: (Score:2)
To program in for fun, yes. To do things you'd never have thought of doing, yes.
Blocks and iterators: [1,2,3].collect {|x| x ** 3 }.each {|x| puts x.to_i }
It's like specifying arguments that contain code. Functions you otherwise would have to pass a ton of arguments to, or provide a call-back function for, take an anonymous block.
Ruby's a very quick language. You can get something done quickly like Perl, and it has nice shortcuts like "foobar" =~
Re:Why Ruby? (Score:5, Interesting)
The heart of Ruby is its use of idiom. It's a difficult thing to describe, and I don't know how you'd find some metric to measure it, or to compare it to another language. But it's very clean, and very sensible, and surprisingly simple, at least on the surface.
There's a kind of aesthetic pleasure to be had in the syntax of Ruby. I was about to write that in that sense it's kind of an anti-perl, but that's flame bait, and I never connected with perl, and lots of people probably find perl beautiful. But Ruby is really great.
You can do things like:
1.upto(10) {|x| puts x }
Which does:
1
2
3
This thing looks a lot like an old fashioned for/each loop, but it's an iterator, and the code in the curly brackets is a closure. So under the hood, it's fairly different from a for/each loop.
There are a few things to mention about this.
First, because there are lots of iterators on the shelf, and because you can write your own iterators if you want, this thing is a lot more powerful than looping constructs in many other languages.
Second -- and this is the sort of thing I was trying to get at above -- the syntax for closures is tweaked so it makes human intuitive sense when you're using closures with iterators. In your head, you might be thinking in for/each terms, and the syntax colludes with you if you want to hang on to that useful fiction.
In Lisp, you can never forget about the lambdas. In Ruby, you just sort of do what you want, and the lambdas are there under the hood, but they're not jumping out at you in the same way. Ruby's syntax fits the way a lot of people think, and it hides the stuff that it makes sense to hide, and exposes the stuff that it makes sense to expose.
And when you write out that line of code, its meaning is very clear and easy to grab a hold of, and it turns out that it's usually very concise and compact as well.
This is a little redundant, but I want to stress it, that line of code really is a pretty thing, in a sense. It's not so remarkable if you think of it as a for/each loop, but it's not a for/each loop -- it's an iterator and a closure, and that's a somewhat complicated thing, but here it isn't complicated, or opaque. It's clean, and it makes sense, and it's concise, but most of all, the shape of the code conforms to the shape of the idea in your head. That's what Ruby is all about, and you see that over and over and over again.
Third, this approach to idiom is a real dual edged blade for me, because there's a culture in Ruby books that sort of says, "You know what this line of code is doing, so don't worry too much about the lambdas." For a long time, I felt lost in Ruby -- like, I kind of knew what the code was going to do, but I wasn't exactly sure what was going to happen under the hood. That's a really uncomfortable place to be. I had to watch the SICP lectures to really grab hold of Ruby.
It's always dangerous to talk about some other culture -- I could be way off base here, and I hope I don't say anything really dumb. But it feels Japanese to me -- it reminds me of a drawing where there aren't many lines, but all the lines are kind of perfect and clean. It's got that same sense of elegance to it. Let's boil this big thing down to its essence, and make it beautiful and sparse.
I can't tell you that Ruby is better than some other language. But I can tell you that it's very beautiful, and that the beauty lives in lots of small little details. The experience of learning and using Ruby is one of noticing these little things and saying, "Wow, how great is that?"
I used to live in an apartment building that had been designed by a famous architect -- Mies van der Rohe. The design made a difference -- I can't tell you why or how, exactly, but it d
Parent
I'd like something else. (Score:3, Insightful)
Is parallelization the only niche that isn't supported well? No. There are other areas languages generally do badly in. There are very few languages which handle internationalization efficiently. There are very few languages which handle graphical interfaces efficiently or logically. Languages are typically either good at handling very complicated data structures OR handling structures that are defined just-in-time, typically not both.
My interest in Ruby would be greatly increased if I saw it do something that very few other languages could do, preferably no language that was in mainstream use.
Re:I'd like something else. (Score:4, Interesting)
If you want the evidence, the data, the background, I've no objections to stating it. Well, with the exception of commercial projects still covered by non-disclosure agreements. Even if the company betrayed not only me but also the other software engineers there, resulting in engineers being deprived of rightful wages, forced out or removed under false pretenses. I have ethics, even if they do not. The bulk of my experience is NOT covered by any NDA, but is a little on the lengthy side. People get paid good money for writing books with less content. If you actually want to know, I have no objections, but it's not something anyone would be willing to read on Slashdot as a reply or even as a main article.
Parent
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:3, Interesting)
Now, I would not call myself remotely qualified to write an article (or a
where's unicode? (Score:3, Interesting)
Re:where's unicode? (Score:4, Informative)
Parent
Speed Improvements Are Nice, But Not Enough (Score:2)
Last I measured, Ruby was about a factor 300 slower than C on low-level code (measuring the performance of high-level functionality implemented in the interpreter is not so interesting, becau
Re: (Score:2)
You seem to be thinking of Rails, which is a framework for Ruby used for making web apps.
Ruby itself is quite nice for general development work.
Re: (Score:2)
But RUBY always seems to have to rely upon other languages to scale. The RUBY website uses PHP. The Rails website uses PHP.Seems every place that RUBY has to scale requires it to use another language and the RUBY maintainers have not tried to excuse this but the RUBY community ha
Re:Scalability? (Score:5, Insightful)
I use it heavily as my general scripting language; where I would have used Perl for small utilities, file munging or what have you before, I now use Ruby. Not because Perl is bad - it isn't - but Ruby really is in many respects Perl done right, with many of the benefits and without the syntactic quirkiness. Scaling just isn't a factor for most uses of a script language.
Parent
Re: (Score:2)
I think my two favorite things about Ruby when compared to Perl (which, like you, I used to use for scripting) are:
1) I can actually *read* it because it doesn't look like I rolled my head around on the keyboard
2) It behaves in Windows the same way it does in Linux (with the obvious exception of having to change any hard-coded filenames you
Re: (Score:2, Insightful)
Excuse me but http://www.ruby-lang.org/ [ruby-lang.org] runs on Radiant CMS [radiantcms.org], which is written in ruby, not on php.
Re: (Score:3, Insightful)
Re: (Score:2)
2) Granted. Yet the Ruby community seems more cohesive than other languages. JRuby and Rubinius are intentionally staying close to Ruby. Of course, in JRuby, much of what you do wouldn't work without the J, so it's not back-portable, but technically would be.
3) See 1. A ruby process only wastes the time interpreting and garbage collectin
Re: (Score:2)
Scalability today means using the multiple cores that my processor has. Ruby provides no real means for doing this (e.g., native threads). Sure, you can launch multiple ruby processes, and chat between them with IPC, but look at the overhead of a ruby process ...
Umm, you seem to be confusing performance with scalability here.
I'd say that a program based on processes communicating via IPC is far far more scalable that a program based on threads sharing memory.
The processes + IPC program can be distributed across several machines; the threaded program cannot. The fact that the threaded application is slightly faster is irrelevant since it cannot scale beyond a certain point.
It's easy to forget that hardware costs very little compared to developers' time.
Di
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Also, languages are not by themselves slow, the virtual machines or interpreters are, so saying a language is slow is nonsensical.
Well, yes and no. One can meaningfully say that "Language Foo is harder for an implementation to optimise than language Bar". In practice "harder" will often been completely infeasible.
Here's some examples I've plucked out of the air:
Re: (Score:2)