Dr. Dobb's | Programming in Ruby


	Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

January 01, 2001

Programming in Ruby

(Page 11 of 11)

Jan01: Designing Ruby

Designing Ruby

By Yukihiro Matsumoto

Yukihiro Matsumoto is the creator of Ruby. He can be contacted at matz@ zetabits.com.

Designing the ideal language has been a dream of mine since my student days. It wasn't until 1993, however, that I realized that as computers increased in power, new opportunities were opening up for object-oriented programming (OOP) and interpretive (scripting) languages. Over time, I narrowed my interest to Perl and Python, but they still weren't what I wanted. Consequently, I designed Ruby.

When I first read Programming Perl, by Larry Wall, et al. (O'Reilly & Associates, 2000), I was impressed not only by Perl's features and syntax, but by Larry Wall's basic tenants, in particular: "Easy things should be easy, hard things should be possible" and "There's more than one way to do it."

When I started designing what ended up being Ruby, I borrowed the best from languages such C, Perl, Smalltalk, Lisp, CLU, Eiffel, and the like. In the process, I soon realized that computer languages should follow the principles of human-machine interface design, specifically:

Consistency. I'm not a minimalist, but I do believe that programming languages should be consistent. A small set of rules should cover the entire language. For instance, in Ruby, all data is an instance of some class without exception. Everything is treated equally.
Conciseness. I want my computer to be a servant, not a master, so I'd like to tell it what to do quickly and efficiently. I removed extraneous language elements, such as declarations, static type specifications, and the like. They are all good, but aren't necessary for concise programming. A rich set of literals (as in Perl) helps concise programming, too. In general, Ruby scripts are as concise as Perl scripts, yet far more readable.
Flexibility. A language should not restrict expression, but should enhance it. It should be general purpose. "Easy things should be easy, hard things should be possible." But, you know, even hard things can become easy using proper abstraction, thanks to Ruby's deep object-oriented nature.

I also wanted Ruby to be natural to use, and I wanted programmers to feel at ease when coding in it so they can enjoy the act of programming itself. To me, this is the ultimate goal of language design. I have to admit, I don't believe I can satisfy everyone — every programmer has different needs. But I still believe I can satisfy many, including myself.

Programming in Ruby makes me happy, and I've been told that many others like programming in Ruby as much as I do. I want you to enjoy programming and hope Ruby helps you to this end.

DDJ

Previous Page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11


RELATED ARTICLES Barbara Liskov on Inventing Language Go: A New Programming Language from Google ScalaTest Testing Framework Released Actor Virtual Machine State of Open Source Software Integrity Report Released		TOP 5 ARTICLES No Top Articles.


	FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition	Site Archive (Complete)

ABOUT US \| CONTACT \| ADVERTISE \| SUBSCRIBE \| SOURCE CODE \| NEWSLETTERS \| RESOURCES \| BLOGS \| PODCASTS \| GO PARALLEL