Slashdot Mirror
Why not Ruby?
flounder_p queries: "I have recently started playing with the
Ruby programming language and think it's really great. I was just wondering why you
guys think Ruby has not caught on more in the open source community than it has? How many of you guys are using it? Will it ever catch on or will it always be looked at as yet another scripting language? Don't get me wrong scripting languages are great (and I live by Perl) but I still hope to see Ruby catch on more. I would like to hear opinions on things on why Ruby is good or bad not on why OOP is good or bad. We have already had that discussion
here." On a side note, a little birdy tells me that BlackAdder has plans for Ruby support in its next beta.
Yes, the Open Source Scripting Language Steering Committee should finally decide on an official scripting langugage for all of us.
In many ways I agree. Not too many programmers even know that there are other types of perfectly useful paradigms besides procedural and OO. I didn't fully appreciate this until I took a 4th year programming languages course. The theory behind some of these other paradigms is rather fundamental in nature. The pure simplicity and elegance of the lambda calculus makes it something that I think everyone should know before they consider themselves an excellent programmer. Believe it or not, this type of knowledge will be good to know in practice, especially if you're ever working on a compiler or interpreter, or designing or choosing a language for some particular application. If you are ever working on some kind of meta-language type construct to facilitate your work, you may find it invaluable to know about things like closures and such. Even for very routine tasks in an imperative or OO language, simply knowing something what higher order functions ARE and how you can implement them may make your designs easier to create and understand.
That said, in the real world you'll probably rarely use a functional language. But they are out there. Lisp-like functional languages are not uncommon as extension languages in large applications. And something like Prolog can be useful for quickly prototyping certain things. To limit yourself to OO and procedural paradigms is short-sighted I think, especially to think that one is a silver bullet. The paradigm really has little to do with the language too. There are languages like OCAML and that make it easy to program in either OO, functional, or imperative style. To say that one paradigm is best for scripting, and one is best for large applications is also limiting, I think. OO tends to work well in large applications, but there's no reason you couldn't mix it with a functional style, or use an imperative (procedural) extension language to develop certain parts, if appropriate.
I think the moral of the story is that it's good to learn and be familiar with as many different styles and languages as possible. Be familiar with the theory behind all of them as well.
In the past I've programmed in C, C++, Java, Jython, Python, Perl, Clips, Scheme and Tcl/Tk. What I like about Ruby is the 'everything is an object' mentality; this has saved me a lot of time and hassle learning the language.
.jp page. Many of the hooks or modules that would be standard on Python or Perl are also not available for Ruby at this time.
What I don't like is all the 'end' statements (mostly because I tend to forget or mis-place a few of them).
If anyone at "BlackAdder" is reading this I would love to have a Ruby IDE. One thing that I would love to have is the ability to 'compile' the scripts. I'm not interested in preventing reverse engineering or improved performance; I write code that may be put on a firewall or other secure machine. We don't allow interpreters or compilers on the systems, therefore I can't use rb2exe or similar programs as they require the interpreter.
I think part of the problem Ruby has, at least for now, is that most of the original work is in Japan. When I try to find information I usually have to work from a translation, or read code on a
--
Sounds like you perl junkies are looking for an excuse to ignore Python! -Paul Komarek
But since there are orders-of-magnitude problems that sometimes need to be solved, how does Ruby do in integration with C? Python seems to do fairly well -- though I haven't used it myself -- and putting certain operations in C is a good way to speed things up. Numeric Python seems to do a lot with this, for instance. How hard is it to do this in Ruby?
But that aside, Python isn't perfect, and there are definately places where it is too loose (mostly in its object system, IMHO), and too strict (the indentation thing can be annoying sometimes -- and damn the person who invented tabs!)
But Python is pretty okay. And it's only like Perl in that they are both mostly procedural languages. I'd like Ruby for its OO system, and the clever tricks it allows. (I haven't actually used it, but I've used Smalltalk, and the abstractions that Smalltalk made and Ruby copied are really good) But why, oh why, did it have to use Perl syntax? Who would ever want such a thing? If they did, they'd use Perl. Or awk. Or bash. Or C. Or all the other stupid languages Perl took its syntax from. People who like Perl seem to like Perl. People who hate Perl come to Python. Ruby's syntax seemed to be an attempt to seduce Perlites to Ruby, when it would have been a better tactic to rally against Perl. People who would like Ruby probably weren't ever happy with Perl anyway.
Python was the right thing at the right time (and even then it was just Yet Another Scripting Language for some time). It defined itself in a compelling way. Ruby was just a little too late and not compelling enough to any one audience -- somewhat compelling to several audiences, but you need to do better than somewhat.
Probably didn't help that it came out of Japan either, as Japan doesn't really seem to be in the loop when it comes to free/open source software (language barriers?)
I think the real benefit of OO for scripting is it is a good metaphor to use when organizing the standard library. And a good scripting language should have a good standard library. Not only that, it should have a good set of third-party libraries, which means you can't just hard-code the organization.
Why is it stupid? The majority of the total-cost-of-ownership of any system is in maintenance and support. It's nothing to do with "politics". Do you whine and complain about having to comment your code too? To write documentation? To submit to code reviews? Those nasty political managers, making you do your job like a professional!
Using a new language for its own sake, with no thought to its suitability is foolish. Its rare to find a specification which doesn't stipulate that a system should be developed with ease of maintenance and extension as key success criteria.
I for one hate office politics but they are a fact of life and explains why MS is so popular.
Like most slashbots, you can't let a post go by without a dig at MS, can you? Not that it's even slightly relevant here, of course.
Nah, part of building on what came before is knowing what to throw out. Perl 1 was very much a knockoff of `sh' scripting and `c' coding mixed with `awk' and `sed'. Larry Wall wanted a common interface and a more rational data model to tie them together with. From a broken but standardized scripting language to a cleaner syntax stolen from `c' and two of the best tools' tricks built directly in was athe basic plan there. Building on sh would have made it a nightmare.
And Python started out building a core OOP language with a script heart and syntax that was miles from it's closest rational starting point (Java).
Which language would you recommend we start from? To make it work well would require some nasty bolting-on in some languages.
The reason so many languages have become popular and why Ruby hasn't is one simple koan. "It must have a compelling reason to change."
Perls 1-4 had it (better, faster, cleaner shell scripting that was shell independent, regex). Perl 5 had it (oop and better code reuse, mush improved data model for an (by then) old standard. Python had it (clean pre-planned syntax, clean oop, death to braces). Scheme had it (throw out the old, revamp the syntax, speed up the core). C++ had it way back when (oop). Java had it (c++ ish with scriptability thanks to garbage collection, bytecode model). Javascript had it (ran in browser, simple syntax a "web programmer" could use and a real programmer didn't start crying [too much] over.) TCL had it (tk hookup, meta shell system, shell-ish syntax). Bash had it (un-borked sh, added kitchen sink).
What does Ruby really offer as a compelling reason to change? Honestly. Just a "better" perlish syntax and newer oop? Is that compelling enough? Better international support? Compelling for the Japanese users sure but for the english-speaking coders is that useful or a hinderance?
(Note the .sig, I might be _bit_ biased. =)
--
$you = new YOU;
$you = new YOU;
honk() if $you->love(perl)
It's not an excuse, I think it's more a case that if you are familiar enough with any language, the incentive to change must be pretty large to make it worthwhile.
:)
For example, I only learnt Perl originally because I had a problem I was originally using AWK for, but fell off the end of what AWK would do (filehandling in my case).
I've looked at Python on and off for a couple of years, and for most things I do, I find that doing them in Perl would be easier (for me, as a Perl user), and not worth the additional learning-curve time of Python. For larger projects, one of these days, I'll have another go
--
the telephone rings / problem between screen and chair / thoughts of homocide
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
Check out this link for what might be some interesting benchmarks. Ruby seems to do quite well against Perl and Python (and in some cases better), but in other cases it is downright awful (look at the recursion problems). Ruby is not as mature as Perl or Python, so there are definitely some places where it could be optimized better.
One thing you may want to consider is that Ruby has many different ways of doing loops; some of them open a new scope (which takes time), and others just iterate in the current scope. So where you may have:
1..1000000.each do |i|
j = j + 1
end
You may want to rewrite as:
for i in 1..1000000 do
j = j + 1
end
or even:
1000000.times do
j = j.succ # faster than j = j + 1
end
An Anonymous Coward writes:
In Perl, "missing data" normally generates "Use of uninitialized value" warnings. You are using -w, right?
Yes, I use -w, and even "use strict" but that doesn't stop me from using
my ($a, $b, $c) = split("\t", $_);
on tab-delimited data. If one of the fields is not there no warning will be issued (and that's the way I like it)
I'm not familiar with Ruby, but it sounds like Ruby's "nil" is equivalent to Perl's "undef" and C/Java/etc's "null", which is generally considered a good thing as it catches many logic errors before they can do more serious harm.
Of course, at some point you have to admit that a scripting language that is as strict as a compiled language is pretty useless (because then, why not write in the compiled language?). Of course, where that point lies is a matter for debate.
That's like saying "why complicate things with another means of transportation when we already have horses, feet, dogsleds, etc. etc.?"
Bad analogy. There is real progress in transportation -- new methods are cheaper, faster, etc. There is no real progress in programming languages. All of them (sans a few mini-languages) are Turing complete and so are objectively exactly the same. Everything else is merely a matter of taste. Quite a few engineers and natural scientists still use FORTRAN, after all.
You seem to think that functional languages are somehow more "advanced" than procedural languages. There is no objective reason to support this conclusion -- it is like saying chocolate ice cream is more advanced than strawberry
On the other hand, I have to admit that I'm a sucker for new languages myself. I *know* that new languages can't really make me more productive, but they sure are fun.
I have been fiddling around with Ruby and while I think that it is much cleaner than Perl and even Python, I am still mostly using Perl. One of the reasons is the relatively uninteresting reason that other people I work with use Perl, but some have to do with annoyances of Ruby:
.to_i, etc., but it is too easy to forget to use them when needed.
1) In Ruby, strings and Numbers both use < and > for comparison. Why is this bad? Isn't it cleaner to do this rather than bother with Perl's "le" and "ge" for strings and <, >, for numbers? Yes, but: In Ruby there is no autoconversion like in perl. If I use "split" to generate an array of fields from a columned list of numbers, those numbers will not be numbers, but strings. This means they will be compared as strings, screwing up numerical order. Bad, Bad, Bad, Bad! Yes, I *know* Ruby has
2) nil is not equal to zero. This means in data with variable numbers of fields, you have to write code that handles this case -- it isn't like Perl where missing data is treated as 0 or "" depending on the context. Yes, maybe Ruby's way is cleaner, but it is annoying in practice.
You just defined the class chair. It wasn't an existing type. Nobody is claining that Puthon doesn't allow inheritance of user classes.
For example, why doesn't all business application development get done in COBOL, or FORTRAN, or C, or C++? Because newer languages are more productive
Certainly not all code is written in those four languages, but the majority of business applications *are* written in one of them. Functional languages have comparatively little support outside academia, and even there they are fading somewhat because their typical use, symbolic AI, is no longer the "hot" area of CS.
There are plenty of objective reasons, but they probably go beyond the scope of a
There is a reason why arguments about editors and programming languages are termed "religious wars". Any such "proof" of the superiority of one language over another can be easily denied by the supporters of another language exactly in the manner of religious arguments.
As another poster mentioned, Unlambda and Intercal are also Turing complete, and their existence alone effectively disproves your argument.
Oh, hardly. Those joke languages are hard only because they are so *different* from what we are used to. To give an analogy from human languages, I can say Chinese is hard because it has all those tones, and Chinese speakers can say English is hard because it has all those verb tenses. It's all about what you are used to.
The question is how long it will take, and how much effort you will have to expend to get there. Advances in programming languages are quite closely analogous.
Not really. Someone writing in a language that they like and know well is more productive than someone writing in a language they hate or don't know well. To bring this back to the topic of the article, which scripting language is best? It's all subjective. I hate tcl, for example, but some people love it.
How do you know this? And which languages do you know? If you've never experienced the productivity differences between different languages, you can't be familiar with much of a variety of them.
I know from experience, and I know quite a few, languages having programmed since 1981. let's see:
Basic, Pascal, C, C++, Java, Forth, Actor, Perl, Python, Ruby, tcl, awk, Smalltalk-80, Emacs Lisp, ML, Eiffel
What I have found however, is that different *implementations* of languages can provide quite a productivity difference. For example, some FORTHs have quite a few words defined, and others have only the basics. But that isn't a function of the language itself.
mod_ruby has been around for a while, and last I looked there were several templating systems.
Got time? Spend some of it coding or testing
> Just substitute RUBY with LINUX, and language with operating system.
Ballocks. Linux is Unix, or close enough that I could find my way around it on the first day after using Solaris after a year. Unix software has been around for eons compared to most equivalent windows solutions, not to mention the OS itself. There's expect scripts still running that are older than NT. Linux was hardly an odd shape that required a new hole to be carved for it.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
> What I think is missing is a good scripting language implementation that takes full advantage of C++.
:)
Take a look at ColdStore sometime. It's an interesting approach to designing languages, and IMHO a better one: writing the runtime environment first, then targeting several languages to the environment, including existing ones like OpenC++ (C++ with a meta-object protocol) and Python (as a module), and new ones like Chaos (a "toy" RPN language that's a cross between forth and tcl) and freon (a "real" language deriving from C++ and smalltalk). It supports orthogonal object persistence (the "store" in coldstore, which lets you stop the program, start it again, all your objects are there like you never stopped, no need to explicitly save and load), and an introspective interpreter able to modify the parse tree at runtime (lets you have "interesting" control structures, MOP, intentional programming, etc). Since it is knowledgeable about the C++ ABI (gcc's ABI anyway) from object layout to symbol mangling, it should be able to script arbitrary C++ classes as well. And since the persistent store can be dlopened as an ordinary C++ shared library, other applications can make easily use of it.
It's still a work in progress, but the persistence does already work with OpenC++ and Python, and the way it implements it makes it super fast compared to any other persistence scheme currently in existence. It's shaping up to be an awesome language runtime too, and of course it's written in C++
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
The easiest answer is: Because it's not Perl.
The second easiest answer is: Because it's not what I'm using now.
Seriously, Ruby has some nice features, but most of them are 100% sugar and *really* weird to someone who expects it to be "perl, only clean and logical"...
I'll stick with my dirty Perl, thank you.
-- To dream a dream is grand, but to live it is divine. -- Leto ][
I think you will find that this is not Ruby the scripting language, but instead the concept of ruby text, used in the formatting of eastern languages and in complex run-on formatting.
From the reference document in the XHTML recommendation: "Ruby" are short runs of text alongside the base text, typically used in East Asian documents to indicate pronunciation or to provide a short annotation. This specification defines markup for ruby, in the form of an XHTML module
See the following URL http://www.w3.org/TR/2001/REC-ruby-20010531/ for more details.
S.
Good point. I'd like to add that the reason I currently use Perl and not Python (or Ruby) is similar to (one of) the reason(s) I use Vi and not Emacs - Vi or a clone is available on most every platform, and is a quick download if it's not. Emacs isn't. Perl is available on most everything I use [as a sysadmin in a mixed Linux/Win32/Mac environment]. Therefore, when choosing a language/editor to get proficient at, I choose the language that will give me the most bang for my buck. Perl does darn near everything I need easily, and is far and away the easiest way for me to write apps that will run on *nix, Win32, and MacOS with no changes (Java doesn't count, because I really dislike it ;)).
That said, as soon as I find a problem that Ruby looks better suited for than Perl (I'm looking), I'll take the time to learn it. Being really good at something is good, but flexibility is a good thing too... :) Is Ruby available for Win32 and/or MacOS?
Huh????? Ruby is exactly as strict as Python is.
I do not agree. Ruby implements TMTOWTDI, which Python generally doesn't. Perhaps I expressed myself unclearly, so that you interpreted me as meaning loose as in e.g. "loosely typed". I was reffering to syntax.
Let me explain.
Say I want to do something if a certain boolean variable is false. In Python, I do that in this way:
if not var:
dosomething
In Ruby I can select one of four different syntaxes:
if not var
dosomething
end
unless var
dosomething
end
dosomething if not var
dosomething unless var
These four different syntaxes perform exactly the same thing, but uses different keywords in different orders. That is the TMTOWTDI idea, and it makes Ruby a lot "looser" than Python, syntax-wise.
I'm sure Ruby is better than Perl. But 1st I don't have time to learn another language which isn't "different" enough. And 2nd I don't know what to do with another language. Can't use it at work, because no one else knows Ruby. And can't use it for me and my friends and people I know. They would have to install Ruby and all the cool libraries for it.
No, these things, for all practical purposes, can't be fixed "when the time comes." The time came and went. If you're going to create some classes that are going to be reused by lots of other people, you can't go making all your methods take a StringValue rather than a String. Nobody will ever use that. (Especially when they're also confronted with another package that takes ImmutableString as parameters, and a third that takes....well, you get the idea.) You instead take the expedient, inefficent route of cloning every String parameter you get.
The world's most portable OS: http://www.netbsd.org.
In theory, languages are not libraries. In practice, I'm sorry, they are. How many people do you know using Java that don't use the classes in java.lang and java.util? Would you do that? It's even been pointed out here time and time again: one of the huge advantages of perl is the massive number of modules out there to do the work for you. People use perl for just that reason. Anyway, I think I can put an end to the argument this way: given basically one language change (the 'char' primitive data type holds a Unicode character), and all the library changes I asked for, yes, I'd be far, far more inclined to use Ruby. So I'll just sit tight now until someone presents me with that version to compile up and run on my system, and shows me that lots of modules for that version of Ruby are becoming available, so I don't have to write much stuff from scratch....
The world's most portable OS: http://www.netbsd.org.
1. Python supports HTTPS natively. Brian Gallew contributed OpenSSL support for the socket module in Python 2.0. At the same time the httplib and urlllib modules were modified to support https URLs.
2. tk if you use cPython, swing if you use jython.
3. use the right tool for the right job.
4. see #2.
5. This doesn't make sense to me. A stack is something you can push and pop. What other operations do you want? Pushing and popping IS a real stack.
I rather like Ruby. And I don't like Python's use of whitespace.
OTOH:
1) I don't read Japanese, so many of the extensions aren't useable.
2) Like Python and Java, it's slow. (What do you expect of an interpreter?)
3) I like to use IDE's. I like to use Linux. But the only IDE that I know of for Ruby is win32 only.
OTOH:
1) It's crossplatform to every platform I use.
2) It's supposed to be easy to link to c (I haven't tried yet).
3) It's got an free source license. Python has one for 2.0a, and the next release should have one...but 2.1 doesn't, quite. Forget java here, except for gcj, and a few other independant Java clones. (And I'm going to wait until gcc 3 comes with the distribution before I install it. Too many problems otherwise.)
The upshot is: Sometimes I use Ruby. I like it, but I haven't used it enough to really learn it.
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
Free is subject to many definitions. My favorite is GPL compliant. 2.1a or 2.1.1 will be. 2.0.1 is. Please check the Python website.
This doesn't matter much any more, but the UCITA in combination with Python's current "Laws of Virginia" clause have caused me to refrain from using it recently. Which is one of the reasons that I checked out Ruby.
I will agree that the license is, barring the "Virginia" clause, an excellent one. But Virginia is a UCITA state, and until I feel clear about what the UCITA can and cannot do, then I will avoid agreements that invoke it.
So far, the only good thing I heard attributed to the UCITA is that it breaks the MS license. And that's the Maryland version. And there have been some rather scary potential interpretations of pieces of it. I'll wait until various courts have their say. And until they have, I'll just avoid it.
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
Change aversion compounds on itself. People avoid new things that replace their old things, because they fear change. The more they do this, the more risky and costly it is to change. The fear grows. Why else would such a large percentage of desktops be running Windows when MacOS, BeOS, Linux, *BSD, etc. have been around to provide something that is in many cases much better?
To quote from your post:
"I say Object Oriented Programming is highly overrated."
If it's "not just procedural and OO", then why are you saying OOP is highly overrated? That implies that procedural programming is not overrated, and thus better than OOP.
This may not be what you meant to say, but that's how it sounds.
A Government Is a Body of People, Usually Notably Ungoverned
Well, I guess there are three comments to make here.
Now, I have been a Perl programmer since the 4.036 days, and I will undoubtedly continue to use it a lot. But, at least in one interview, Larry Wall himself noted that the design and ideas behind Ruby were deep and yet not merely academic curiosities. I, for one, have been waiting a long time for a language that could afford the creation of code as succinct as Perl's without some of the collateral weirdness. (Random example of the day: I *hate* the fact that things as useful as "chomp" have nearly useless values.)
In the mean time, I don't know about you, but I'm having a blast learning new things and finding out what I do and don't appreciate about the old. return values
Babar
We tend to switch languages not because something is 'better' in some way.. there will *always* be some new language that is 'better' than the previous one. We switch through necessity.
Example: People started using perl because it was better and more convenient than sed/awk/shell. Then came the internet, and cgi-scripts... perl just happened to fit in there nicely. Other developments followed as it gained in popularity, and now it's used for tons of stuff. Lots of work has been put into speeding it up; embedding it into web servers for faster execution of code. Lots of supporting work and material out there. CPAN. Etc....
Then Python. Python is unique enough to warrant a good following; OSS, elegance, nice OO language. Doesn't stop people from using perl though, although some people switched because they like OO better.
Now Ruby. What cna I say about Ruby? I don't know much about it.. but does it offer an order of magnitude more flexibility than perl and/or python currently offers? I doubt it. Sure, it may be nicer, more elegant.. but perl and python are rather elegant at doing what they do.
Irrational prejudice against (or for) "hacker" versus "corporate" things is silly - but preferring familiar, well-known, well-documented, easily-supported tools over more avant-garde or experimental things, where reliability and uptime and long-term persistence is important is not silly.
That's the same argument that works for open-source tools in the long run - while they don't always look as safe as their closed-source competitors in their early years, as they get more mature and a userbase develops, they become safer - e.g., Commodore can kill off the Amiga, IBM can stop making OS/2, and Microsoft can stop selling MS-DOS, but nobody can kill Linux or Perl, because there's such a big installed base that they'll be user-supported for the next 20 or 30 years, no matter what happens.
Ruby is being used as an optional extension language for Vim 6. Much of the documentation of Ruby is just now being translated to English. Python lacks true closures, whereas Ruby does not. Love it or hate it, Ruby has operator overloading. In the case for "scripting" languages, this seems useful. Ruby is faster than Python. Ruby is not statically typed.
-Gwizdak.
That is correct but, as I already pointed out, language and implementation efficiency can sometimes affect efficiency issue if the programmer has to go outside the language and leave its semantic benefits behind to get adequate performance.
Again correct, and if you had read my other post on this topic you might have noticed that I already pointed out that both criticisms are similarly pointless. I only mentioned it because it was being touted as an *advantage* of Ruby when in fact - like Python's indentation - it's an unnecessary fixable/avoidable wart. In fact my point was rather anti-fascist, in that I explicitly objected to the way Ruby forces people to adhere to what should be a voluntary convention.
Your comments might be a lot more welcome if you'd try reading what you're responding to, and/or not paraphrasing others' previous statements as though they were your own unique insights.
Slashdot - News for Herds. Stuff that Splatters.
Often? No. Recomputed instance variables like that are *vastly* outnumbered by instance variables that are simply read and written, by one or two orders of magnitude. Why optimize for the extremely rare case? The same effect can be had with explicit accessors, which also give a clear signal to the programmer that there might be side effects and don't double your stack size by filling the stack with accessor frames (yes, it matters in some environments). A convenient notation for accessor functions would be nice for when they are appropriate, but making them the default is just a mistake.
Any non-trivial accessor function might have side effects, including not just obvious side effects such as modification of a global but also delays (causing timeouts elsewhere in the code) or locking errors. Such problems, "hidden" in what the programmer might think is a simple variable access, can be a pain to debug. Besides that, there's always some idiot who thinks it's clever to override an accessor in a way that's incompatible with the original class designer's intent - leading to even "spookier" kinds of errors. Accessor functions have their uses, but using them safely requires more care than I give the average programmer credit for. Again, they should be available but not the default.
Slashdot - News for Herds. Stuff that Splatters.
For me, a good scripting language must have three features:
As it turns out, Perl and Tcl both fail with regard to #1 and #3, so I use Python. Ruby seems fully competitive to Python with regard to #1 and #2; sure, I find the use of variable punctuation to indicate scope abominable, but a lot of people loathe Python's use of indentation to indicate program structure, so I'm happy to call the race even.
That leaves #3 as the most important aspect distinguishing Ruby from Python. Does anyone know of a good description of Ruby's extension interface, or perhaps a good example of an extension module? I've become pretty comfortable with Python's extension interface, but there's some room for improvement. If Ruby's extension interface is cleaner and/or more powerful than Python's, then I might actually consider it as an alternative for my next project. Probably not, because it seems highly unlikely that Ruby's extension interface is *so* superior to Python's that it justifies the time investment and short-term loss of productivity that switching would inevitably require. The key point though, is not about what *I* as an established Python user might do. What's more important is how I should answer the next time *someone else* asks me which language to learn or use. If Ruby can meet this standard, my recommendation might well be to go with Ruby (even as I continue to use Python myself).
Slashdot - News for Herds. Stuff that Splatters.
Why even spend the 2 days for something I don't need? (And really, there's no way the total cost of adopting a new programming technology could ever be 2 days.)
As for not having a clue, here's my clue: I don't need a new programming technology. That's enough of a clue to decide not to go chasing after promises of new programming technologies. Good enough for me. Is it good enough for you? (Who cares.)
While it is true that UTC is not GMT, they are close enough to each other for nearly all practical purposes in a programming context. If you are handling astronomical or navigational data, you will care about the differences, but otherwise, probably not.
:)
I should also note that there are two UTC definitions. These days, when we say UTC, we usually mean UTC2, which is based on atomic clocks. Both GMT and UTC(1) are based on astronomical observations, with UTC(1) compensating for some local variations. Generally speaking, the differences ammount to not more than a few seconds.
Time zones are civil structures, where UTC/GMT times are really observations. Thus, time zone handling can be nearly irrational (after all, civil law makers were involved). In this context, using the observable time for all internal comparisons/storage/calculations makes a great deal of sense. This relegates time zones to input/output, which makes almost everything much simpler. You just need to remember that the hours value in the object is probably UTC, with the zone retained only for convenience.
Having said that, I'll note that the usual abbreviations for time zones are not unique, world wide, with some 3-letter abbreviations being used for several zones that are widely separated geographically. An additional complication comes from the various rules for going to/from daylight savings times.
If you were not already convinced, UTC is far simpler to use and stay sane with, and that is totally independent of your language of choice.
have a nice day
Knowing Latin certainly doesn't help you understand why you form sentences. In fact, if you did understand that, you could write a computer program to do it and become rich and famous overnight.
You may learn various grammatical properties (few of which Latin shares with English, but it's hard to learn another language without learning more about your own), and learn a lot of vocabulary which passed into English during the Renaissance, but that's about it.
Being a fluent native speaker, I feel quite certain that I understood English before I attempted to learn another language.
The ASM - C analogy does not compare to Latin-English, because C code (along with many languages) was designed to produce ASM, and C is at quite a low level above that, whereas English and Latin are more like distant cousins. Ebonics - English is closer to C - ASM (altho still not a particularly good analogy).
I think as long as it's use is based on it's usefullness (which has been the case with most scripting languages), it's only a matter of time.
Ruby has been as much of a pleasent surprise to me as Perl was back when I first learned it. No, it's not "Perl with Objects"; Perl itself does that quite well. It's more like Smalltalk, only readable, pragmatic rather than idealistic, and as expressive and concise as Perl when you want it to be. Personally, i think Ruby is a much greater threat to Perl than Python is, in the long run. Rather than forcing you to do it Guido's Way, you can do it the Perl Way, or the Smalltalk Way, or the Functional Way... or any combination of the above. No wonder the Pragmatic Programmers wrote a book on it. It does TMTOWTDI better than Perl does TMTOWTDI; while remaining relatively simple and clean.
So just give it time. I think it's well on it's way to world domination.
Oh, and as for a CPAN-like code archive for Ruby, there's a somewhat embrionic one here. There is discussion currently going on at the RubyWiki on how to implement a CPAN-like system for Ruby only avoiding the problems that CPAN has.
--
--
CPAN rules. - Guido van Rossum
Java takes up incredible amounts of RAM on my box, even accounting for shared memory. And why do we need another virtual machine language? Wasn't Icon first? True, Icon wasn't much like C, but C handles almost everything, and what it is poor for C, Perl or PHP will cover well.
These new languages like Ruby and Python don't seem to add anything to the realm of existing ideas. Maybe mix and match them in better ways, but nothing particularly innovative. (Feel free to contradict me through example!) I've always found Icon interesting though, since functions can return more than one value (called "generators") which is great for avoiding the messes of raw link-list programming etc.
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
I think that a lot of people feel a bit nervous to start a big programming project that will go through all the stages of development, right through to maintainance for two to five years, when the language used is not standardised.
You simply can't afford to let the language and the supporting libraries change too much when developing for the future. Using a language whos "version number" changes faster than Walt Disney's web site counter is simply not acceptable.
That's why C, C++ and Fortran are still so popular -- they haven't changed too much over the years. There's a new Fortran standard being released every four years, but if it was more frequently, people would stop using the language since they simply wouldn't trust the structure of the language to be stable.
Sure, yet another scripting language with all the bells and whistles is great fun and may be suitable for getting the small things done (small things == no real need for OOP), it's no use trying to deny that, but do you really want to put too much money into a project based on ad hoc standards?
It's 11pm, do you know what your deamons are up to?
New languages like Ruby usually require the programmer to reinvent libraries that have already been developed, tested, revised, retested, etc. in other languages.
In languages like Perl, Java and other really popular languages more than likely someone has already done what you want and you can build off of that. In Ruby, you may find yourself starting from less of a developed base than in other languages.
The good news is that people who want to make a name for themselves in the open source world can jump into the Ruby world and do some good work. Once a well-tested comprehensive base of library code is available then the language will develop some momentum (my opinion).
Also, how many books are there for Ruby...ONE, right? That's not enough to attract attention at a bookstore. It also makes it more difficult for people to learn.
I "played" with Ruby under Windows and have the so-called Pick-axe book and found the language nice but in terms of usage now: how many hosting services allow server side scripting with Ruby? For simple utilities my Perl skills are better than my Ruby skills so I don't change since I want to get tools done fast.
So, my opinion is that Ruby isn't "popular" simply because it needs more time to be accessible to more people and not because of technical reasons.
I should also mention that an overview of Ruby syntax, for those interested, can be found at Dr. Dobb's Journal.
Let's say I want to iterate over a list in Python. I'd "map(a_function, a_list)". "map" applies a_function to each element of a_list, creating a new list as it goes along. It doesn't entail side effects; the original list isn't modified. You'll find a function similar to this in nearly every language; any implementation of lists in any language should provide such a facility (and Ruby provides that facility via its iterators.)
I prefer the Python/Lisp/O'Caml way. I, like more intelligent people who have gone before me, see iterators in object-oriented languages as a sign of weakness. Ruby's iterators exist to work around the fact that functions aren't first class objects in Ruby. They exist because a programmer can't write higher order functions in Ruby.
As beautiful as "pure" languages like Java and Haskell and Ruby are, they'll always lose in practice to languages that implement multiple programming paradigms well, like O'Caml, and Lisp, and Python. Programmers don't need to be contrained by their language, restricted to programming in a particular way or paradigm because that's the way the author/designer of the language decided it should be. In O'Caml or Python or Lisp, they're not. In Ruby, iterators are a perfect example of how they are.
Jeremy
--
Looking for a Python IRC bot?
Pop pops an element anywhere in the list. Not just at the end, as the Perl version does. You can use .append and .pop to treat a list like a stack very easily. Complaining because .append isn't also called .push seems remarkably petty to me.
Perhaps "overloaded" is defined differently in your dictionary, but whitespace has one purpose in Python: as a delimiter, for blocks and for tokens. Indent your code as a good coder would indent his code (note: I didn't say how you would indent your code, I don't know what your Perl code looks like :)) and you'll experience absolutely no difficulties writing your own code or reading others'. And believe me, when you leave the Perl world and learn that code can actually be read by someone other than he who wrote it, you'll be astounded.
Please, explain how this is so. I'm curious.
Do you prefer proof, or unsupported assertions? Me, personally, I'm a big fan of proof, but I'm having some trouble finding it in your posts. Maybe you can enlighten me.
I found the assertion, but again, I couldn't find the proof. Perhaps you can provide some.
Stackless provides continuations. Their utility is questionable, at best -- there's a reason Scheme includes it, but Common Lisp doesn't -- Standard ML includes it, but O'Caml doesn't. The argument has raged a long time on both sides, with no signs of letting up.
I'd like to see them in the language, but not if it costs the simplicity of the language. It's definitely not something that is required for Python to be "truly unique and kickass" -- it already is.
Jeremy
--
Looking for a Python IRC bot?
Those are not run-on sentences. They are grammatically correct. :)
I think the fact that you find Ruby's iterating style strange is because you didn't understand it. I know I didn't get it when I first looked at it. For example, what you'd do in Java with something like: Iterator i = myList.iterator() while (i.hasNext()) { SomeObject a = (SomeObject) i.next(); //some stuff on a...
}
you'd do in Ruby like this:
myList.each { |a|
#some stuff on a...
}
What's happening is that the stuff in the curly braces gets turned into a Proc object (Oh, by the way, instead of just making functions objects, Ruby lets you turn blocks of code into objects which retain their context.) which gets passed to the each function, which in turn assigns each element of the list to a and executes the Proc.
I have no idea how you'd do that in Python... (which certainly isn't to say that you can't...)
No, I don't mean that the argument is old (though it is), but that this post smells of a template with filled-in blanks.
Anyway, since I'm here, let me bait.
Bosses of bosses don't care about which language or operating systems or other technical mantra you are using, as long as it works. When it doesn't, well, then _YOU_ are in deep sh*t, not them.
And technical managers worthing their wage know that in today world either you innovate or you die. And today Very High Level Languages (like Ruby, Perl and Python) gives to software development companies so many advantages than you cannot ignore them and hope to be around tomorrow.
Ciao
----
FB
However, it does a number of new things which I don't think could have been included in either Python and Perl interprters (wrt to Python: Full garbage collection, everithing is an object approach (including built-in types), and more
That is why a new language. And if a community forms around it, it means that maybe it was needed.
Ciao
----
FB
In the Church-Turing sense, we only need one programming language (or processor, for that matter), but practically speaking it would make programming hell. The question is when do we reach the point of diminishing returns in writing yet another scripting/prototyping language, and how do we know? I personally would just as soon people experiment, until such time as we can prove a language optimal for a class of problems.
CPAN.
That's the draw of perl for rapid application development using reusable (well-tested) code. It's awesome.
--
-- @rjamestaylor on Ello
XHTML 1.1 incorporates Ruby.
Someone please mod it back down. It's a different "ruby", not the scripting language discussed.
If you open yourself to the foo, You and foo become one.
I must admit, one of the things I do like about Ruby is it's sensical enumeration/iteration, which really borrows from Smalltalk. C++ and Java with their Iterators, Perl with foreach, Python with for x in... - they all just seem so messy compared to the Smalltalk and Ruby way of doing things.
:object | object someMethod ].
:object | object hash ].
:= #(1 2 3 4 5 6 7 8 9 10). "array literal"
:num | num > 5].
:= #($a $b $C $d $O). "array of characters"
:aChar | aChar isLowercase].
Your example in Smalltalk:
myList do: [
It doesn't end there. Smalltalk's Collection classes have a bunch of really cool methods that do various kinds of iteration.
"returns a new collection with the results of sending the #hash message (or in the parlance of other languages, calling a method) to each of the objects in myList."
myList collect: [
"returns all objects that are greater than 5. this can be used for anything, not just numbers. returns a collection with all objects that respond with true."
| anArray | "declare a temp. variable"
anArray
anArray select: [
"returns a collection with uppercase characters"
| anArray |
anArray
anArray reject: [
There are a bunch more, but I would say those are the most common. It just makes for a really clean way to deal with all sorts of collections, and I'm glad to see that Ruby adopted this way (roughly), and didn't stick with the archaic ways found in Perl, Python, C++, and Java.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Iterators ala C++ and Java are not an inherent weakness of OO language, simply of languages that use them. Smalltalk, the original, fully OO language has nothing like Java/C++ implementors. I don't think you understand the way Ruby interates/enumerates, as it also doesn't have iterators like Java/C++. Things between begin and end in Ruby are first class closures, IIRC.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
A necessary part (as stated by Alan Kay) of OO is that it must support inheritence, or else it's not truly OO. While you may not yourself think it important, it is a vital part of OO.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
You got it almost right. Simula is missing OO features that are found in Smalltalk. One is, Simula lacks class variables. Relatively minor, and a missing feature in a lot of so-called OO languages.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I've had a look at F-Script, mostly because it is a Smalltalk-like language that has is closely tied with Cocoa, can interact with Objective-C objects with no problem, and thus has a AppKit binding with Mac OS X. If you have a look at the Array class (in the Users Classes section of the F-Script manual), you'll see the \ method is basically a somewhat-more-sense-making #inject:into: method.
:subTotal :next | subTotal + next].
The F-Script example:
{1,2,3,4,5} \ #+
is executed as if it were 1+2+3+4+5 and returns 15.
In Smalltalk:
#(1 2 3 4 5) inject: 0 into: [
F-Script is pretty interesting, and looks like a promising alternative to Objective-C, C, and C++ for Mac developers.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
If you like Haskell, but want a mission critical ready implementation you will have to try a slightly different functional language called Clean, which has everything Haskell has as far as purity, expressiveness, elegance, rock-solid static type checking (most important feature IMO), lazy evaluation, and Clean has more like Linear (Uniqueness) Types ala Girard's Linear Logic, which allow you to have greater control over system resources, yet still maintaining functional purity and expressiveness.
GUI Spreasheet programs have been written in Clean. Video Games have been written in Clean, and even Clean's GUI integrated development environment and compiler are written in clean. There is only one problem with Clean... it is proprietary, but don't let that detract you for playing around with it for non-profit use.
Check out Clean here. You only have to pay money for the compiler if you want to use it for commercial purposes. I started out learning Functional Programming with Haskell, which is a favorite language of mine, but I ended up seeing the brilliance of Clean as a language that has the beauty of Haskell yet can still "get things done".
Imperative and functional languages can easily be directly compared to eachother, and it has been argued time and time again that imperative languages lack the type checking features available in modern functional languages. Imperative languages also fall short when you want to formally verify aspects of your code. Functional languages have wonderful easy to use algebraic properties that lend to easy verification compared to imperative programs which lack referential transparency. I think that I even remember the father of imperative languages saying at a key speech of his, that functional programming was the right way to go and that imperative programming was the wrong path.
However, it is my theory that the newer mobile calculi such as the pi-calculus and ambient-calculus will lead to a canonical generalization of all of the various paradigms, from imperative to object to functional to logic. Once that generalization is found, there will be one language for all jobs.
I still hold that FP and Procedural Programming can be compared directly, and many have done so over the past decades. Both languages are used to describe the same thing, so they aren't as different as apples and oranges. Anyway, FP nor PP will be the wave of the future. Read below...
Recent research in Linear Logic and Mobile calculi show the possibility of a programming language that is simple and elegant yet is a generalization of functional, imperative, and object-oriented programming languages. Mozart-Oz is kind of a hack compared to the more recent stuff (but still very interesting). Check it out here! The site has info on free mobile languages (don't think they are all ultra-complex like Mozart-Oz).
I first discovered Ruby about 1 1/2 year ago, and was greatly impressed. The language combines most of the good qualities of both Perl (ability to write compact code, TMTOWTDI, useful one-liners, etc) and Python (readability, orthogonality, actual language design and not just evolution), and adds a few other goodies from Smalltalk (code-blocks, garbage collection, etc).
But my immediate reaction was also: Why do we need yet another scripting language? We already have Perl, Python and Tcl, which together should fill most niches people have for scripting in the Unix world. And the few people who aren't happy with e.g. reference counting, but want something academically pleasing would probably not look for a "practical" scripting language, but go with something like Scheme, Haskell or other "clean" languages. (I know, as I've been using SML for scripting purposes myself, simply because SML was the programming language I worked in mostly at the time).
The timing of Ruby's arrival couldn't be much worse. Back in the days of only Perl and Tcl, many people (including myself) were looking for something cleaner. After Python arrived, this niche was mostly filled, and the few people who wasn't at least 80% happy with one of the three scripting languages doesn't make up enough people to really make a difference. Besides, Ruby had all the disadvantages of a newcomer, immaturity (I notices some serious GC performance problems when I tested it on some toy problems in mathematics), incomplete documentation, few users, and so on.
So who would the Ruby user be? To be true, I wouldn't want to convince my company to use Ruby. Ruby is still immature, underdocumented, and it still haven't found it's niche market. For problems suitable to Perl, I use Perl, not Ruby. Why? Because code has to be maintained later (hopefully not by me), and because we don't want to install third party software everywhere to suit every developers whim.
Unless you can point me to a task where Ruby is really much better than all of Perl, Python and Tcl, then I will not adopt it. It is too much of a hassle for me, compared to the tiny benefits it might have if I took the time to learn it properly enough for me to be as effective in Perl.
In summary, the enthusiasm over Ruby is not bad. It is a great language, and certainly better than Python, Ruby or Tcl when it comes to language design, although most likely not implementation (unless something drastically happened while I were away). But the benefits of using it is simply not great enough for all the disadvantages in learning yet another scripting language and supporting it where we need to use it.
Besides, I doubt more shit means better jobs. A good job is somewhere where you can simply do your thing, and get paid for it, not somewhere where you will have to incorporate every buzzword in a project description to be able to get something done (even if you get paid more). Let's face it, new doesn't mean better. For what it does, Fortran is a great language. It lets you get things done.
And if you really believe open source will magically give you faster development, then you really need a reality check. While it might be true of some specific projects, it is certainly not a universal truth. Put 3-5 fulltime developers on a project, or 100 student hobbyists and watch who can keep up with deadlines. Open source certainly has some benefits (especially for the customer), but it is certainly not a silber bullet.
as I write this, modded up two, and down two.
A good sign you have written a valuable and thought provoking post. Too bad there's no way to elevate a post that generates a lot of modding that leaves it about even with where it started as these are often the most worth actually reading and responding to.
KFG
This isn't strictly true. English and Latin sort of have a cousins relationship -- a lot of the structure of English relates to Latin because English's ancestral languages came from the same roots as Latin did.
In fact the similarity is responsible for "rules" like "it's a bad idea to ever split an infinitive"; people got the idea that English had to conform to Latin as much as possible and tried to impose grammatical rules that simply made no sense.
/brian
The idea that "the only things that I can think about are the things that my language has words for" is better known as the Sapir-Whorf Hypothesis, and for reasons why many people consider it to be wrong, look through the links of this Google search.
Have fun: Join D.N.A. (National Dyslexics Association)
I'm not a Ruby advocate, but your post illustrates issues which are common to nearly all of the /. posts on programming language issues.
Another thing I often see on /. is people praising language X because it has an IDE, or a debugger, or a profiler, or fast garbage collection, or good error messages, or dynamic linking, or an interactive interpreter or a fast compiler. These are properties of the language implementation, not the language itself, and thus say nothing of interest about the quality of the language design.
Lastly, if you choose one language over another solely on the basis of surface issues such as the size of its available libraries, its syntax or the quality of its implementation, then that suggests that there really is not much difference between the two.
The only solid criterion I know for comparing languages which does not revolve around holy issues (e.g., static vs. dynamic typing) is locality. Language X is better than language Y with respect to feature F if in X you can use F to write code localized to one part of the program, which in Y you would be forced to spread globally all over the program to get the same effect. Features which satisfy this criterion are things like objects, higher-order functions, first-class continuations, logical constraint variables, etc. It can be shown that, thanks to such a feature F, programs of language X may be exponentially smaller than programs of language Y. Features which don't satisfy this criterion will lead at wost to linear size differences in the lengths of programs, and can thus be adequately addressed by macro-processing. (Not that I advocate macros...)
BH
BH
Fools! They laughed at me at the Sorbonne...!
Anyway, by your definition, ANSI C supports operator overloading since you could write a couple of "int MultiplyInt(int, int);" etc. etc. functions.
Generally, "operator overloading" means overloading the specific character(s) that make up the operator. By my (and I think the general) definition, C++ allows operator overloading, C (any, by your description, Python) doesn't.
Anyway, I like Ruby even though I'm just learning it now. I think the reason I like it better than any other language I've dealt with recently is that, since it's new, many people are learning it together. The people I've asked for help are friendly and helpful.
Try going to comp.c.plus.plus.moderated and enter a snippet of code that starts "void main(void) {". Half the people there will act like you pissed on their mom no matter what your question is... It doesn't affect me -- I'm past that level of C++ coding -- but it bothers me that so much mental bandwidth is wasted.
Waltz, nymph, for quick jigs vex Bud.
If anybody who's read Programming Ruby would like to review it on The Assayer, it would be greatly appreciated. Review it here.
The Assayer - free-information book reviews
Find free books.
No. It is a language because it has rules-- and yes, the rules are filled with exceptions and the rules are constantly changing: new words are made fairly often, new constructions appear (think of "verbing"). Humans learn languages through repetition and pattern recognition. Rules are inherent, because language that was not consistent from use to use and which had no recognizable patterns would be impossible to learn unless it was actually a constructed language and one had a reference book in which one could look up previously unused constructions. Whether we choose a set of those rules and make them the "right" or "official" version of the language is a different matter.
As to computer languages, I agree that the more they look like English the worse they have done... but oddly there are languages like Perl which are natural language oriented (with things like pronouns, context, etc) and seem to be relatively successful.
I do not have a signature
It is an ultra cool geek language. You can program and see results immediately. The syntax is ultra-clean. It's WORA. And the whole system is under an extremely liberal license.
It's almost perfect, but there are drawbacks to it.Python is missing:
Native HTTPS support.
Good widget set (small, portable, and simple - preferably built in too).
Native compiler (bytecode is great...but for some things it's too slow. Gimme a binary).
Powerful graphics primitives.
Easier stack manipulation (hacked pushing and popping isn't a real stack, guys)
Some of these shortcomings are present in other languages, like REBOL and Java, and of course the incredible Squeak (add your own primitives and customize the entire VM in a subset of the language itself)!
But overall, Python is still my favourite language, and I know a few (Squeak/Smalltalk, C, tons of Basic variants, Java, Shell, and a bit of Perl)....but it WOULD be nice if the Python team addressed the concerns above.
"A few atoms won't even light a match" - Dr Jones, 1933
I would have to agree. With what you have said. I think I may be a little different though I love to learn new languages and I tend to use the best language for the job not what I learned first. Except for the whole english thing I always use english even though it may not be the best. But I mean how many programmers really talk to people if it was not for slashdot we would not need english damn you slashdot :-)
-- Tyler >+++++++[-]++++.---------.+.++++.++.
What I said was modified slightly. Here are some things you may want to know. I have been programming perl for many years and it is great. I have just been looking at Ruby lately and it has some great features. All of you that say OOP is bad have you used smalltalk or ruby? The way they handle it is great. In my opinion(remeber my opinion) OOP in java, c++, python is kind of clumsy and with perl I think creating classes is clumsy but I think using them is pretty slick. I think that OOP is handled pretty good in Ruby it is there but is not got the hack feel that say IMO java does. Mind you these are all good languages and have there place. I believe that every language has its place. And like mentioned before the more you learn and the more views you view programming from the better you will be. Also so you know I am a language whore I learn all that I can so I tend to play with a langauge before most people may even have heard of it. Now back to Ruby here is a link that has a great list of some of the coolest features of ruby. http://www.hypermetrics.com/ruby37.html
I know some say not another f*cking langauge. Well what I have to say to that is I am sure all people were saying that about C. They were probably like man what the hell is wrong with asm C is soooo slow. But now C is one of the top lanauges used today.
As you can tell I have a habit of just rambling on and not orginizing what I am saying oh well this is all just my 2 cents.
-- Tyler >+++++++[-]++++.---------.+.++++.++.
Um, no.
Speaking as a guy whose done a little maintenance programming, developers really need to at least try to make the rest of the software's life cycle tolerable. A company should attempt to restrict itself to as few technologies as are necessary both for its budget and for the sanity of the IT/programming staff.
Secondly, not all programming languages are the same. Some are radically different lisp . When I first looked at LISP and scheme it looked like gibberish. Now it looks like very clever gibberish. At any rate its not easy to transfer to an entirely different programming style.
Sure a good programmer ought to be able to learn a new language at an intermediate level in a month or two, but what if you've got to work with 15 different languages and you only know 8?
Finally, even if good programmer's could pick up languages quickly in a day and if it were worth their time to do so... we come across the problem that not everyone out there is a good programmer. A good programmer knows that and codes appropriately.
Another big argument for Ruby over Python used to be that Ruby was GPL but since there is a GPL Python this really does not stand, as well Perl is not GPL, so not much water there.
A couple of details: Pyton is not GPL, but it is available under a license which is GPL compatable, and certainly in any event good enough to satisfy the definitions of both Open Source and Free Software. Perl is (if memory serves) dual licensed, and one of the two license is in fact the GPL.
-Rob
PHP is good for the web, Perl is unbeatable as text processing language.
What is Ruby's advantage over all the rest that would make me take the time and learn it?
--
Two witches watched two watches.
--
Two witches watched two watches.
Which witch watched which watch?
That seems like a strawman. Larry could have built on any number of existing scripting languages, interpreted languages, and syntaxes. Whether he deliberately ignored prior art or just didn't know about it, I don't know. But it seems pretty clear that he took a kind of perverse pleasure in combining the most oddball elements of sed, awk, sh, and C syntax.
[ ...a good scripting language implementation that takes full advantage of C++.]
Which language would you recommend we start from? To make it work well would require some nasty bolting-on in some languages.
Huh? Why would implementing Perl6 or Python3 in C++ require some "nasty bolting-on"? God knows, the current implementations of those languages are messy enough internally that they could benefit from some abstractions.
What does Ruby really offer as a compelling reason to change?
I dunno, why do you ask me? I think Python and Perl are already superfluous, let alone Ruby. I think the only reason for using them is that they are widely available and have user communities. Technically, as far as I'm concerned, they seem to be much less efficient implementations of the interpreted dynamic languages we already had in the 1970's and 1980's
To me, the real question is why people keep reinventing the wheel. Technically, none of those languages break any ground compared to their predecessors of 30 years ago. In fact, on the whole, they are simply slowly retracing the early evolution of Lisp and Smalltalk. Perl and Python could have started out being as good as Perl 5.6 and Python 2.1 if they had built on what had come before.
In any case, I use Python for any kind of complex scripting and Perl as a replacement for many simple shell scripts. Lua is great for embedding because it's so compact. If Python didn't exist, I would probably be using Ruby, but Python 2.1 cleans up most of the rough corners of earlier versions of Python (scoping, etc.).
What I think is missing is a good scripting language implementation that takes full advantage of C++. Perl, Python, and Ruby (?) are C-based and require laborious manual bookkeeping when interfacing with C/C++ code (Swig helps but isn't a complete solution). The implementations themselves would also benefit from C++'s abstraction facilities.
I think the answer to the poster's question as to why Ruby hasn't gained as much support as other languages is that it doesn't add enough perceived value to persuade people to move away from they currently use. After many years of using Perl, I switched to Python because I was looking for something that I reckoned was more object-oriented, cleaner and more explicable - I imagine similar reasons would be given by others who made the same move. But before making the move I had to weigh up the cost of switching. I've since had a look at Ruby, and though I'm prepared to concede that it may, perhaps, be a better language technically, it doesn't offer me enough perceived added value to warrant the cost of switching.
Why not use both Ruby and Python/whatever? Though there is truth in the maxim "Use the appropriate language for the task", it's also true that there are many benefits from having a body of work in the same language. Leaving aside the time and effort to learn Ruby, for me to do a project in Ruby would mean ending up with some code that I probably couldn't use from my other projects. That's why I've characterised it as a switch.
I will have to agree it is the best python book. Though an update for 2.1 would be nice.
--
A while back I was required to do an extensive research paper and a presentation on a particular programming language. The language I was assigned was Ruby...mostly because my professor at the time had heard it mentioned once and really knew nothing about it. I will regret that encounter until the day I die. When I researched it (and I'll admit that this WAS a longish time ago) there were NO books published in english on the subject and all I had to go on was the tiny bit of documentation that came with the distrobution. Anyway, here's my point. I benchmarked Ruby against various other programming languages doing a very very simple loop in which an integer variable was incremented from 1 to 1 million. It was marked against Perl, Python, and (unfairly) C++. The results were rather interesting. C++ approx. 1.01 seconds Perl approx. 18.3 seconds Python approx. 21.2 seconds Ruby approx 47 seconds Does anyone other than me see the problem with that?
-----------------------------------------
Remove the Greed which plagues mankind.
That's like saying "why complicate things with another means of transportation when we already have horses, feet, dogsleds, etc. etc.?" Or "why complicate things with another means of communication when we already have smoke signals, morse code, etc. etc.?" You get the idea.
Existing mainstream languages are all hopelessly primitive when compared against a checklist of powerful capabilities well-known in academic circles, and found in languages such as the functionally-inspired languages like ML, Haskell, and Scheme. If you're using C, C++, or Java, you hit your head against walls daily, to the point where it becomes such second nature that you treat better methods with suspicion ("But it doesn't *hurt* to use this language - why should I switch?")
Programmers who are a little more discerning usually realize how limited the languages they use are, but the realistic alternatives are mostly more of the same. In fifty years time, today's languages will seem incredibly primitive.
Unfortunately, Ruby doesn't really advance the state of the mainstream-language art significantly, although it does have a nice collection of features so can be argued to be an incremental advance. The incentive to switch languages needs to be more than incremental, so Ruby probably isn't going to take over the world anytime soon. However, that doesn't mean development of new languages should stop. The incremental improvement of languages is an incredibly slow process: Java only recently introduced to the mainstream features which were introduced by Smalltalk around 1970 - and Java still doesn't even come close to doing everything that Smalltalk can!
It took me one day to learn ruby, using the online version of the excellent book Programming Ruby.
The next day I wrote a program to log in to a website, extract some information and email it to me. While that might not seem like a great achievement, it was the first time I had ever used hashes, iterators (which is definitely a cool feature of ruby), exceptions, http or cookies.
I was able to do this because ruby makes it so easy. Things tend to work the way you expect them to.
I would expect that if you have already used Perl or Python, you will find ruby even easier to learn.
Some other posters have mentioned the lack of "community support". I find the people on comp.lang.ruby to be extraordinarily helpful, with the creator of ruby (Matz) and one of the authors of Programming Ruby (Dave) often helping people with their problems.
Or 'who needs Linux when we have UNIX®', 'who needs Netscape when we have Mosaic', etc.
Don't write Ruby off until you play with it. And, having played with it, I've written it off. I was looking for something on the client side that was more powerful than JavaScript but not as hefty as Java. Perl moved across the wire would be beautiful and that was the goal of the Penguin module. Alas, it seems to have withered on the vine.
Be a little more open. It'll keep you young.
http://www.ruby-lang.org/en/compar.html claims to compare Ruby to other languages, and such it does. Unfortunately it's full of half-truths and downrigth lies about other languages, that doesn't make me feel warm and fuzzy. A few examples follows from the Python section:
Python types are more limited (no inheritance/subclassing; cannot add methods to existing types). What are they smoking ? No inheritance in Python ? Python has had inheritance since day one as far as I know. Cannot add methods to existing types. Not ? How about:
class chair:
"Class with no methods"
pass
def siton(obj):
print "You sit on the chair"
chair.siton = siton
Just an example, I don't know Perl or tcl well enough to comment, but when I find mistakes in simple factual claims I get a whole lot more skeptical of other claims that I am myself unable to verify.
Use the right tool for the job. If your domain does not fit an object oriented paradigm, then by all means don't use it! Procedural languages are algorithm-centric while OO languages are data-centric. So pick your language based on your problem.
When you domain model is appropriate for OOP, then by all means use an OO language. Sure, you can do it in C. But you could also do it in assembler. If you're going to use OO, then use a language that supports and facilitates OO.
A Government Is a Body of People, Usually Notably Ungoverned
What annoys me, and always has, is that people associate namespaces with OO. It makes no sense. Namespaces are a scope construct, and would be increadibly useful in procedural languages, if people would just add them.
What annoys me more, is 'OO' languages which tie namespaces to modules or objects, instead of the other way 'round.
-- Crutcher --
#include <disclaimer.h>
-- Crutcher --
#include <disclaimer.h>
Such orthogonality has aesthetic merit, but is bad for performance. There are a lot of things one can do to reduce the cost, but there is a cost.
Variable punctuation is evil regardless of whether it determines scope or type. Sure, some people like putting an MFC-ish "m_" before member names etc., and they should be free to do so, but they shouldn't be forced to do so by the language.
Again the performance issue rears its ugly head, and also the issue of assignments etc. having side effects. Sure, it can be "cool" to overload access/modification, e.g. to enforce range/consistency limits or to create "magic" variables such as r/theta when what you're really storing is x/y. However, the cost and potential for abuse aren't worth it. You can already get almost the same effect with explicit accessor functions, or with a keyword attached to declarations. People who really like being able to go in after the fact and change the semantics of an assignment in one of their classes can just always use the keyword; people who want to be able to do the same for other people's classes generally have no business doing so lest they cause all sorts of "spooky" failures when they violate the class implementation's internal dependencies.
BTW, I'm not really that hung up on performance, in the usual sense. If your application doesn't run fast enough in an interpreted (including byte-code interpreted) language, you should profile, refactor, and rewrite necessary portions in native code. However, I am concerned with performance in the sense that I hate to see billions upon billions of cycles wasted for little or no functional benefit. Machine cycles are cheap, but programmer cycles aren't. If a language runs 10% faster then that might be enough for some large number of applications, so instead of all that refactoring and rewriting I just mentioned the programmers can spend more time on adding features or making the program more robust.
Slashdot - News for Herds. Stuff that Splatters.
Try checking out the __add__, __radd__, __mul__, __rmul__, __div__, __rdiv__, etc. methods in Python. If you want to override the "*" operator for a class, all you have to do is write your own __mul__ (and, optionally, __rmul__) method and presto, operator overloading.
If you're going to bash a language, you really should make it a point to at least learn the language first.
Python 2.1 is free software; it is simply not GPL-compatible free software, due to the clause which specifies Virginia as the state of jurisdiction. Python 2.1 meets every single freedom listed in the Debian Free Software Guidelines.
Please don't spout FUD regarding Python's license. Instead, call a spade a spade and say, "Python is free software, but is not GPL-compatible. In this sense, it's no worse than the Mozilla Public License."
It could be said, as well,
Currently I'm using, and loving, Perl. It has a very active and helpful community, plus tons of modules that come with the system. While I do like Python, it doesn't have the support behind it that Perl does. Thats why I use Perl, and not Python.
Java seems to have the mark of the corporate beast on it: while it has its benefits and benefactors, it hasn't kept steam like Perl has. Personally, I'm liking the looks of JDK 1.4, with select(), assert(), faster Swing, and mostly-Perl-friendly regex classes built in.
[
If Ruby has some features that I need and no scripting language I already know fits the bill, I might make an effort to learn it, but I'm not going to go out of my way to pick up Yet Another Scripting Language.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I've seen Ruby used for AI/machine-learning code as well as some math applications. It turns out that one may extend the language using other code, such as C. Add in the untyped OO as others have discussed and you can easily write programs for multiple platforms/languages without giving up speed (write speed-critical code in a C extension).
Doctor Dobb's Journal
For more Ruby info, check out their homepage
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Higher Logics: where programming meets science.
Well, I'll bite.
... In scripts??
I say Object Oriented Programming is highly overrated.
Many programmers I know seem to believe there are about 2 ways to program in the world: procedural (uncivilized, messy spaghetti code, no support for large programs, etc.) and object oriented (civilized). The fact is that all modern languages spanning many different paradigms support civilized programming, even if they are not "object oriented". And what I infer from this is that objects are primarily useful only when the data you are processing are neatly expressed as objects, that is, they actually *are* objects. (For instance, if they describe operations, then higher order functions are much handier.)
Every civilized language that I know of supports the features that I believe most people think of as object-oriented. Even languages which are adamantly *not* Object Oriented (such as SML, of which I am a stalwart fan) support them.
Some examples are aggregate data (in the case of SML, aggregate data is supported much more cleanly than OO languages I know of, since one can make anonymous "classes"), abstract data types, exceptions, threads, polymorphism, garbage collection, and type safety. (The advanced languages I'm implicitly referring to also support some really nice features typically not in OO languages, such as higher-order functions, static typing, parameterized modules, and generics or "parametric polymorphism".)
So what really separates Objects from regular old modern programming? I say two things: inheritance and subtyping. Essentially, if you are not making use of subtyping (using it for polymorphism doesn't count, since other modern languages support polymorphism in their own way) in your program, then you aren't using any OO-exclusive features. Do you actually write programs the way that they introduce OO in textbooks? (A motorcycle derives from wheeled_vehicle, which derives from vehicle?)
So I guess what I'm saying is, be sure you know what you mean when you say "OOP", since there is very little which is particularly special about OO languages. In my opinion, there is not much need in scripting language for subtyping. So I say that emulating Java or C++ is not a very worthwile goal, except inasmuch as it might engender comfortable syntax/semantics for those who have only used those kinds of languages. Let's look to some other advanced languages to get us useful features in our scripting languages, and encourage the use of them.
Why not Haskell?
Why not Mozart-Oz?
Why not Prolog?
Why not Pict?
Why not Programming Language X?
The truth is, most people do not choose a programming language based on the technical merits of the language, but instead, most people choose a programming language based on a mix of the following list of reasons:
Hey, its the reason most have for why they use their natural language. I use English because it is the first language I learned, but English is not necessarily the best natural language.
For example, most people simply aren't educated in computer science, and therefore don't understand Object-Orientation, functional programming, declarative programming, etc, and therefore, these people are turned off my languages that they simply cannot understand. Why do you think that Visual Basic is so popular?
Never under estimate the horrible effects of legacy. It comes in many forms, from having large amounts of code written in previous languages, to only having experience with writing code in previous languages. If you have legacy code, then moving to another language requires allot of work to migrate the code or you could end up complicating things by keeping the old code base and introducing the new latest and greatest programming language. And the other form of legacy, mindshare legacy, is even worse. A programmer should constantly be on the hunt for tools that will make him/her more productive, but the fact is that most people are lazy and really only know how to efficiently code in one programming language... even when something better comes out, people that have already become efficient in their one favorite programming language are very reluctant to change. Why do you think that C++ is so popular?
Its obvious that hype and its flip-side, FUD, heavily influence the average person's choice in programming languages. Over the past 5 years, the ultimate way to sell a programming language was to fill the description of the language with all sorts of "Object-Oriented" buzz words. However, big dollar marketing campaigns have made at least two programming languages catch on: Java and Visual Basic. Meanwhile, FUD has been used to slam alternative programming languages into the background. Whoever thought that the words "procedural programming" would become programming language profanity?
There's so many scripting languages out there already, and it takes time to become proficient in each one. It is better to have a few that are widely used, and then some like Ruby that are nice but mostly used by code hackers who enjoy new and different things.
Too much diversity can be a bad thing, especially in open source where people have to be able to read the code to extend it.
Just my two cents.
Given the number of posts above to the effect of "What the heck is Ruby?" -- as well as the lack of any critical details in the post (such as comparisons between Ruby and the alternatives) -- one can't help but get the impression that the poster is merely looking for free advertising for his/her pet language.
Toronto-area transit rider? Rate your ride.
I don't know how many times I've heard a fellow techhead complain "Yeah, I went to work for these guys. But they have a proprietary system that they have to teach to people. It took weeks to understand." In this world, "proprietary" means "rarely used and I've barely seen it before". That's why you see ads in the paper for jobs requiring Perl and C++ and less requiring Ada programmers.
Give Ruby time, a strong open source (or not) base, and people using it to create prefabricated programs not requiring little reprogramming, and it will get the audience it deserves.
In my case, I came to Ruby from the Java world. A friend forwarded me an email announcing the release of the Programming Ruby book and so I decided to check out the language. Since I enjoy learning about new programming languages I wasn't agaist learning "yet another language." A search on Google yielded the main Ruby-lang web-site, and after some reading I decided it was worthwhile to take the time to really learn it. That was about 4 months ago.
Since then, I've read through the on-line version of Programming Ruby as well as the printed version, which I recommend very highly. It is one of the best computer language books I have ever read (and I have a Computer Engineering degree.) I have also gotten very good at programming Ruby after only a month and half of serious study. In fact, I'm probably as good (or better) at programming Ruby as I am in Java (which I've been using for 3 years.) Now that is impressive. Of course I will admit I've been somewhat obsessive with Ruby and have studied it very extensively over this last month and a half, so your mileage may vary. But still: 3 years versus 1.5 months? Hmmm....
Of course I can't say the same wouldn't happen if I seriously studied Perl or Python, but I will say I don't intend to learn those languages now. They are fine and dandy for what they do, but just like all those out there who don't want to switch to Ruby since they know Perl (or Python), I don't want to switch to them because I know Ruby. So given that, I can probably respect those who decide not to learn Ruby for this reason.
But I have heard other Ruby users who have used Perl or Python say it is an improvement to them in some ways, so it may actually be worthwhile to at least take an hour or so to give Ruby a good look. I would say the same for Java programmers. If you've never touched a so called "scripting language", learning Ruby will change how you think about programming permanently. I'm sure former Java users now using Perl or Python could say the same thing. Of course Ruby is much more than a scripting language. In fact, I really wish I could just totally stop programming Java and just use Ruby (since it can solve the same problems), but I really don't think that is possible now since Ruby is so new (to the United States.) And of course Java is pretty much the corporate mantra these days.
But in the long run I could certainly forsee Ruby replacing Java in the enterprise. In fact, I think this should in some way unite Perl, Python and Ruby users, since we have a "common enemy" in Java, heh. Of course Java has it's uses too I suppose. And before Java advocates flame me, consider that I hold this view after 3 years of being a Java advocate and switching to Ruby for about 1.5 months (as noted above.) That's how much better I think Ruby is compared to Java.
Now other complaints about Ruby usually revolve around it's newness:
- It's doesn't have a big library like Perl's CPAN.
- No one uses it.
- I can't get paid to use it.
- I don't know it and won't learn it.
Now the first argument is valid (in fact I'm working on my take on the solution), though of course like the others it is kind of a self-fullfilling prophecy. If people had used these arguments and logic with Linux, this web site wouldn't be here right now, and the world would be a much different (and probably worse) place. So given this, at least give Ruby a chance before you just bash it because it is new and you perceive it as a "threat" to your own personal favorite programming language (why are languages so much like religions to programmers?)So, to conclude, at least give Ruby a chance and try not to be so fanatical about programming languages :)
--
Ryan
Because every language you learn affects how you program. Lets get meta here for a second. Think about how you think. I can only think in English, C, or Perl. This limits the number of things I can think about. As you learn new languages your capacity for think of new things increases and your understanding of the things you already knew deepens. I didn't really understand English until I started learning Latin (not that I remember much of it today). I could speak and write English, but I didn't really understand why I formed sentences in the way I do. Similarly, when I learned x86 assembler I suddenly understood why some things in C work the way they do. In the end all languages are worth learning (except Visual Basic).
"I don't need it." seems to be the consensus answer to the "Why not Ruby?" question.
If people don't need it, it doesn't stand a chance. The helpfulness of Ruby is outweighed by the cost of learning it.
The cost is greater than the benefit, just like [insert your other underused neato technology here]. Come back when the benefits are greater than the costs; preferably when they're MUCH, MUCH greater.
If you are writing simple scripts, by all means, OO is a disaster. If you are building a large scale system with components, OO helps you get there. It all depends on what you are doing.
If you are doing sysadmining, you may or may not want OO. Perhaps you have some conceptual objects, perhaps you don't. For the most part, I'd suggest that you don't.
I found for web applications, the database handles so much of your processing, that many of your public display components are simple are simple procedural displays.
However, if you are building an infrastructure, real OO style approachs can help you build up your concepts. I've found that we can often take advantage of OO design, even if not implementation.
We try to do, as you call it, text-book OO. It helps as the project scales. We have tremendous code-reuse for our client projects. This lets us stay in business despite being smaller than our competitors, because we can reuse so much of our code base. It also lets us undercut the big-boys, because we've maximized code reuse, not just taken what we've got.
Alex
I really like coding in object oriented languages. Right now I'm working on quite a major project in Python, and objectising everything is making it a lot more convenient. I'm using inheritance and polymorphism and so on, but it took me a while to figure out how that was useful in a scripting language where there isn't any strong typing.
I don't have anything against procedural languages, although I tend to write in objects more when they're available just because I'm more used to the technique. In general though, I think one of the most useful things that I get out of using objects besides all the polymorphism stuff is namespaces.
Classes are simply a really convenient way to package related things together without getting them messed up. I know this can be done without too much trouble without objects using packages or naming conventions, but classes are a much more general way to do it. Certainly it's one of the main reasons I prefer C++ over C, even for relatively simple programs, because C doen't have any natural way of assigning namespaces in a clean way that's guaranteed not to clash.
===
Here's some references ...
DDJ's January Article on Ruby (Thomas and Hunt)
Ruby Presentation (Thomas and Hunt)
Programming in Ruby Book (Thomas and Hunt. Available from Addison Wesley, online version is under an open content license)
And some web pages ...
Ruby Home Page
Ruby Central
I think the simple answer is that most people are quite happy with the scripting languages they already use.
Many people enjoy Perl, many enjoy Python, some enjoy /bin/tcsh. The latter population should however, needless to say, be put into working camps. Many also enjoy other languages, but I see Ruby mostly as a contender with Python and Perl.
So why should people switch to Ruby? Because they can do everything in Ruby they can in their current choice? Not likely. They can by definition already do that already. Because Ruby has an extensive library of ready-made code? No, because it doesn't have one compared to Perl or Python. Becuse it's a nice language design? Thats not enough reason to learn a completely new language if the one you use does what you want.
I might be prejudiced here, but i basically believe that many who like Perl do so because it's a very free-form (write-only :-) language, suitable for quick hacks. And those who like Python do so because it is a "cleaner" language, suited to write easy-to-read code. Both camps also enjoy the fauna of ready-made objects/functions/classes/modules that lets you do things easily without reimplementing the wheel.
There are probably Perlies that think Perl is a bit too loose, and Pythonettes that think Python is a bit too strict, and these people can probably find a new friend in Ruby once it gets the library support Python and Perl has.
But for most people that are already into Perl or Python, I think that the potential gain of switching languages simply isn't even close to the effort. And most Python-lovers don't want a looser language, just like most Perl-lovers probably don't want a stricter one. They're quite happy with what they've got.
In order for a new language to be able to make it as a strong contender to Python and Perl, I think it would have to supply something that neither language has, but that all programmers want (I can't think of anything matching that criterium at the moment, if I could I would've implemented that super language already! :-) If the language was then inbetween Python and Perl, both sides would have an easier time switching.
But only being between Perl and Python, which is just about everything Ruby seems to be at this point, isn't a reason to switch. It's just an advantage to ease migration if you happen to have something unique. Until Ruby actually invents something that makes it that much more valuable, I think most people will stay with the language they already use.
I do however wish the Ruby developers the best of luck. It is indeed a quite nice language, one I could definately imagine myself switching to if it gave me a clear advantage.
1. Strings are not value objects. Ouch! So you constantly have to worry about aliasing when you're passing strings around. Java got this right. (Though both languages fail on this count when it comes to date/time objects...sigh.)
2. I18N support is poor. Again, Java did this right (or got it much better, anyway)and made Strings sequences of characters, not bytes. This forces you to worry about your character set at the place (input) where you're actually in a position to deal with it, and then you never have to worry about it elsewhere. Ruby has some things (such as the Integer#char method) that just make no sense from an I18N point of view. Return the character represented by the receiver's value? In what charset?
3. Float uses the native architecture's floaing point. So FP programs' behaviour may differ (in very interesting ways, if you work with numbers such as the infinities and NaN) from system to system.
4. It's only related to certain styles, of course, but the semicolon-free syntax is, for me, more annoying than the semicolons. For continuation lines, I often try to split at operators (+, =, etc.) and put the operator at the beginning of the continuation line. Since a statement can't start with an operator (aside from C/Java constructs like ++, which I don't use in those situations), this makes it very natural to see the continuations, but in Ruby I have to put backslashes at the ends of all the continuation lines, now, and worse yet, make sure I edit them in and out properly when reformatting.
5. The Time object includes time zone information. This is confusing. Most stuff (such as comparating two times) seems to operate on the UTC value of the time, regardless of the time zone. But does #hour return the UTC hour or the hour in that time zone? If the latter, we can have two time objects that compare equal but where a.hour != b.hour.
Time zones are complex things. UTC and GMT are not the same thing (as Ruby seems to claim). Time zones do not have standardised unique three-character abbreviations (which is what Ruby seems to use for them. The time zone support, besides being fundementally broken in this way, is also implemented poorly; there's no easy way even to figure out the offset of the time zone of a given Time object.
And all this even before we start to get into date processing. Ruby doesn't seem to acknowledge the existence of different calendars. (Yes, even today different calendars are in use in a fairly major way. Take a look at a Japanese driver's licence if you don't believe me.)
I'm sure I could find more. And there's a bunch of stuff in Ruby that I like, too. But just from this glance, the language seems to have enough annoyances of its own that I can't see any reason for it to take over from Perl, Python, Java, or whatever.
cjs
The world's most portable OS: http://www.netbsd.org.
Don't get me wrong, I use Perl too, but I'm using it less and less these days. I've been programming in Ruby since about the start of the year and these are the advantages I find:
1) RUby has much nicer OO syntax than Perl - advantage is that when you go back to read the code after a month you can tell what's going on.
2) Perl's alarm doesn't work on the windoze platforms (sometimes in the corporate environement they make you use windoze), Ruby's timeout does.
3) Threads - With perl you actually have to compile a special threaded version. Ruby threads work - even on windoze.
4) Ruby has dRuby a distributed object system that is very easy to use (compared to SOAP, and other XML based approaches).
5) Hashes, arrays, strings have many more builtin functions (methods since they are objects) than Perl's Hashes, arrays and strings.
6) ease of writing extensions in C for Ruby(though Perl's Inline is supposed to make this a lot easier than it was in Perl)
And then there are lots of other things like about RUby like iterators, the ability to extend buit-in classes, built-in support for some design patterns.
Colonel Panic
Yes, it does.
A Few Things I like about Ruby, by Joshua Haberman
> 65.chr
"A"
> "hello".length
5
> [1, 2, 3].last.to_s
"3"
def initialize(foo, bar, baz)
@foo = foo
@bar = bar
@baz = baz
end
class Song
def durationInMinutes
@duration/60.0 # force floating point
end
def durationInMinutes=(value)
@duration = (value*60).to_i
end
end
And now you can read to or write from someSong.durationInMinutes as if it were a simple attribute when in truth they're methods!
I'm not a Ruby expert, and I'm sure that some of these features can be found in other languages: my point is that people shouldn't just assume that Ruby is another Perl or Python, because it offers several advantages that differentiate it from Perl or Python. (and these are just a start: it features iterators, blocks-as-arguments, threads, and more)
However I completely agree that not having something like CPAN is a serious disadvantage in comparison to perl.
--
Here are the reasons I'm not, and haven't ever chosen to use Ruby:
First, I don't like the syntax[*]. Python has a beautiful, simple, typing-economic syntax that no language I've seen can compare to. Ruby doesn't -- it uses "end" to denote the end of blocks, it has several prefixes (@ and $) for varaibles to change the interpretation of those variables, and it has a strange (to me) syntax for iterating through data structures.
Second, I don't buy the speed argument. I've tested various trivial scripts and a few non-trivial ones in both Ruby and Python, and found them about equal -- Python is faster in some operations, Ruby is faster in others. In either case, neither is ever much faster or slower than the other. In the world of scripting languages, a 10% difference in speed makes very little difference -- if you need more speed for what you're doing, you likely need an order of magnitude increase, and thus, a compiled language. A 10% increase in speed isn't generally worth switching scripting languages, and except for some pathlogical cases (which exist in both cases!) you won't find Ruby or Python differing by more than 10% in their total execution time.
Thirdly, while many claim that Ruby is "more OO" than Python because even the basic types are classes which can be inherited from, it's not that simple. First, Python provides UserList, UserDict, and UserString modules for those that do need to subclass a basic type (believe me, it doesn't happen often :)). Also, functions in Python are first class objects, whereas functions in Ruby aren't. You can argue about which language is "more OO" all day long, but there are points for each side, and at the end of the day, whichever helps you do more work, no matter how OO it is, is the superior one.
Python OO is, by the way, far more reflective than Ruby OO -- you won't find anything in ruby that's as flexible as python's getattr/setattr functions and __getattr__/__setattr__/__dict__ attributes of objects. Esoteric stuff like the Meta-Object Protocol is thus far easier to implement in Python than in Ruby.
Python has a more active user community in the US and Europe (though I hear Ruby has a more active community in Japan.) The standard library in Python is to die for, and much more extensive than that included with Ruby.
Features that don't affect me as much, but still played a part in my decision not to use Ruby: It's less portable than Python and the C interface is (in my opinion) not as cleanly implemented. Python has several implementations available, whereas Ruby has only one.
In short, Ruby and Python both have their advantages and disadvantages. I prefer Python (and feel that compared to Ruby is comes out way ahead,) but even if Ruby ended up slightly ahead after an objective evaluation, it would be hard to justify learning an entirely new language for the barely incremental increase in productivity.
Jeremy
[*]: Yes, those of you who know/have looked at O'Caml have seen its syntax, and probably noted that it's far worse than Ruby's. I can agree, however, O'Caml has numerous features to compensate: static typing, tail recursion optimization, blazingly fast native code compilers, support for several programming paradigms...the list continues. O'Caml has an ugly syntax, but in most cases (and definitely in O'Caml's case) syntax is a one-time cost, and O'Caml pays back that cost nicely.
PS.: If I'm wrong on any of the above points, please correct me -- that's what I've learned from a cursory examination of the language, I don't claim to know it in-depth.
--
Looking for a Python IRC bot?
Currently I'm using, and loving, Python. It has a very active and helpful community, plus tons of modules that come with the system. While I do like Ruby, it doesn't have the support behind it that Python does. Thats why I use Python, and not Ruby.
Last night I shot an elephant in my pajamas. How he got in my pajamas I'll never know.
Politics.
If I were a boss I would be nervous to let a programer use a langauge like RUBY for a project. My fear would be that the employee would leave and no one would support the RUBY based app. I know this sounds stupid, untechincal and irrational in chosing a langauge but politics in the bussiness world is very important. I was reading a comment here a few days ago about slashdotter who needed a firewall solution. His boss chose an inferior solution over openBSD because the users and his boss was more familiar with the company name. Picking a political solution also looks good on my resume and to reports to directors and CIO's.
Second fear: what if the RUBY project turned out to be a diaster and nothing got done? MY boss and my boss's boss would like to know why in a detailed report. What would they think if they found out it was based on this so called experimental langauge called Ruby made by some hacker and not a corporation? I would not be employed for long if this ever occured.
Programming langauges are just as political as chosing a platform. I would encourage open source developers to increase the amount of projects based on ruby and if Ruby becomes more popular then it might be less risky for a Ruby based solution in the bussiness world.
I for one hate office politics but they are a fact of life and explains why MS is so popular.
http://saveie6.com/
The question to me isn't "Why not Ruby?" The question I would need answered is "Why Ruby?"
We've already got Perl and Python. Both scripting languages are quite powerful (way beyond what simple shell scripting can do). Both have strong communities behind them and are well supported. Both have a lot of programmers working on extentions and modules. And, importantly, both languages are open and free. Perl and Python are different enough in structure that they appeal to different people. Some like both, some like one or the other. I wouldn't want either language to go away; I don't want to see Perl "beat" Python or vice versa, since they are different enough in concept. There is a place for both of them.
But, given that we have Perl and Python as free scripting languages, and that both are powerful and supported, why do we need yet another? Mind you, I don't really know anything about Ruby; perhaps it provides something which Perl and/or Python simply can't. But unless it does, I simply don't see the point of having Ruby. If Perl or Python were controlled by a single entity (as is the case with C#, and even to some extent Java), I would see the point of having another language. But given that Perl and Python belong to anybody who want to have it belong to them, unless Ruby provides something they don't, there is simply no point to Ruby, so far as I can tell.
If you want a scripting language to do something, rather than writing a whole new one, I would say put your effort into writing a module for Perl and/or Python. The world will be better served by that. Again, all of this is unless there is something fundamental and useful about Ruby which Perl and/or Python simply can't do.
-Rob
- I already know a language, and it is perfect.
- I don't have time to learn something new.
- Someone once told me that a friend of theirs knew someone whose uncle said it was slow.
- It's new.
There are valid reasons not to deploy applications with Ruby. It doesn't (yet) have a library the size of CPAN. It doesn't (yet) own a stack full of books at your local bookstore. It doesn't (yet) have the performance of Java (although it is faster than Python in most benchmarks). That's why the people who currently use and love it tend to be more adventurous, and more forward looking. They believe that Ruby will be a significant language. In Japan, where there are a number of Ruby books, and where there is currently more Ruby support, the language has more users than Python.So, a couple of years from now, we'll probably see Slashdot readers saying "but I already know Ruby, why should I switch to xxxx?".
In the meantime, the book Programming Ruby is available online. Maybe it's worth a look. You can download Ruby from ruby-lang. Maybe it's worth a play. You never know...