Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Programming in the Ruby Language 345

Posted by michael from the no-semicolons dept.
ShoeHorn writes: "Here is a good article (1st of a 4 part series), that introduces you to the Ruby language. If you are currently a programmer coming from the likes of C++, Perl, or Python, you will see some strong similarities (especially to Python)."
This discussion has been archived. No new comments can be posted.

Programming in the Ruby Language More

Programming in the Ruby Language

Comments Filter:

  • I'm just guessing, but I think I have learned at least 15 programming languages. Maybe it is 30, if you count assembly languages. At some point, learning languages must come to an end. At some point, I would like to see all the good features put into one or two languages. I have no intention of using my life learning languages that then die very quickly, like Pascal.

    It seems that, at some point, every skilled programmer becomes interested in writing either an editor or a computer language. I wrote one myself, for use with some H-P data acquisition equipment. Now both the equipment and language are obsolete.

    With every new language, there are years of extending the language, finding and curing the bugs, and wrestling with incompatibility problems. At some point, this must stop.

    Language writers should put their creativity into extending C++ rather than abandoning it.

    Consider Java, for example. There have been literally years of hassle and discussion about Java, when it could have been implemented merely as a compiler switch to a C++ compiler. The compiler switch could have provided automatic garbage collection, given error messages for use of pointers, and provided the other features of Java.

    Microsoft, following its usual abusive practices, put many ease-of-use features into Visual Basic, while keeping them out of Visual C++. The result was that there are maybe 1,500,000 programmers who know Visual Basic, but don't know a real language. And what language is Visual Basic itself programmed in? C++, of course.

    When you write in Visual Basic, you are just a dog on a leash. Anytime Microsoft wants to yank your chain, it can. If Bill Gates happens to lose interest, Microsoft can kill this one-OS language, the way it killed xBase (dBase, FoxPro), for example, by making quirky additions that no other vendor could/would follow, and then abandoning development.

    It is a shortcoming of the U.S. culture that so many men feel that they must play King on the Mountain, and try to knock everyone else down, rather than cooperate.

    Like everyone, Bill Gates has inner conflict. But don't let his anger and obsessive desire to make money reduce the quality of your life!

    So now it is Ruby, supposedly the next big thing. How long will it be until the books are all written? How long until we discover the shortcomings? Is there some feature in Ruby that can't possibly be added to another language?

    I reviewed Ruby a little about a year ago, but came to the conclusion that the documentation was extremely poor. The overall value of a language is the value of the language itself, plus the quality of documentation of the language.

    At some point, I want the merry-go-round to stop, so that I can get off.

    Is there something in C# that simply could not be made a compiler switch to C++? Do we really need more syntax? I'm not saying I know all the answers to some of these issues. But I sense that something bad is happening.

    For a few years, languages were interesting to me. But now, I just want to do the job, not discover other ways to do the job. Let's move on, rather than repeating what we have done before. Let's improve what we have, rather than starting again.
    • If C++ were extended in the direction of making it easier to call from other languages, and of making it easier to call routines in other languages, then this would become easier. But as I understand it, the C++ standard doesn't even talk about this. The closest it comes is with the extern "C" construct, which allows C programs to call a subset of the programs.

      I would not want to claim that this is an easy problem, but the C++ justifications of "Well, we can't tell the C compiler how to do things, so we'll just leave that unspecified." grates on my nerves. If you can't decide on the proper specification, at least you could define a way that would be guaranteed to work. And I don't believe they even talk about any language other than C (though that would be a reasonable lingua franca if it were better defined). But a C interface is sort of guaranteed to be a bare minimum that leaves out all of the OO features. I'ld like it to be something that would open up C++ templated routined to being called from Smalltalk, etc. Then I might agree that C++ could be worked on as the "only needed" language. Currently it doesn't have anything approaching that state. Java comes closer, despite its single inheritance and clumsy interpreter.

      Note. Much of the foregoing is wrt Standard C++. gcc is a somewhat different beast. It is aggressively much more compatible between languages than the C++ standard requires. But it suffers the problem that its features are non-standard. And this is a problem. Standards are the fixed posts around which designs evolve, so if the standard doesn't proclaim that "this should be a feature of the language" then it's quite easy to evolve away from it.

      Condider, e.g., purely virtual C++ compilers. For awhile there were several C++ compilers that would preferentially make all class methods virtual calls, so that they could be overridden by inheritance. That seems to have slipped away. I don't know the precise reason, but the result is that code written for those compilers is often broken with the currently common compilers. Because they were using a useful extension that wasn't in the standard.

      So for working code, rather than experimental code, it's important to only depend on features specified by the standard. Which means that as long as the C++ standard doesn't specify decent methods for connection to other languages, then such a feature can't be depended upon.

      Languages rarely give up a feature that was a part of the standard. At most they will mark it as obsolescent, and suggest that all new programs adopt another way of doing things. They only give up features quite reluctantly, and with as much backward compatibility as possible. And I have a feeling that C++ may have painted itself into a box. In the name of efficiency it has specified that certain features should be implemented in certain ways with certain results. So it would, for example, be quite difficult to import a feature like Smalltalk/Python/Ruby's run-time binding of name to feature into it. It has gained efficiency, and lost flexibility. The obvious way to regain the flexibility is to allow the flexible part to be done in another language. But it's difficult to link most other languages to C++. They generally need to pipe themselves in through the restricted pipe of a C compliant interface. (Though gtk shows both a way around that, and the costs involved in using that way.)

      And, no, I don't have any better choice for the central position. Even though it's also missing garbage collection (another bonus of its C heritage -- it's hard to distinguish pointers from data).

    • I agree and disagree with your point. On the one hand, I agree strongly that there are too many languages. I have yet to see anyone post why Ruby is different from Perl or Python.

      And I strongly agree that making Java a compiler switch to a C++ compiler might have been a Good Thing.

      BUT...! The reason C++ sucks (to me, anyway) is the language complexity, not lack of features. In other words, it has too many features. The reason I like Java-the-language (versus Java-the-environment, which I don't like) is that it strips out a lot of the B.S. that makes C++ unwieldly, like multiple inheritance, operator overloading, and other "somewhat useful features but not worth the extra complexity and downsides".

      Sometimes to make something really good you have to throw away the past and start over with a clean slate. With languages, this is very dangerous, because it's hard to build up a following for a new language. The whole reason C++ was able to create a following is because it was semi-backward compatible with C.

      I don't know that much about C#, but it's guaranteed to be used and successful simply because Microsoft will probably embrace a huge internal development effort which will bleed over into the industry. I hope and pray that it turns out to be what C++ should have been... a nice, tight language like C with modern features, but without the insanity. I also hope and pray that it can be native compiled, and not require a Java-style runtime environment.


      • I think your point is interesting about C++ having too many features. But why not just have compiler switches that prevent use of some features? That way, if a project didn't need the complex features, they could be prevented from being used, assuring uniformity and, in some cases, ease of debugging.

        The features of C++ don't bother me. I just use what I want. Similarly, English is a very complex language. But, as a professional writer, I choose to avoid obscure words and poor constructions. For example, I usually avoid verb phrases ending in prepositions. I don't say "used to", for example.

        And the complex features of C++ are of higher quality than the complex features of a human language that was never designed. The complex features of C++ are very useful in special cases.

        What I really don't want is to have to change languages just because I need a particular feature.
    • "For a few years, languages were interesting to me. But now, I just want to do the job, not discover other ways to do the job. Let's move on, rather than repeating what we have done before. Let's improve what we have, rather than starting again."

      You sound like a guy I work with. I sympathize with him, because he's getting close to retirement. Maybe you are too. I think it was the "Pragmatic Programmers" who said you should learn a new language every year. I find it helps to keep the brain plastic. It's all too easy to get into ruts, but soon the joy is gone too, and you might as well be flipping burgers.

      Brent

      • Age is not the issue here. The issue is that it might be better to put more of the fine features into one language, rather than have so many languages.

        There would still be the same amount of features to learn, but they would not be scattered all over the programming landscape.
        • How do you think these experimental features are going to get into an ISO standardized language like C++?

          Do you think some smart guy like Matz, or Guido Van Rossum or Larry Wall can just go up to the ISO committee and say: "I've got this set of cool ideas -- let's add them to your language."

          Also, do you really think that all of the good ideas of Perl, SmallTalk, C++, Lisp and Icon can naturally fit together in a single language? It isn't always possible, nor advisable, to pile every possible feature into a language.

          Most people dislike C++ because it has TOO MANY FEATURES. That may not bother you but it is a big part of why Java caught on so quickly. So if you make an uber-language with every feature, you will CAUSE the creation of competitive new languages with smaller feature-sets. Smaller languages are often a reaction AGAINST bigger ones.

          • You are raising extremely interesting questions. If people don't like many features, should language designers provide subsets that people can access easily? Could a compiler switch make C++ like Java?

            Is the dislike people have for a language partly due to poor explanation of the features?

            I'm not saying I know the answers. I'm just thinking that we could do better for ourselves than create an average of one big language each year.

            Maybe the ideas of Perl, SmallTalk, C++, Lisp and Icon are just a subset of a larger truth that, if we recognized it, would simplify all languages.

            You raise an interesting question about the politics. My guess is that, if someone knew enough to lead us in a better direction, the politics would eventually be changed to fit the new situation.
  • I like the way this one teaches, is there a tutorial similar to this one for perl?
  • Most of the advantages being quoted are "ease of use", "rapid development", etc. Fine. But what about runtime? How does Ruby compare with Perl in running efficiency? Are there any benchmarks out there?


  • We've all seen the usenet post in the coffee room or on various websites. Usually under some title like:

    So how does one go about shooting themselves in the foot with Ruby ?

  • Horses for Courses (Score:2, Interesting)

    by Hairy1 ( 180056 )

    A associate once said about programming its "Horses for courses". What he meant was that we should use the best tool for the job at hand. When he said it he was talking about using Clipper (an dBase clone) over Quick Basic in 1990.

    Today I know two languages to what I consider 'professional level'. On Windows I develop stand alone applications with Delphi. Its easy to develop quality code - I define quality in this case by not crashing due to obscure memory errors. Its very hard to write code in Delphi which causes memory handling issues. Writing Delphi feels like the IDE wants to help you, but if you want to get your hands dirty you still can (unlike VB).

    For Web Development I now use Java. I wouldn't use Java for stand alone GUI apps because its still too slow compared to Delphi, but for server side web development it has the features I want - portability, easy to develop in, connects with SQL etc.

    Learning a new syntax takes time. You need to be sure that a new language is going to have a payoff in terms of being able to achieve something you can't in others. For years I wrote Delphi, as it was the best horse for the course. Now with Web Develoipment the course has changed, and Java is best (for me).

    That said, a programmer should be able to learn any language. But just because you can doesn't mean you should...

  • As the guy who wrote the article. (Score:5, Informative)

    by poet ( 8021 ) on Saturday August 11, 2001 @07:14PM (#2135449) Homepage
    It is important not to judge Ruby on this article.
    The content in the article is specifically designed to look like either Perl or Python. This was to generate a similarity that programmers from other languages can understand.

    The second one, article in the series looks a lot less like Perl and more like Python. This is due to Ruby being a true OO, very similar to Python.

    The third article will (if they let me write it) cover advanced Ruby structures and illustrate them by interfacing with the PostgreSQL database.

    The fourth article will cover Ruby/Qt.

    If you guys want to see these articles you may want to give some decent feedback on the Developer Works site.

  • so many choices (Score:2, Insightful)

    by RestiffBard ( 110729 )
    I'm just learning python now. There just aren't enough hours in the day for me to learn all of these languages.

    • Re:so many choices (Score:2, Informative)

      by Waffle Iron ( 339739 )
      I'm just learning python now. There just aren't enough hours in the day for me to learn all of these languages.

      Then learn Ruby. Python looks clean to the untrained eye, but you have to remember lots and lots of special cases because of the arbitrary mixture of object-oriented and procedural features.

      Ruby is extremely consistent and well thought out. I've used well over a dozen languages, and Ruby is my favorite by far.

      • I think one of the great advantages of python is the wealth of material the monty python scripts bring to the table. Endless material for tutorial and how-to writers. Think of the novelty of reassembling the string "spam, eggs, spam, sausage, spam, spam, bacon, spam and spam" in a million different ways using all the different types of sequence objects. Ruby just can't compete with this type of idiom.

  • The Pragmatic Programmers Ruby Book is Online (Score:4, Informative)

    by swagr ( 244747 ) on Saturday August 11, 2001 @05:22PM (#2142326) Homepage
    here [rubycentral.com].

  • Time for an icon.... (Score:3, Insightful)

    by jeffy124 ( 453342 ) on Saturday August 11, 2001 @08:01PM (#2145130) Homepage Journal
    I think it's time for Slashdot to draw up an icon for Ruby topics. This story is about the 5th maybe 6th Ruby related item to appear on /. in the past few months. A simple picture of a good red-ruby you would find in a jewelery store would do fine, such as one of these [israel-diamonds.com]. Anyone for it? Against it? Got a better pic to use?

  • Don't judge ruby based on the article (Score:5, Interesting)

    by MeowMeow Jones ( 233640 ) on Saturday August 11, 2001 @06:23PM (#2146774)
    There's nothing wrong with it, it just doesn't get into any of the crazy stuff that makes ruby ruby. So wait until the other parts come out or check out the Pragmatic Programmers Guide.

    If Python was the result of Lisp and C++ having a baby, Ruby is the result of Perl and Smalltalk having a baby.

    • If Python was the result of Lisp and C++ having a baby, Ruby is the result of Perl and Smalltalk having a baby.

      Which is funny, as Smalltalk itself is really a child of a Lisp mommy getting some unknown, alien artificial insemination. Some put Smalltalk in the LISP family of languages, but those who don't just avoid classifying it. Fascinating, it's family tree.

    • missing the point (Score:3, Insightful)

      by mj6798 ( 514047 )
      If Python was the result of Lisp and C++ having a baby, Ruby is the result of Perl and Smalltalk having a baby.

      The key features of Lisp are the use of a uniform notation for programs and data, a notation that makes it very easy to write syntactic extensions, and full support for functional programming. Python 2.1 now has some limited support for lexical closures, but users almost never extend its syntax. The key feature of Smalltalk is its programming environment. As a language, Smalltalk's main feature is the use of very descriptive method and argument names. Neither of those is shared by Ruby.

      Python, Perl, and Ruby are nifty little scripting languages, but don't think for a moment that if you are using them you are using the next generation of Lisp or Smalltalk. The object models of Python, Perl, and Ruby are general but slow and memory intensive, their programming environments are oriented towards scripting, not large system development, and compilation to native code, when it exists at all, is of limited benefit. If the scripting languages ever evolve into something like Lisp or Smalltalk, their object models, syntax, and semantics will have to change dramatically and incompatibly.

      • Re:missing the point (Score:2, Insightful)

        by rowland ( 12870 )
        Wow! I nominate you for the "Sweeping Statements Award." I especially like the way you say "The object models of Python, Perl, and Ruby."

        So far, I haven't heard anyone nominate these languages for "large system development," but a lot of large systems are made out of small systems, and while it is tempting to create these large systems in a uniform language (*cough*)Java(*cough*), this can be a mistake. I read a magazine article recently about a shop where they were replacing shell scripts with Java for automating tasks--which turned out to be a big mistake, considering the overhead of the Java VM.

        You're right about compilation to native code being of limited benefit to these languages. For the most part, it is a "benefit" they don't need. Take, for example, creating a complex web site in C or another statically-typed, and therefore easily-compilable, language. By the time you're on your third page, you'll realize you need some kind of templating system. Next, you'll discover you need to vary the appearance of pages based on aspects of your business logic, so you add conditions to your templating system. Next, you'll find management wants to be able to update the site quickly using cheap HTML monkeys and is reluctant to spend expensive programmer time recovering old ground, so you make the site entirely data-driven. So now you have a buggy, ad hoc, poorly-documented excuse for PHP! Sure, the code you wrote is compiled, but the system as a whole is slower, and it took a whole lot longer to write.

        You said, "If the scripting languages ever evolve into something like Lisp or Smalltalk, their object models, syntax, and semantics will have to change dramatically and incompatibly."

        Have you ever considered that maybe these languages ARE the evolution of Lisp and Smalltalk? With all due respect to Lisp and Smalltalk, their creators didn't have the benefit of Lisp and Smalltalk when creating their languages. Larry and GVR and Matz didn't create their languages in a vacuum. Even PL/1 must be of benefit to current language designers (here's what NOT to do!).

        Perhaps it would be of benefit to aspiring language designers if you could elucidate exactly how "objects models, syntax and semantics" could be improved and what the benefits would be--keeping in mind the purpose(s) of these languages.

        Granted, the best programming language doesn't always win out, but the purpose of evolution is to thrive, or at least survive. I am therefore equally suspicious of praise for highly-evolved-yet-dead languages and snubs of unevolved-yet-wildly-thriving languages.

        Brent

        • Re:missing the point (Score:2, Informative)

          by mj6798 ( 514047 )
          I nominate you for the "Sweeping Statements Award." I especially like the way you say "The object models of Python, Perl, and Ruby."

          Maybe you haven't noticed, but Python, Perl, and Ruby all represent objects as general purpose dictionary types, in contrast to the Lisp and Smalltalk approaches.

          Beyond that, I have no idea what you railing against. Did I say scripting languages were bad? Did I say people should switch to Lisp? What is your problem?

        • Re:missing the point (Score:2, Insightful)

          by RevAaron ( 125240 )
          Have you ever considered that maybe these languages ARE the evolution of Lisp and Smalltalk? With all due respect to Lisp and Smalltalk, their creators didn't have the benefit of Lisp and Smalltalk when creating their languages.

          I would definately agree that it's evolution, however, it's not a controlled evolution pointed forwards, like the evolutions that created Lisp and Smalltalk.

          Python, Ruby, and others are adaptations of Lisp and Smalltalk to a way of thinking that people used to C and Unix can handle. Smalltalk and Lisp are too advanced and forward thinking that languages like Python and Ruby have to take a forced step backwards to accomodate those who cannot advance. It's kind of sad in a way, but I suppose it's still a step in the right direction, as there's a better chance of converting C++, Java and Perl people to Ruby than converting them to Smalltalk or Lisp, unfortunately. Better part way than none!

  • Strict languages vs. hacked languages (Score:4, Interesting)

    by Anonymous Coward on Saturday August 11, 2001 @05:24PM (#2146983)
    I notice strong distinctions between those languages that have been developed by actual programming language researchers and those who hack together a language to scratch an itch.
    Usually the latter turns out to be some baroque conglomeration of features piled on features, creating a very top heavy feeling to the language, while the former classification languages all have a purity to them, e.g. smalltalk, lisp, and c.

    Some would defend the "hack languages" as a means to Rapid Application Development, but Smalltalk has been shown to be the most productive language, and Ruby/Python/Perl all seem to me to have a BASIC odor to them; I'm wondering if people are afraid to learn a new way of speaking?
    • Usually the latter turns out to be some baroque conglomeration of features piled on features, creating a very top heavy feeling to the language, while the former classification languages all have a purity to them, e.g. smalltalk, lisp, and c.

      Well, I mean, as long as we're talking in generalities here, the latter also seem to be geared towards getting jobs done where the former are geared towards elegant problem-solving. Purity is great when you're admiring something, but no one wants to hang out with the righteous virgin when they feel like getting laid. Personally, when I program, I'm not looking for my code to fit some elegant theory. I'm looking for the job to get done as succinctly as possible.

      Some would defend the "hack languages" as a means to Rapid Application Development, but Smalltalk has been shown to be the most productive language, and Ruby/Python/Perl all seem to me to have a BASIC odor to them; I'm wondering if people are afraid to learn a new way of speaking?

      I would say that Perl stinks more of shell and C than it does BASIC. If you're talking because it has a lot of built-in features, there are plenty of languages that have it. But out of all the languages you've mentioned, I found it ironic you say that because Perl has problem undergone the most intensive language development of any (and the new process probably blows efforts for other languages out of the water). Larry Wall has a great affinity for languages (both spoken and programming), and it shows, because, for English speakers, Perl is designed so that you can write it like you almost would speak it. Now, you might say that that is "hack"-ish, but that shows a lot more care for the process of programming than a language that idealistically sticks to a theoretical truth in favor of making the language easier to use.

      And provide a link to a study that shows Smalltalk is the most productive language. I'm not saying I don't believe you, but I personally find the "hack languages" to allow a much more natural flow between my brain and the screen, so I'd be interested in seeing how that conclusion was reached.
      • ...I personally find the "hack languages" to allow a much more natural flow between my brain and the screen, so I'd be interested in seeing how that conclusion was reached.

        Different strokes for different folks, I suppose. While you seems to say that the simplicity and elegance of Lisp and Smalltalk isn't practical, it is for me- my brain thinks in such terms. Perl is, for me, in many ways almost a big of a pain in the ass as C++, because it tries way too hard to fit what Larry Wall said is the "natural flow."

        Jujst another perspective...

    • I'm wondering if people are afraid to learn a new way of speaking?

      You bet they are! Ruby, Perl and Python are putting in terms of a contrived BCPL derived syntax Lisp and Smalltalk. They don't quite embody the semantics fully (Ruby seems about the closest), but as people are too lazy to learn a fully new way, they have to give people training syntactical wheels.

    • I agree Ruby and Perl seem to be like the latter type.
      Python, however, is a truly clean, well-designed, quite-pure, strong-typed language.
      I wouldn't say it has a Basic odor at all, besides for a built-in 'print', perhaps :)

      Basic is braindead and has no library - instead, it has its entire library built into its syntax in a horrid way.
      Python is the exact opposite - many many libraries separated into modular modules, with only flow constructs, OO organization, functions and exception handling built in.
      • Python gets all of its object-orientness from C++, Ruby gets its from Smalltalk. C++ is generally regarded as a crude (although useful) hack, whereas Smalltalk is the definition of elegance itself. So, if it is cleanliness you want you should move to Ruby. I find it amusing that while the Pythoners mock the Perl-hackers that refuse to upgrade to Python, they themselves refuse to upgrade to the next level .
        • Python gets all of its object-orientness from C++, Ruby gets its from Smalltalk.
          I have a strong sense that you don't know Python. Python gets *none* of its object-orientedness from C++. Python has full dynamic dispatch, the ability to catch unknown method calls at runtime and so forth. In other words it is much more like Smalltalk than like C++. Python's OO credentials are just as strong as Ruby's. This is especially true for Python 2.2 where you can subclass even primitive types.
          I find it amusing that while the Pythoners mock the Perl-hackers that refuse to upgrade to Python, they themselves refuse to upgrade to the next level .
          If Ruby were clearly the next level, you'd be right. But Ruby has as many weaknesses relative to Python as it has strengths. Python's threads are extremely robust (at least on single-processor machines). Ruby's are weak. Python's industry support is much better. Python has full multiple inheritance. Python has less "syntax". So Ruby isn't more OO and it isn't more elegant. It is at best more "Ruby" -- that will be important for some people and not for others.
          • I have a strong sense that you don't know Python.

            I get the stronger sense that you don't know Ruby -- most Rubyists tend to be ex-Pythoners and not the other way around, but nevermind.

            Python gets *none* of its object-orientedness from C++

            Python lacks metaclasses, lacks a true unified object hierarchy, and supports multiple inheritance (considered a very bad idea by most experts in OO. Like the "goto" statement, multiple inheritance may seem useful at times but it leads to unmaintainable code). All these are simple repeats of the mistakes of C++.


            Python's OO credentials are just as strong as Ruby's. This is especially true for Python 2.2 where you can subclass even primitive types

            Yes, Python is improving, but all these improvements (like allowing the subclassing of primitives) only serve to point out flaws in the design (why aren't primitives normal objects in the first place?)
            • I get the stronger sense that you don't know Ruby -- most Rubyists tend to be ex-Pythoners and not the other way around, but nevermind.

              People do tend to progress from more well-known languages to less well-known ones. They don't go to a bookstore and pick up a K book and think: "this would be a good first language." I've played with Ruby enough to decide that it is neat but not appropriate for many of my projects and not a sufficient improvement over Python for the rest.

              Python lacks metaclasses, lacks a true unified object hierarchy, and supports multiple inheritance (considered a very bad idea by most experts in OO. Like the "goto" statement, multiple inheritance may seem useful at times but it leads to unmaintainable code). All these are simple repeats of the mistakes of C++.

              Python 2.2 has metaclasses, a unified object hierarchy and supports multiple inheritance which is quite useful and safe when used thoughtfully.

              It is simply a matter of historical fact that Python was not based upon C++. If it shares features with C++, those would probably be traced back to Simula through Modula-3. Smalltalk is also based upon Simula.

              Yes, Python is improving, but all these improvements (like allowing the subclassing of primitives) only serve to point out flaws in the design (why aren't primitives normal objects in the first place?)

              Nobody would claim that Python 1.0 was perfect, nor that Python 2.2 is perfect. Nevertheless, you haven't yet mentioned a feature of Ruby that isn't in Python 2.2. There certainly are such features -- but they get increasingly esoteric as Python improves. If I have to choose between Bertrand Meyer-approved-OO-cleanliness and native threads that don't block when you do I/O, I would choose the solid threads. OO-cleanliness is about conceptual elegance and native threads are about getting the job done.

              And how deep is Ruby's Unicode support? If you can please point me to documentation on using Ruby's regexp engine to match Unicode characters, I would appreciate it.

              My current Python projects depend heavily on both threads and Unicode. Mixins, multiple inheritance and the ability subclass "integer" really don't matter one whit! I am mostly happy that Python is unifying its type system for rhetorical reasons. Practically it hardly matters at all!

              If you want to impress the vast majority of programmers who are not language collectors, you'll have to show us some program that are hard to solve in (e.g.) Python and easy to solve in Ruby.

              For this and other reasons, it is not accurate to paint Ruby as the next step after Python. It is another good language with strengths and weaknesses. One day it will have a superset of features that Python currently has...but Python will itself have evolved by then.

              • And how deep is Ruby's Unicode support? If you can please point me to documentation on using Ruby's regexp engine to match Unicode characters, I would appreciate it.

                Here you have an issue of implementation, not design, but at present a legitimate issue. Ruby is a product of Japan, and ironically, from the perspective of Westerners, who generally see Unicode as a sort of peace offering to Asians to make up for the dark ages of ASCII, the Japanese hate Unicode and prefer their own multibyte solution. So, the status of Unicode in Ruby is somewhat primitive at present. However, as Ruby was designed with multibyte characters in mind, it should be much easier to improve the Unicode support than in other languages.
              • It is simply a matter of historical fact that Python was not based upon C++. If it shares features with C++, those would probably be traced back to Simula through Modula-3. Smalltalk is also based upon Simula.

                No, Smalltalk borrowed ideas from Simula. Other than the idea of classes, Smalltalk derived very little else from Simula. Most everything else came from Lisp.

          • If Ruby were clearly the next level, you'd be right. But Ruby has as many weaknesses relative to Python as it has strengths

            No, the next level isn't Ruby. It's Smalltalk. It's Lisp. That's the point your post's parent is saying- if you can move from Perl to Python, why not go all the way to the source, to the acme of elegance and simplicity- Smalltalk or Lisp?

    • Re:Strict languages vs. hacked languages (Score:5, Interesting)

      by smallpaul ( 65919 ) <paul@prescod.CURIEnet minus physicist> on Saturday August 11, 2001 @05:40PM (#2146443)
      I notice strong distinctions between those languages that have been developed by actual programming language researchers and those who hack together a language to scratch an itch.
      "Actual programming language researchers" are typically not even interested in designing languages for general purpose use. Often they are just trying to explore a particular idea of aspect of programming.
      Usually the latter turns out to be some baroque conglomeration of features piled on features, creating a very top heavy feeling to the language, while the former classification languages all have a purity to them, e.g. smalltalk, lisp, and c.
      I think you're going to have to define your terms if you want to make this point. How were Kernighan and Richie programming language researchers but not Van Rossum and Wall? By now, the latter two have spent about ten years of their lives thinking about almost nothing other than programming languages.
      Some would defend the "hack languages" as a means to Rapid Application Development, but Smalltalk has been shown to be the most productive language,
      Could you provide a reference to back up that claim? I'd like to see evidence that Smalltalk fares well at system administration or text processing.
      and Ruby/Python/Perl all seem to me to have a BASIC odor to them;
      Now you are really grasping. That claim isn't even solid enough to refute.
      ...I'm wondering if people are afraid to learn a new way of speaking?
      I don't know...are you? If you are into purity and elegance, I would suggest you give either Python or Ruby a real try. There are many Lisp fans that like both and Ruby is especially popular amoung Smalltalk users.

  • Why learn another language? (Score:5, Informative)

    by Dalroth ( 85450 ) on Saturday August 11, 2001 @07:36PM (#2153745) Homepage Journal
    Well, I see a lot of people complaining as usual... Why should they learn another language? So I thought I would throw in my $0.02 for all a languages (not just Ruby, which I am particularly fond of).

    A lot of you people come from what I call the Computer Science Student mentality. This unfortunately something I've noticed as a side effect of the way computer science is taught in most schools. It's quite unfortunate, because that clearly isn't the aim of the Professor's when they are teaching classes this way.

    I'll use my school as an example. When I started at the University of Dayton, about 7 years ago, every class was taught in ADA. It was a horrible horrible expierence. The ADA compilers were horribly lacking at the time, and anybody who has done any work in ADA will know that it is an extremely strict and picky language. That has it's good and bad sides when it comes to teaching programming, but I'll save that for a different discussion. I had no problems, since, well, I had a good solid 4 years for Pascal and C/C++ programming experience before I even started college, but this seriously affected the other students in my class.

    The problem was, about two years into the program, my school decided (thank god) to switch the department over to C++. This was a great move, because now the students were being taught a language that they could actually apply in the real world (beyond the confines of the Wright Patterson Air Force base anyway). It worked out quite well for the newer students, but my classmates were blindsided. Most of them suffered through half a semester of C (the other half of the semester was 360 assembler) and never even touched upon C++. They should have just been able to pick up a C++ book, apply the concepts they learned from their ADA classes and the syntax from the C++ book and their C course and move on, but most of them had a hard time doing it.

    Why was that? They all knew the concepts. They all knew how to write their algorithms, and their trees, and their stacks and queues. Yeah, they weren't taught how to write real software, but they clearly knew the basics. I spent more time helping others learn these concepts than I did doing my own homework the first two years, so I know what they were capable of from first hand experience.

    The problem was entirely in their minds. C++ is a huge ugly beast, and it is a bit imposing when you first start. But if you've got two solid years of programming behind you, it should be a relatively smooth and easy transition. Most of them didn't realize this though. They were scared of C++, they were scared of new languages, and they suffered as a result.

    The simple fact of the matter is, if you know one language, you know them all. It's not the syntax that makes the difference, it's the concepts that you express within the framework of the language's syntax that are the real guts of programming. My classmates took awhile to realize this (and I'm sure many of them still don't). That's the same thing with Ruby, or Python, or Perl, or just about any language. Unless you are making the jump from procedural to OOP, or OOP to Functional for the first time, you *CAN* pick up a book and learn a new language in a days time. The only thing stopping you is yourself.

    Now, the other part of this is, why would you do that? I love learning new languages, and I love learning new languages for a few reasons. These reasons apply to every programmer, and I honestly don't understand why some people are so opposed to learning something new. I guess that's what seperates a good programmer from a bad programmer. So if you want to know why you should learn Ruby, or LISP, or Haskell, or even Visual Basic, I'll tell you why.

    1. It helps keep your skills in tip top shape. Perusing a computer manual may remind you of algorithms or techniques you haven't used in a long time and forgotten.

    2. You always seem to learn something new. Not some new technical trick that only works in one lanuage (although that definitely happens), but just a different way of approaching problems that sometimes can transcend language boundaries.

    3. You may find a new language that allows you to get the job done faster!

    4. You're enhanced knowlege of languages looks great on your resume no matter what you use as your primary language.

    5. You learn the way other people think. And I don't want to gloss over this one. As a programmer, you frequently have to work with other programmers. Learning new languages is a *GREAT* way to see how other people do things. To learn the way other people think, so to speak. By learning Ruby and Smalltalk, you start to learn why people in those communities are so die hard about OOP programming styles. By learning LISP or Haskell you start to learn why Functional styles even exist! And it all comes back full circle. Techniques I learned from Haskell I now use when writing C++ programs and vice versa. It only made my C++ code better.

    Knowlege is power, and learning new languages is one (of many) ways of increasing your knowlege. Go ahead and try it, even if you think you won't use the language, and even if you're just starting out and don't think the transition from your learning language to a new one will be easy. You just might be surprised by how much you already know, and how much you have yet to learn. That's the real benefit of it.
    • I appreciate and share your view that by learning multiple languages you enlarge your toolbox, and in the big picture all languages are intertwined. (Jeez. I sound like I'm rambling on about "The Force" or something.)

      I've noticed a similarity in my "night job" as a musician, where playing different types music acts in a similar way to programming in different languages. You pick up stuff in one style that can enrich your playing of another style. Well I sure am staying on topic, eh?

      One comment I wanted to make regarding Picking up another language in a day. I agree somewhat. There was no question that after programming in (time order) Pascal, C, Fortran, Ada, Lisp, Clips, and Scheme I was able to "pick up" Perl pretty quickly. That said, it took some time to really learn the Perl idioms and to do things in the "Perl Way". I've seen my share of C code that was really Fortran written in C, or Java code that was really C written in Java (procedural vs OO). With appologies to Heinlein, it takes longer than a day to grok a new language.

      • With appologies to Heinlein, it takes longer than a day to grok a new language.

        Not always. IMO, Java built on my existing C++ and Smalltalk knowledge that it didn't really provide anything that Smalltalk (and to a lesser extent, C++) could provide- it was merely a new syntax and was a part of a different business model. For those unexposed to Smalltalk, Ruby has some aspects which may take a while to grok, but for the most part, it builds on my existing knowledge, leaving almost nothing to grok. But in many cases, it's more convenient.

        I'm stil trying to get to know how to use Perl, but not just to grok it- it seems there are so many rules for every tiny thing you'd want to do that I've had to keep docs open for anything that departs from print "hello world...";

    • Re:Why learn another language? (Score:4, Insightful)

      by StrawberryFrog ( 67065 ) on Sunday August 12, 2001 @06:42AM (#2121234) Homepage Journal
      Great post, but IMHO any 3-year CS course that aims to teach only one language is going about things completely the wrong way.

      You should spend time in (for e.g.) a simple teaching language to start off, 1 mainstream procedural/OO language, one functional language, one scripting language and study briefly a sampling of languages of comercial or academic interest, and what makes them interesting or sucessfull.

      IMHO when you learn your second language is when you start to 'get it' about what is an essential feature, and what is an accident of syntax or history in programming.

      I wouldn't call knowing only 1 language a "the Computer Science Student mentality" because a CS graduate should definitely not know just one language - they should know how to pick up any language quickly, having had practice at it.
      • I noticed this too. I'm curious what schools are pursuing this type of curriculum. When I was in school, it seemed like I was learning a new language for every class. Whatever language was most apropos was (usually) used. Freshman year Intro class? Pascal. Artificial Intelligence? Lisp. Operating Systems? C++ (that's a little odd, I admit.) Embedded Systems? 68K Assembly. Numerical Analysys? Mathmatica. The default of course was good old C, which I ended up doing a fair amount of.

    • In the second half of his post above, Dalroth has made a very sensible case in my opinion, for learning other languages.

      (Dalroth seems like the kind of programmer employers want to hire. But he has provided no way to contact him. In fact, he is very negative about being contacted in his bio.)

      I'm tired of new languages (read my post #128), but Dalroth has a point that other languages sometimes teach other ways of thinking.

      The answer seems to be to put all the knowledge in one place, or as few places as possible. At some point even Dalroth will decide that one more language is too many.
      • The answer seems to be to put all the knowledge in one place, or as few places as possible. At some point even Dalroth will decide that one more language is too many.

        I doubt he will. That is, there is no point at which there are too many languages. To say otherwise is just a submission to the stronger and stronger trend of American capitalist corporate philosophy under the guise as "effeciency."

        Let me explain. Oftentimes new languages are created for someone to learn the ins and outs of designing and implementing a language and it's tools, be it an interpreter or compiler, native or bytecode. Writing a language seems to be a popular enough of a hobby that it won't soon go away. Eventually, some schmuck, consortium, or business will come up with some new whiz-bang theorectical basis for some new language that will make everything look that much older.

        Now, you don't have to go and learn any of these new languages. No one is forcing you. In fact, most of you are already mentally stuck in the 60s, with languages based on flat files. And that's fine. But the nature of science is that there's a lot of experimentation before discovery, and regardless of whether or not you think Ruby is that useful, it's serving some use to someone, and seems to be advancing computer science (not "programming", but CS) to a degree, if only for a small group of people.

    • Amen! I wish I had mod points ( +1 Insightful ).
    • The simple fact of the matter is, if you know one language, you know them all.

      I was about to object to that, but then you wrote...

      Unless you are making the jump from procedural to OOP, or OOP to Functional for the first time, you *CAN* pick up a book and learn a new language in a days time. The only thing stopping you is yourself.

      Thank you for being one of the few to acknowledge that while languages using similar ideas may be easy to learn once you know the first, languages using fundamentally different approaches might take some effort! Sadly few people seem to realise this.

      Having said that, I'm afraid I have to disagree with your "one day" as well. You can learn a new syntax in one day, sure. But how long does it take to learn the new idioms? Java and C++ have similar syntax, but Java uses a GC and finally for resource management, while C++ has predictable destruction and uses the abysmally-named-but-rather-neat "resource acquisition is initialisation" idiom. Anyone working seriously in these languages needs to appreciate this distinction, but it's not written down in (m)any of the books.

    • There seems to be something about schools that systematically damps down any enthusiasm for any subject. I'm really glad that programming doesn't feel much like math to me. I used to be enthusiastic about math, but a few years as a math major killed that. Now I avoid it to the extent possible. But programming doesn't feel like math (to me), so I've got a decent job that doesn't feel bad.

      If you don't feel enthusiastic about something, then it can feel like an imposition to be required to learn something different. It doesn't much matter what. And a new language certainly can qualify.

      OTOH, languages certainly do run in tides. There don't seem to be any decent books right now on "Data Structures and Algorithms the C++ way" that aren't primarilly texts. Now I'm trying to switch over to C++ after using a raft of different languages, so most of the introductory books get insufferably dull. I don't want to work through all the drill. Been there, done that. I want a guide on picking things up fast. The best book that I've found so far is "Data Structures, a PseudoCode approach with C++". It isn't really designed as a reference book either, but at least it doesn't stop in the middle of an algorithm and say "the rest is left as an exercise for the student". So I may be able to get my AVL tree working and tested by Monday. (Then I need to decide whether to switch the code over to Eiffel, or recode the Eiffel a bunch of Eiffel in C++ ... or experiment with trying to link the two in a manner not covered by the C++ standard, and quite compiler specific in Eiffel.)

      So using lots of languages has its drawbacks, too.
      • There seems to be something about schools that systematically damps down any enthusiasm for any subject. I'm really glad that programming doesn't feel much like math to me.

        Perhaps it's because most school in America, both secondary and tertiary, seems to be geared towards producing employees, and not thinkers? It used to be that you'd learn many ways of thought, and usually, many languages when persuing a CS degree. Now, they teach you C, C++, and Java. Forget that you may not learn any real science or how to think and synthesize, you're taught how to use the tools. At least they still teach students to experiment in Biology, rather that just showing them how to follow procedure and use the microscopes.

  • Comment removed (Score:3, Insightful)

    by account_deleted ( 4530225 ) on Saturday August 11, 2001 @08:46PM (#2169595)
    Comment removed based on user account deletion

Slashdot Top Deals

After all is said and done, a hell of a lot more is said than done.

Close