Scripting Bulletin, 2002

NEWS CONTENTS

• 200102 : European Unix Platform (EUP) - e-zine by Pjotr Prins ( 16-05-2002 )

Old News ;-)

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

16-05-2002

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 (http://www.pragmaticprogrammer.com/). The book has an on-line version at http://www.rubycentral.com/book/. 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
  end

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
    end

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

  end

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 = form.next();
  }

the Ruby way is:

  class Forms < Array

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

  end

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

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 http://jruby.sourceforge.net/.

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

• ``Programming Ruby'' by David Thomas and Andrew Hunt, Addison-Wesley, Oct 2000, ISBN: 0201710897. Also online at http://www.rubycentral.com/book/
• ``Ruby in a Nutshell'' by Yukihiro Matsumoto, November 2001, ISBN 0-59600-214-9. See http://www.oreilly.com/catalog/ruby/ for more information.
• The Ruby Language website at http://www.ruby-lang.org/en/
• The Ruby Application Archive contains many libraries and bindings at http://www.ruby-lang.org/en/raa.html
• The pragmatic programmers at http://www.pragmaticprogrammer.com/ruby/
• The C++ Programming Language, Bjarne Stroustrup, 1040 pages, Addison Wesley; ISBN: 0201700735

... concepts^*)

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

... Prechelt^**)

http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprt_computer2000.pdf

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

Society

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

Quotes

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

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

History:

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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. 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.

Last modified: March, 12, 2019