Why not Ruby? 316
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.
Re:Too many already (Score:2)
Re:Namespaces (Score:2)
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.
I love Ruby... (Score:2)
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
--
Re:Perl (Score:2)
Re:Ruby (Score:2)
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?
Re:Python (Score:2)
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?)
Re:Object Oriented programming is overrated (Score:2)
Re:Answer is simple (Score:2)
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.
Re:scripting languages are a dime a dozen (Score:2)
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;
Re:Perl (Score:2)
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
Re:Ruby: A comparison (Score:2)
Check out this link [bagley.org] 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
Re:My take on Ruby (Score:2)
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.
Re:The better question is ... (Score:2)
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.
My take on Ruby (Score:2)
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.
Re:Less tran truthful advertising... (Score:2)
Re:The better question is ... (Score:2)
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.
Apache support (Score:2)
Re:Deja Vue ? (Score:2)
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.
--
Re:scripting languages are a dime a dozen (Score:2)
Take a look at ColdStore [sourceforge.net] 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++
--
Why not? Easy! (Score:2)
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.
Re:XHTML + Ruby (Score:2)
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/ [w3.org] for more details.
S.
Re:Perl (Score:2)
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?
Re:Why not not switch? (Score:2)
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.
Re:Too many already (Score:2)
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.
Re:Some Annoying Features of Ruby (Score:2)
Re:Some Annoying Features of Ruby (Score:2)
Re:Excellent language, some drawbacks. (Score:2)
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.
Sometimes I use Ruby (Score:2)
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.
Re:Python 2.1 is free software (Score:2)
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.
Fear of Change (Score:2)
Re:Object Oriented programming is overrated (Score:2)
"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.
Re:Very few language succeed.. (Score:2)
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
Why we switch? (Score:2)
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.
Re:Answer is simple (Score:2)
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 (Score:2)
Re:Prioritizing efficiency (Score:2)
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.
Re:Because Ruby Rocks! :-) (Score:2)
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.
Extension Interfaces (Score:2)
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).
Re:Consensus Answer: I don't need it (Score:2)
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.)
UTC vs GMT (slightly off-topic) (Score:2)
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
Re:This has been mentioned before, but... (Score:2)
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).
Give it time (Score:2)
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 [tuxedo.org] has been as much of a pleasent surprise to me as Perl [perl.com] 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 [python.org] is, in the long run. Rather than forcing you to do it Guido [tuxedo.org]'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 [pragmaticprogrammer.com] wrote a book [rubycentral.com] 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 [cpan.org]-like code archive for Ruby, there's a somewhat embrionic one here [ruby-lang.org]. There is discussion [rubygarden.org] currently going on at the RubyWiki [rubygarden.org] on how to implement a CPAN-like system for Ruby only avoiding the problems that CPAN has.
--
Re:1995: Who needs Java when we have C? (Score:2)
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.
We must keep our standards (Score:2)
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?
Ruby is still too new (Score:2)
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.
Re:Popularity of Ruby in Japan (Score:2)
Re:I can tell you why *I* am not using Ruby. (Score:2)
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 [nec.com]. 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
--
Re:IMHO: Perl-Python-Ruby (Score:2)
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
--
Re:This has been mentioned before, but... (Score:2)
Re:I can tell you why *I* am not using Ruby. (Score:2)
Deja Vue ? (Score:2)
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.
Re:The real question: Why Ruby? (Score:2)
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.
Re:The better question is ... (Score:2)
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.
Answer (Score:2)
That's the draw of perl for rapid application development using reusable (well-tested) code. It's awesome.
--
Re:XHTML + Ruby (Score:2)
XHTML 1.1 incorporates Ruby.
Someone please mod it back down. It's a different "ruby", not the scripting language discussed.
Re:I can tell you why *I* am not using Ruby. (Score:2)
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.
Re:I can tell you why *I* am not using Ruby. (Score:2)
Re:Object Oriented programming is overrated (Score:2)
Re:I can tell you why *I* am not using Ruby. (Score:2)
Re:I can tell you why *I* am not using Ruby. (Score:2)
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.
Re:The Truth Ain't Purdy (Score:2)
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. [cs.kun.nl] 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".
Re:The Truth Ain't Purdy (Score:2)
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.
Re:The Truth Ain't Purdy (Score:2)
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! [move.to] The site has info on free mobile languages (don't think they are all ultra-complex like Mozart-Oz).
Why doesn't more people use Ruby? (Score:2)
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.
Bandwagon... (Score:2)
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.
Re:Give it time (Score:2)
Actually, I couldn't have said it better myself. That is exactly why I don't use Python much. The regexps might be good, but can you do
while (<>) { /foo/ .. /bar/; .= $_ if $between_markers; /E0/) {
$between_markers =
$text
if ($between_markers =~
dosomethingwith $text;
$text = "";
}
}
easily? It might have map and filter, but does that make it a functional language? It certainly doesn't feel like one, and I for one feel that e.g. C++ with STL comes much more close to being a functional language than Python ever will. Likewise, it might support OO, but is it SmallTalk? Even java come closer if you ask me. Not that there is anything inherently wrong with any of those examples of Python features, but I find it easier to use more languages if each of them can do one thing well.
Re:I love Ruby... (Score:2)
Re:Ruby is still too new (Score:2)
I was checking out ruby a bit a few months ago, and my main concern was the lack of a standard database library. There were some database interfaces, but no standard way. I think some developers were working on this, but they have a long way to go before they are at the level of Perl's DBI.
Even is this was available, then we'd have to talk about template modules, Apache integration, etc.
I think Ruby has a future, but it's not a no-brainer choice.
Congratulations, you have been. . . (Score:2)
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
1995: Who needs Java when we have C? (Score:3)
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 [cpan.org] module. Alas, it seems to have withered on the vine.
Be a little more open. It'll keep you young.
Less tran truthful advertising... (Score:3)
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.
Re:Object Oriented programming is overrated (Score:3)
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.
Re:Namespaces (Score:3)
What annoys me more, is 'OO' languages which tie namespaces to modules or objects, instead of the other way 'round.
-- Crutcher --
#include <disclaimer.h>
Re:Because Ruby Rocks! :-) (Score:3)
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.
What, and Python doesn't? (Score:3)
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 (Score:3)
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."
Re:Perl (Score:3)
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.
Another Scripting Language, Ho Hum (Score:3)
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.
Popularity of Ruby in Japan (Score:3)
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).
Re:Python (Score:3)
For more Ruby info, check out their homepage [ruby-lang.org]
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Object Oriented programming is overrated (Score:3)
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.
The Truth Ain't Purdy (Score:3)
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?
Too many already (Score:3)
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.
Somebody's looking for free advertising (Score:3)
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.
Re:Answer is simple (Score:3)
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.
From Java to Ruby (Score:3)
In my case, I came to Ruby from the Java world. A friend forwarded me an email announcing the release of the Programming Ruby [rubycentral.com] 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 [ruby-lang.org] 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
Re:This has been mentioned before, but... (Score:4)
Consensus Answer: I don't need it (Score:4)
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.
We use OO-style in scripts all the time (Score:4)
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
Namespaces (Score:4)
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.
===
Ruby Resources (Score:5)
Here's some references ...
DDJ's January Article on Ruby [ddj.com] (Thomas and Hunt)
Ruby Presentation [pragmaticprogrammer.com] (Thomas and Hunt)
Programming in Ruby Book [rubycentral.com] (Thomas and Hunt. Available from Addison Wesley, online version is under an open content license)
And some web pages ...
Ruby Home Page [ruby-lang.org]
Ruby Central [rubycentral.com]
Why not not switch? (Score:5)
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.
Some Annoying Features of Ruby (Score:5)
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
Advantages over Perl (Score:5)
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
Because Ruby Rocks! :-) (Score:5)
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.
--
I can tell you why *I* am not using Ruby. (Score:5)
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.
--
Python (Score:5)
Answer is simple (Score:5)
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.
The real question: Why Ruby? (Score:5)
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
because.. (Score:5)
- 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 [rubycentral.com]. Maybe it's worth a look. You can download Ruby from ruby-lang [ruby-lang.org]. Maybe it's worth a play. You never know...