May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Scripting Bulletin, 2002

Prev Up Next

Top Visited
Past week
Past month


Old News ;-)

European Unix Platform (EUP) - e-zine by Pjotr Prins


Every few years something significant happens in the land of computer programming. In my opinion the Ruby computer language is such a land mark. *)

Over the years I have seen programmer productivity go up. These are no hard measured calculations, but I have the impression that every five years the speed of delivering software doubles. Not only that, the curve for writing maintainable software appears to increase lineairly too. A lot of that speed can be attributed to the tools of a developer. And core to the tools is the computer language.

1. A short overview of main stream languages 

Computer languages are essentially alike. There are more similarities than differences between any language. Nevertheless, the differences have a large impact solving problems, finding ways of expression and human interaction. For example LISP, a language of great beauty and simplicity in conception, reflects its affiliance to the computer more than to the human. A language easy to interpret is not necessarily easy to program, as many a student can attest. LISP's most amazing feature is that it shows with how few rules one can create a powerful computer language.

Structured languages like Pascal and C clearly bridged a gap between native assembler and quick human readable coding. C is still widely used where performance matters - it is possible to write close to assembler as the Linux and BSD kernels prove.

With C++ in the early nineties I personally went through a period of exploration and discovery. Classes, objects, containers, operator overloading - the works. Reading Stroustrup's classic book was crucial to understanding C++ as a language - and I loved it. But with hindsight I can see it takes something to become productive in C++, it is not for everyone.

JAVA came to the rescue. A much simpler language with an elegance in OOP (object oriented programming). JAVA has some down sides, slow JVM's dealing with large libraries, and the language has some short comings too. Make an experienced C++ programmer use JAVA and the complaint will come that it feels like working with the hands tied behind the back. Nevertheless JAVA is great for corporate type team programming efforts. As a languauge it goes some way in enforcing structure and using OOP concepts *).

In parallel two other languages made a mark in the nineties: Perl and Python. Both are (interpreted) scripting languages. These languages have some real advantages over C++ and JAVA in terms of delivery time of software (more on that below). And With current levels of computing power performance is hardly an issue for most 'user land' software.

Perl was a revolution in a way. and most of the productivity boost was because of the introduction of a full programming language with light notation for regular expressions, arrays and especially hashes.

Perl has some real problems, as almost everone will assert who has participated in large Perl programming efforts. Perl has OOP extensions, but they are non-obvious and laborious. I enjoyed learning Perl OOP because it taught me a lot about OOP itself and how to implement OOP in a language as a single hack. Meanwhile writing Perl OOP is no joy. Maintaining a large Perl source base is only possible with the highest level of discipline by the coders - and the language itself does not help enforcing right coding practices.

Python is cleaner as a language though its OOP was added as an afterthought - and shows it. I spent some serious time looking into Python and personally did not like it that much. It gives a lot, but runs short for example with object elements all being public. That means in a team effort developers have trouble understanding how their classes are used (or abused). In my case I would even have trouble trusting my own code. Operator overloading is ugly, the syntax of a colon after an 'if' statement I find non-obvious etc. The indentation idea is clever, but somehow it doesn't improve code readability. In short, Python almost makes it, but not quite.

2. Introducing Ruby

Late last year I got my hands on the Ruby book by the (self-named) pragmatic programmers Dave Thomas and Andy Hunt ( The book has an on-line version at I read the book in one go, and it goes into the hall of fame of important computer books, as far as I am concerned, right next to the Stroustrup. After reading I almost skipped sleep for a week. I was so excited by the implications of Ruby, a programming language that reads like poetry.

The author of Ruby, Yukihiro Matsumoto, a.k.a. 'Matz', knows his languages (LISP, Small Talk, Perl, Python and others) and aimed to create his perfect language. Ruby follows the Principle of Least Surprise - and funny enough, it gets close. It feels, in fact, exactly like the computer language I have wanted to design all my life (without really knowing it). And maybe it is the case - it comes out of a common archetype of computer languages.

Ruby was developed after 1994 and does not carry the baggage of Perl and Python. It is the new kid on the block. And despite its newness it has everything I want in a computer language and more. It also comes with extensive libraries - not as rich as Perl's CPAN - but after a year of working with Ruby I haven't missed any critical components. Ruby is complete with HTML and FTP classes, CGI support, XML parsers, database libraries, GTK and Qt bindings and even a pure Ruby BTree library. It is also quite straightforward to link up Ruby with Python libraries - which gives it an even richer base.

Ruby is well supported on Unix and Windows. Developing on Unix and deploying on Windows works without a hitch - including GUI development.

3. Developer Productivity

A very interesting study related to developer productivity was executed by Lutz Prechelt **). The outcome is that the amount of time needed for software delivery is directly correlated with the number of lines of code that have to be written. Projects written in C++ and JAVA take double the number of lines as projects in Python and Perl, so the development effort takes (as an indication) twice the time.

Writing code in Ruby improves productivity even more, surpassing Perl and Python. The syntax is very forgiving and feels natural. For example there are no semi-colons.

  if i == 15
    print i

Maybe I am worse than other developers, but I find I often have to execute an edit/compile cycle because of a end-of-line typo. Less interruptions make programming a flow-like effort. It is amazing how often a piece of Ruby code is written and runs in one go.

Because of Ruby's light syntax for defining a new class it is really easy to create new classes and write support for testing at the class level:

  # form.rb
  # Form class derived from Document

  class Form < Document

    def initialize
      # ---- Constructor

    def mymethod s
      # ---- Do something with s and return s
      print s


This results in OOP design on-the-fly and prevents the coder from lazily opting for other solutions. I have to admit that in Perl my OOP would degenerate because of the effort involved. With Ruby this never happens.

There are language features which are not available with the others. Ruby supports closures which assigns code responsibilities to the proper object resulting in cleaner code. With Ruby writing 'for' and 'while' loops is rare. Less error-prone and cleaner constructs like 'each' become natural to implement.

Instead of (JAVA like) every time:

  Form form = forms.first();
  while (form != form.last())
    if (form.valid())
      // ---- Do something
    form =;

the Ruby way is:

  class Forms < Array

    def each_form
      each do | form |
        yield form if form.valid


  forms.each_form do | form |
    # ---- Do something

Where the right responsibility is captured within the Forms object.

For more complex projects maintainability becomes an issue. Proper OOP design helps to bring structure and make the the source code logical and transparent. All these languages support OOP to a certain degree, but Ruby shines in ease of use and predictability.

Delving deeper into the niceties of Ruby is beyond the scope of this article. I strongly recommend the book by Thomas and Hunt and also Matz's 'Ruby in a Nutshell' - which has just come out. The latter book, obviously, is merely a reference, it won't take you through the dazzling heights of 'Programming Ruby'.

4. Switching Over

People often ask the following questions:

Why should I learn another programming language?

Or laziness versus love. Every computer language has something to offer, and the added insights will make you a better programmer. JAVA taught me to write better C++, Ruby taught me so much I don't intend to go back.

Why move from Python?

If you are happy with Python there is, arguably, not a significant reason to switch. There are even two pretty strong cases for Python: The Zope WWW framework and Jython. Both very attractive in specific circumstances.

There are quite a number of Python programmers that have switched to Ruby. It may be a lot more rewarding than it looks. Remember the days when people were questioning a change from Perl to Python? Once switched no one appears to want to go back.

ESR made quite a strong case in Linux Journal for moving from Perl or C++ to Python. All his arguments are familiar and applicable to Ruby.

Why move from JAVA?

Ruby's role may be to both strengthen and replace JAVA. JAVA's strength, at this moment, is for medium to large server side projects and distributed environments. Ruby kicks in on the deployment side and for writing proof-of-concepts. Meanwhile a lot of programming concepts in Ruby are related to JAVA. I can see Ruby playing a role in these environments once bindings become available. Matz is working on a byte-code version of Ruby. A JRuby project took off on

JAVA is strongly embedded as a language in corporate environments and will be for some time to come.

Working with JAVA is intentionally very 'verbose'. But that also means it takes a lot of time to achieve the same results.

Once having tasted real wine it is hard to drink the lesser stuff. Ruby is an excellent Red Wine (and maybe one could add that JAVA is expensive coffee!).

What about Perl6?

Perl6 appears to have a lot of new features. Mostly it is still vapourware. Meanwhile Perl, even in its version 5 incarnation, contains a lot of baggage. Even if it intends to give similar functionality as Ruby it will never be as clean.

I have more than five years of Perl under my belt and only one of Ruby. Coding Perl still makes me revisit syntax issues often and rereading up on functions. With Ruby my experience is that going back to the manuals is a much rarer occasion. I don't expect Perl6 to change that.


5. Conclusion

For raw performance C/C++ is still the best choice. For large multi-platform team efforts you may be best off with JAVA. But when it comes to delivery speed and proof-of-concepts you should think seriously about using Python or Ruby. Perl I would reserve for system administration tasks.

Ruby has some distinct advantages over Python. It is a far cleaner OOP language with excellent features while it supports Perl's regex type terse notation. It scores high in enabling one to write short conscise and maintainable code.

In fact I do most of my development in Ruby now. Only touching JAVA and C++ when I have to.

Ruby may not be a new paradigm, nor represent a new generation, but it takes the best of many programming languages and takes productivity to a new level. I am not original in stating Ruby may supercede both Perl and Python and will make many a JAVA programmer envious. Ruby is a land mark in computer programming.

6. References

... concepts*)
Note: a bad programmer can mess up the greatest computer language. In this article a certain level of programmer quality is assumed
... Prechelt**)

*) This article was published earlier in the on-line edition of Linux Journal 


Other articles by Pjotr Prins:
  • SANE Times (Issue 1)
  • ROCK Linux Guide
  • 4 issues of the SANE Times (SANE 2000)
  • …diteurs d'eup, listes de diffusion et indications pour les auteurs
  • Book Review: Programming with Qt
  • Using Rock Linux on a Sony ultra portable laptop
  • Book review: Open Source Development with CVS
  • PostgreSQL User Experience
  • eup Editors, Mailing Lists & Guide Lines for Authors
  • Linux Politics
  • Editorial
  • eup Mission Statement
  • Linux

    E-mail: Pjotr Prins

  • Etc

    FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

    ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  


    Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


    War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


    Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


    Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

    Classic books:

    The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

    Most popular humor pages:

    Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

    The Last but not Least

    Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

    The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

    Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

    FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

    This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

    You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


    The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

    Last modified: January, 24, 2014