Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Programming IT Technology

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.
This discussion has been archived. No new comments can be posted.

Why not Ruby?

Comments Filter:
  • by Anonymous Coward
    Yes, the Open Source Scripting Language Steering Committee should finally decide on an official scripting langugage for all of us.
  • I think a few responders are missing the original poster's point. Judging by the fact his email address is the fixed-point ('Y') combinator in lambda calculus notation, I assume he is a fan of functional languages. I think the point had nothing to do with things like namespaces and such. Those are implementation details that have nothing to do with the overall paradigm. You can have namespaces in a non-OO, OO, functional, logic programming or any other type of language.

    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.

    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 .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.



    --
  • Sounds like you perl junkies are looking for an excuse to ignore Python! -Paul Komarek
  • I'm curious: Ruby I assume is pretty close to Python in speed, no? I was under the impression they were both interpreted (byte-compiled or whatever).

    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?

  • Yeah, I think that Python and Perl are well differentiated. They both express very different philosophies. I might even say they both express different, exclusive, but valid opinions on how to program. I might say that if I believed it, but I can't say I think Perl is a good way to program, even for other people.

    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.
  • I know this sounds stupid, untechincal and irrational in chosing a langauge but politics in the bussiness world is very important

    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.

  • the real question is why people keep reinventing the wheel.

    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).

    ...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.

    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;

  • by Howie ( 4244 )
    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
  • 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:

    • j = 0

    • 1..1000000.each do |i|
      j = j + 1
      end

    You may want to rewrite as:

    • j = 0

    • for i in 1..1000000 do
      j = j + 1
      end

    or even:

    • j = 0

    • 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:

    1) In Ruby, strings and Numbers both use &lt and &gt 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 &lt, &gt, 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 .to_i, etc., but it is too easy to forget to use them when needed.

    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 /. discussion.

    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.
  • > 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.
    --
  • > What I think is missing is a good scripting language implementation that takes full advantage of C++.

    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++ :)
    --
  • 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.
  • 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/ [w3.org] 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.

  • That's right.

    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.
  • 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....
  • 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.
  • 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.
  • 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.
  • The "scripting language niche" is quite already filled by Perl and Python.. IMHO Ruby is more readable than Perl (not difficult!) but it competes head to head against Python, and there are many more Python users than Ruby users..

    I would say that the odds are against Ruby, we'll see..

    Well, I guess there are three comments to make here.

    1. I think the notion of a scripting language niche as such has really lost all meaning. Given the fact that 10K+ line programs exist in pretty much any "scripting" language that got anywhere at all, I'm really not convinced that there is any interesting distinction to be made here anymore.
    2. When plotting world domination, your current market share is certainly important, but really no more so than your growth rate relative to the overall rate of growth in the dominion. The number of Ruby adherants today is tiny, but the growth rate is pretty stunning. Of course, if the latter levels off in the next year or two, there won't be much to say. I would like to point out, however, that Python hung out for a surprisingly long time in what might be called its "single digits with no obvious influence on the race" stage. Now, *why* that was is another question entirely...
    3. People on slashdot never seem to understand what competition is. Ruby is really not that much like Python, or really that much like Perl, although it has obviously borrowed ideas from both. As the saying goes, "Competition does not exist of being different from other, but, rather, from being the same". Now, I've been looking at Ruby for only a couple of weeks, and I have to say that it is very different from other so-called scripting languages. The real key differences that Ruby brings to the table isn't "real object orientation" or any such stuff, but its use os abstract iterators, the well-supported notion of mix-in classes and an aim towards the terseness of Perl but with a systematic reduction in the amount of "huh?" surprise at the effects of your code.

    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

  • 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.

  • That's not politics, it's risk management, and it's the sort of boring but essential thinking that's crucial to building a long-term business. No apologies or excuses are necessary.

    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.

  • by Wazm ( 33360 )
    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.
  • making run-time efficiency a significant language evaluation criteria is a mistake. What's critical is programming-time efficiency

    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.

    The commentary regarding variable punctuation is in the same league as negative criticism of python's indentation scoping mechanism

    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.

  • Often you're asking a class for a piece of data, and the class has the option of recomputing the data each time the accessor is called (easy to code) or caching the result as an instance variable

    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.

    You say there is a potential for abuse of accessors... what is it?

    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.

  • For me, a good scripting language must have three features:

    1. Clean syntax and a sane underlying conceptual model.
    2. Sufficient power to perform complex tasks within the language itself.
    3. A good extension interface so that you can write code in other languages and integrate it cleanly with the script language when necessary.

    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).

  • 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 [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.

    --

  • 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.
  • 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?

  • 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 [ddj.com].
  • It's not that I don't understand it. I do completely understand the idea of an iterator (with a name like that, who couldn't?) What I don't understand is where the syntax came from and why the syntax is necessary.

    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
    --

  • As for cleanliness of code. Python looks cleaner than Perl, but Python is still full of broken symmetries. "a.append(b)" but "del a[len(a)]"; pop but no push;

    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.

    And lets not get into the retarded block structure. (Oops, to late) semantically overloaded whitespace!

    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.

    A real reason Python's block structure sucks is that it makes arbitrarily nested lexical scopes difficult to implement, that in turn makes closures difficult to implement

    Please, explain how this is so. I'm curious.

    Ruby kicks Python butt in the cleanliness of design and programming department.

    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.

    Ruby is faster. Ruby is easier to write extesions for (though SWIG make this minor except for typemaps).

    I found the assertion, but again, I couldn't find the proof. Perhaps you can provide some.

    Python has one pretty cool thing: Stackless Python. Guido-Python-dev-whom-ever, integrate Stackless Python into the Core; make python truely unique and kickass!

    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
    --

  • 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...)
  • I have already seen this. Just substitute RUBY with LINUX, and language with operating system.

    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.

  • Ruby borrows features from Python and Perl and other languages I don't know (just like Perl and Python did).
    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 ...) They would have meant heavy architectural changes (Python FAQ section 6 lists a few design choices that 'could have been done differently, only it's too late now, and maybe it is better so'). And they would have been incompatible, breaking tthe existing code base and annoying the community.

    That is why a new language. And if a community forms around it, it means that maybe it was needed.

  • Hey, none of this wimpy language stuff...Real Programmers write Turing Machine state transition tables! :-)

    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.
    --
  • XHTML 1.1 incorporates Ruby.

    Someone please mod it back down. It's a different "ruby", not the scripting language discussed.

  • 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.

    Your example in Smalltalk:
    myList do: [ :object | object someMethod ].

    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: [ :object | object hash ].

    "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 := #(1 2 3 4 5 6 7 8 9 10). "array literal"
    anArray select: [ :num | num > 5].

    "returns a collection with uppercase characters"
    | anArray |
    anArray := #($a $b $C $d $O). "array of characters"
    anArray reject: [ :aChar | aChar isLowercase].

    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.
  • 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.
  • 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.
  • 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.
  • 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.

    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: [ :subTotal :next | subTotal + next].

    F-Script is pretty interesting, and looks like a promising alternative to Objective-C, C, and C++ for Mac developers.
  • 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. [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".
  • 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! [move.to] The site has info on free mobile languages (don't think they are all ultra-complex like Mozart-Oz).
  • Ok, I'll try to bite, although I'm not a heavy user of scripting languages.

    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.

  • Well, if you are constantly hassled by more codebase to use (more to learn, more bloat to be added), better development tools (that take more time to learn than the time you might save), more documentation (for new products that does exactly the same as the old products, except everything is different), how are you supposed to get the time to work? When are you going to sit down and simply hack?

    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.

  • You can't use Python like Perl even though it has a strong, Perl-compatible regular expression library. And you can't ues it like Smalltalk even though it has OO and can even support meta-OO types of programming. And it doesn't support functional programming even though it has map, filter, lambda and list comprehensions.

    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 (<>) {
    $between_markers = /foo/ .. /bar/;
    $text .= $_ if $between_markers;
    if ($between_markers =~ /E0/) {
    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.

  • I'm curious. Why don't you allow interpreted code? Does this really help security? I can't imagine it would help security in any way, but I might be wrong. Have you removed /bin/sh as well?
  • Overall, i have to agree. I do a lot of Perl. The language is good (which is arguable, i know), but the developer support is great.

    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.
  • 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
  • by Jules ( 2226 ) on Sunday July 08, 2001 @01:11PM (#100067) Homepage

    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.

  • 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.
  • by Crutcher ( 24607 ) on Sunday July 08, 2001 @02:49PM (#100070) Homepage
    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>
  • Everything is an object.

    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 determines scope, not type

    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.

    Reading or writing from a class attribute is always a method call.

    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.

  • by rjh ( 40933 ) <rjh@sixdemonbag.org> on Sunday July 08, 2001 @05:57PM (#100072)
    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.
  • by rjh ( 40933 ) <rjh@sixdemonbag.org> on Sunday July 08, 2001 @06:06PM (#100073)
    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."
  • by Speare ( 84249 ) on Sunday July 08, 2001 @12:38PM (#100074) Homepage Journal

    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.

  • by Greyfox ( 87712 ) on Sunday July 08, 2001 @12:22PM (#100075) Homepage Journal
    If I jumped on the bandwagon of every scripting language (Oe every language in general) that came along, I'd never have time to get anything else done. I'd also never get to be any good with with any one language. About the time you start getting comfortable with one, another comes along.

    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.

  • by SBChoDogg ( 93091 ) on Sunday July 08, 2001 @12:58PM (#100076)
    One place that Ruby has found popularity is in Japan. According to the authors of Programming Ruby the Japanese have found Ruby very useful because it handles multibyte character sets, a requirement for doing text processing with such a large character set. Not to say that other languages can't handle this too, but its an interesting feature that helps Ruby in the international sense.

    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).

  • by naasking ( 94116 ) <naasking AT gmail DOT com> on Sunday July 08, 2001 @01:14PM (#100077) Homepage
    Doctor Dobb's Journal [ddj.com]

    For more Ruby info, check out their homepage [ruby-lang.org]

    -----
    "Goose... Geese... Moose... MOOSE!?!?!"
  • by Tom7 ( 102298 ) on Sunday July 08, 2001 @12:40PM (#100078) Homepage Journal
    Well, I'll bite.

    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?) ... In scripts??

    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.
  • by Jagasian ( 129329 ) on Sunday July 08, 2001 @05:29PM (#100079)
    Moderators: If you don't agree with the text below, then refute it with a real arguement. Its about time that people admit the reasons why they picked the programming language they know best...

    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:

    • First Come/The Only One You Will Learn
      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.
    • Ignorance
      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?
    • Legacy
      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?
    • Hype
      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?
  • by QuantumFTL ( 197300 ) <justin,wick&gmail,com> on Sunday July 08, 2001 @12:18PM (#100080)
    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.
  • by s20451 ( 410424 ) on Sunday July 08, 2001 @01:04PM (#100081) Journal

    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.

  • by SilentChris ( 452960 ) on Sunday July 08, 2001 @01:55PM (#100082) Homepage
    One other reason why your boss and "boss's boss" may get upset is that after you leave, how many programmers who know Ruby will be able to come in and step-up in your place?

    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.

  • by MrCode ( 466053 ) on Sunday July 08, 2001 @02:58PM (#100083)

    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

  • by cowens ( 30752 ) on Sunday July 08, 2001 @12:50PM (#100084)
    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).
  • by Kohath ( 38547 ) on Sunday July 08, 2001 @02:24PM (#100085)
    "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.
  • by alexhmit01 ( 104757 ) on Sunday July 08, 2001 @01:21PM (#100086)
    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
  • by jesterzog ( 189797 ) on Sunday July 08, 2001 @01:35PM (#100087) Homepage Journal

    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.


    ===
  • by Anonymous Coward on Sunday July 08, 2001 @01:11PM (#100088)
    Ruby is fairly new to the English speaking community, but there are some good resources for it. Dave Thomas and Andy Hunt (authors of the "Programatic Programmer") have been doing a great job of promotting it and getting the information out to all of us non-Japanese speaking programmers.

    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]

  • by viktor ( 11866 ) on Sunday July 08, 2001 @01:20PM (#100089) Homepage

    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.

  • by cjs ( 12969 ) <cjs@cynic.net> on Sunday July 08, 2001 @07:26PM (#100090) Homepage
    Well, after a quick look at Ruby, here are some examples for annoyances:

    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

  • by Colonel Panic ( 15235 ) on Sunday July 08, 2001 @02:22PM (#100091)
    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
  • by CoughDropAddict ( 40792 ) on Sunday July 08, 2001 @05:57PM (#100092) Homepage
    I don't really know anything about Ruby; perhaps it provides something which Perl and/or Python simply can't.

    Yes, it does.

    A Few Things I like about Ruby, by Joshua Haberman

    1. Everything is an object. Seriously. Even if you're not an all-out OO hippie, it gives great consistency:

      > 65.chr
      "A"
      > "hello".length
      5
      > [1, 2, 3].last.to_s
      "3"
    2. variable punctuation determines scope, not type-- '@' is an instance variable, '@@' is a class variable, '$' is a global variable, and no prefix is local. This makes so much more sense than perl's confusing semantics ($foo[0] is part of @foo, but not $foo). It also lifts the ugliness of self.this and self.that. A constructor might look like this:

      def initialize(foo, bar, baz)
      @foo = foo
      @bar = bar
      @baz = baz
      end

    3. Reading or writing from a class attribute is always a method call. I absolutely love this! It means you get the syntactic clarity of foo.bar = baz (no foo.getBar or foo.setBar), but the safety of hiding it behind a procedure. For example (this one is from The Ruby Book, in the chapter on classes [rubycentral.com]):

      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.

    --
  • by jemfinch ( 94833 ) on Sunday July 08, 2001 @01:35PM (#100093) Homepage
    I've been through my rounds with programming languages -- I started with C, then loved Perl, then moved onto Python and learned what readable code was, and now I'm currently enamoured with O'Caml.

    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.
    --

  • by Cheshire Cat ( 105171 ) on Sunday July 08, 2001 @12:20PM (#100094) Homepage
    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.
  • by Billly Gates ( 198444 ) on Sunday July 08, 2001 @12:42PM (#100095) Journal
    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.

  • by rknop ( 240417 ) on Sunday July 08, 2001 @01:13PM (#100096) Homepage

    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

  • by PragDave ( 466044 ) on Sunday July 08, 2001 @01:23PM (#100097)
    • 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...

A modem is a baudy house.

Working...