Yukihiro Matsumoto Built Ruby Around a Radical Idea: Programming Should Feel Good.

Yukihiro “Matz” Matsumoto did not begin Ruby because a corporation handed him a market requirement. He began because the programming languages available to him did not feel right. In his own later account, Ruby was “born” on February 23, 1993, during a conversation about creating an object-oriented scripting language. He wanted something practical enough for everyday scripting, but also genuinely object-oriented and pleasant to use.

A language built from dissatisfaction, not a business plan

Matsumoto already knew Perl and Python, but neither matched the language he wanted. He admired scripting for its speed of expression, yet he wanted a cleaner object model and a design in which object orientation was not bolted on afterward. Ruby’s official history says he drew from languages he liked—Perl, Smalltalk, Eiffel, Ada and Lisp—rather than trying to invent every idea from zero. The originality came from how he combined them and what he optimized for.

That optimization target was unusual: the programmer. Matsumoto has repeatedly described his goal as making programmers happy. In a 2003 interview, he argued that programming languages are interfaces between humans and computers, so the human side should matter. He did not pursue simplicity as an absolute. Ruby’s own documentation summarizes one of his recurring ideas: make the language feel natural rather than merely simple, even if the implementation underneath becomes more complex.

Two years before the public release

The first idea did not immediately become a famous language. Matsumoto spent months getting an interpreter running and continued shaping the design in relative obscurity. In his 1999 retrospective on the ruby-talk mailing list, he wrote that Ruby 0.95 was posted to Japanese domestic newsgroups in December 1995. Ruby 1.0 followed in December 1996. For several years, much of the community and documentation remained centered in Japan.

That slow start matters because it is easy to rewrite technology history as a sequence of instant successes. Ruby had no guarantee of global adoption. It was a personal design project that found users gradually. Its syntax was flexible. Everything behaved as an object in a way that felt consistent. Blocks, iterators, garbage collection, exceptions and a rich class system made small programs expressive without preventing the language from growing into larger applications.

“Programmer happiness” became a real engineering constraint

The phrase can sound soft, but it led to concrete design decisions. Matsumoto favored code that stays close to the programmer’s mental model. He valued concise expression, multiple ways to solve a problem, and APIs that make the preferred path comfortable rather than forcing it through rigid rules. In interviews, he also emphasized craftsmanship: reading code, learning other languages, understanding fundamentals and paying attention to interfaces.

Ruby’s philosophy became more visible internationally when the language’s ecosystem expanded, especially through Ruby on Rails and the growth of libraries distributed as gems. The official Ruby site now describes an ecosystem with more than 200,000 gems and credits the community for extending the language far beyond anything one person could build. That point is important: Matsumoto created the language, but Ruby’s durability came from people who built frameworks, libraries, tools, documentation and local communities around it.

A design philosophy that outlived the original problem

Ruby has never been the only answer to software development, nor was that Matsumoto’s ambition. Its deeper contribution is the idea that developer experience is not decoration added after the “real” engineering is finished. Language syntax, error behavior, libraries and conventions shape how people think, how quickly they can turn ideas into working code, and whether programming feels like wrestling with a machine or expressing an intention.

Three decades after the first public releases, Ruby is still maintained, used and debated. New languages have appeared, hardware has changed dramatically, and software development now includes problems that barely existed in 1993. Yet the question behind Ruby remains current: when we design a technical system, whose experience are we optimizing? Matsumoto’s answer was unusually clear. The machine matters, but the person using the machine matters too.

Explore

Stay connected