the Power and Philosophy of Ruby For your information, this talk will explain the principles and the philosophy behind Ruby's design. I will not teach you anything about the detail of the Ruby language. For that purpose, other programs are available here in the open source convention. If you miss Dave Thomas' "Ruby in a Day" tutorial, that's too bad. I missed it too. But we still have several programs about Ruby. It is a Ruby day today here in OSCON. Today, I'm going to talk about the Power and Philosophy of Ruby, or how to create babel-17. %%%%%%% Men are created unequal In 1999, Larry Wall gave a presentation at Perl/Ruby Conference held in Kyoto before Japanese audience. His presentation was in English. And an interpreter was hired. He talked about "soon comming" Perl6 then. That's because he doesn't speak Japanese, although he said he had studied for several weeks. And still he does. I was surprised last night how good he was. I think he can give his presentation in Japanese if he wants. And Larry gave his presentation with an interpreter, because most Japanese don't understand English very well. And finally because he was important enough to hire an interpreter. %%%%%%% But now, I have to stand before you. No interpreter. Poor English. Because I speak English And Because most non Japanese don't understand Japanese. Does anyone here understand Japanese? こんにちは。げんきですか。どもありがと。 And finally because Japanese-English interpreter is too expensive. You have to endure my poor English, just because English speakers are so lucky. I need to suffer just because I born in Japan. Life is unfair. I hate to speak in English. It makes me feel like I'm stupid. Maybe I am, though. %%%%%%% More than 4,000 years ago, when the tower was fallen, languages were introduced on the Earth. It is the source of my suffer. But we can compare languages. And by comparing languages, we can learn a lot. %%%%%%% For example, I will show you comparison of two languages I know, English and Japanese. They have totally different syntax, and writing system. Japanese has rich way to express respect. We have levels of expression to show honor. And Japanese has thousands of characters. Most of them are ideograms that express meaning, inherited from China. They are great invention. %%%%%%% And we need no icons. For example, the character here mean "mountain". This is simple one. You might see the figure of a mountain in the glyph. This one is little bit harder. This mean "love". This is the power of ideograms. Can you imagine designing an icon for an abstract concept like "love", without causing confusion? It's almost impossible. This one is insane. Even I can't write this one. This means depression. A lesson learned here would be "ideograms are useful, it can even be a shelter from Anglo-centric cultural invasion. they make the language too hard to learn for non Japanese". Larry had a good try though. %%%%%%% After a small lesson, let us examine the purpose of languages. Men use languages to describe the facts. And to Express thoughts and feeling. And even to think. This is important. Men think in the language. Thus languages are not only tools to communicate, but also tools to think. %%%%%%% For example, I, personally, think in Japanese, even now, at least partially. So that, every conversation is translated automagically and stored in my brain in Japanese, no matter what language is used. %%%%%%% Thus, in my brain, they appear like this. 私は日本語で考える どの言語で会話しても自動的に翻訳されて日本語で私の脳に記憶される。 %%%%%%% But even though I think in Japanese, I am still influenced by the language I'm speaking. I feel like I have different personality when I speak in English, and when I speak in Japanese. When I use English, I feel like I am more logical, but blunt. When I use Japanese, I feel like I speak a lot more, and tend to be more emotional. %%%%%%% The influence from the language reminds me of a Science Fiction book, titled "Babel-17". A book I read while I was young. %%%%%%% Babel-17 is an artificial language, which is considered as an cryptogram first, and found out to be a very logical, concise, and useful language. And it helps people to think better, and sometimes enlightens its users. And it even brainwashes people speaking in it. It is an ultimate goal of language designers, sort of. %%%%%%% Thus I define a first theorem in this talk, that is: Languages influence human thought, more than you think. Because they are tools to think. Because they are result of the activity deep inside of your brain. %%%%%%% well, probably I talked too much about natural languages. I was invited here to the OSCON to speak about Ruby. So let's talk about programming languages. The question is: Do programming languages influence human thoughts? In other words, can the first theorem be applied to the programming languages? How do you think? I believe they do. %%%%%%% When a good programmer thinks about programs, perhaps he thinks in a programming language. Because Natural languages are too ambiguous. Or, too verbose. Or, too indirect. Programmers' written-down thoughts become programs. Programs sometimes can be an expression of programmers idea, thoughts, and policy. %%%%%%% If programmers think in programming languages, they must influence thoughts as much as natural languages do. By the same mechanism. Whereas "languages" in the theorem #1 include programming languages. %%%%%%% There are some interesting questions left. What is the purpose of programming languages? Do programming languages differ in productivity? What makes programming languages more productive? %%%%%%% What is the purpose of programming languages, anyway? To teach computers what to do. This is original purpose of the programming language. To describe problem to solve. Most importantly, to express programmers thought, in a form of programs. I will revisit other two questions later. %%%%%%% OK, the talk has just entered in to the second part. It's called "How to Create Babel-17". %%%%%%% How can we create a "super language" like Babel-17? that helps our thought that guide us to be better programmers that makes us to enjoy programming but does not brainwash us ;-) We just want to be "influenced". %%%%%%% There are three basic keys among others to create Babel-17, Or keys that I tried to make Ruby like Babel-17. Choosing good names Understanding humanity Embedding hidden messages I will explain these keys one by one. %%%%%%% Key #1: Choosing Good Names Believe it or not, "name" itself is the power. In a native Americans legend, If you know a true name of a thing, you can have mysterious power and control over it. So that they hide their true names, and reveal them only to close relatives. To keep the evil from having power. This is just a myth. But it contains the truth. Think about the design patterns. Most of them are program construct often rediscovered again and again in the history of programming. But when Eric Gamma and others named them, put them into catalog, something has been changed. Now, everyone knows design patterns, uses them. I think it's a part of "name magic". From my experience, if you give a good name for a concept, 80% of the design is done already. And good names are evidence of your understanding of the problem, and you will hardly regret about its design. A good name keeps motivation. A good name encourages us working with it. %%%%%%% For example, There are so many opensource projects. A few survive. Survivors often have short, good project name, like Perl, Ruby, etc. So, we have to care about every name we name. ... Programs, Files, Modules, Classes, Methods, Variables, everything. %%%%%%% Key #2: Understanding Humanity I think this is the most important key to create a good language. I am a MACHINE! He is, but we are not. We often forget the fact, when we design languages, or software. %%%%%%% If you are a machine, there's no need for programming languages, nor user interface. You can talk to the machine directly. ピーガガガー %%%%%%% This is an example. This is my first name, not uncommon name among Japanese men. This is another form of my first name, in binary ASCII code. Perhaps you don't read the latter at a glance. But machines would have no trouble. They can be converted each other by simple translation, simple but bothering to the human. %%%%%%% Bothering because human brain is limited. Men are good at making errors, creation, and imagination. Making error is not really a "good thing" though. On the other hand, men are bad at making copies, routine works, and fast calculation. Machines are incredibly fast in calculation. They are millions of times faster than human brains. %%%%%%% As you know, some languages are more productive than others. Java is more productive than COBOL C++ is more productive than FORTRAN Perl is more productive than shells If we measure "productive" by human costs. Of course, if we measure "productive" by the amount of calculation, we might get the different result. But,... %%%%%%% We have Moore's law, that is the number of transistors per square inch on integrated circuits doubles every 18 months That means the power of machines doubles every 18 months Amazing, isn't it? but it's been true for 30 years. Compare power, size and price of computers of 10 years ago, 30 years ago, and 50 years ago. We have plenty of power now. We can "overspend" machines' power for most cases. %%%%%%% Let's look back the history of programming, and programming languages. Wired Logic - it's not really programming. Toggle Switches - No power was used for human. Very stressful for human, except for a few. That's why programming language was invented. Assembler - Mnemonic kept us away from tedious translation. Still stressful. FORTRAN - Formula Translator, incredible step in the past. you can tell formulas directly to the computers. You could stay abstract while computer did the compilation. At the first time in the history of computers, they started to care about men. BASIC - Beginners All-purpose Symbolic Instruction Code. It tried to make programming easy enough for non experts. PASCAL - High level structured programming language. Machines don't care whether programs are structured or not. Structured programming is for human. C - A more pragmatic language than Pascal. While Pascal has faded away in practice, C survived, because it was more flexible, and because it's tightly coupled with the popular operating system, UNIX. C++ - It's an object-oriented cousin of the C language. Notice that object-oriented programming is no good for machines. They don't care OO. Dynamic dispatch increase flexibility, reusability at the cost of performance. C++ also proved that how complex a language designed by committee can be. Java - Say it is simplified C++. It shows the power of languages are not by the size of the core. And finally, Ruby - The best language ever, for me, at least. It's designed for me, or for us, the hackers. It does a lot of thing run time. Type check, boundary check, and so on. This means flexibility. And as you know, we have to pay the price for flexibility. In summary, the history of languages is the history of moving toward human, by abusing machines' power. %%%%%%% So that I believe languages must be nice to human. It must focus on human to make them productive, at the price of machine power, by reducing programmers' stress. Stress is the enemy of programmers. %%%%%%% # Programmers' Stress Graph To illustrate the problem, draw imaginary stress graph. This graph shows the level of stress that a programmer feels during programming activity. For example, he found a bug here, and forget something about the language here. This is a function of two inputs, the problem to solve, and the environment, especially programming languages used. %%%%%%% # Programmers' Stress Graph We can compare programming languages by the area surrounded by graph. The area shows integral of stress amount. This area varies language to language. %%%%%%% This is a graph using C++. %%%%%%% This is a graph using Perl. Lower stress, but a several peaks here and there. %%%%%%% This is Lisp. Much lower stress, peaks remain. Macros, CLOS, parentheses. %%%%%%% # Left-out Factor In programming language comparison, total amount of stress is important. We care how much stress we feel during programming. But maximum amount of stress at any point is important too. Because our brains are very limited. They would be broken above certain threshold. %%%%%%% Some even less tolerant. %%%%%%% # Programmers' Stress Graph This is an ideal stress graph. In an ideal case Stress should be caused only by the problem to solve, not by languages. Languages should be designed focusing how much stress they make, in mind. %%%%%%% How can we reduce stress in programming? I think there are principles to follow to reduce it. Principle of Least Surprise Principle of Succinctness Principle of Human Interface %%%%%%% Principle of Least Surprise this is often misunderstood. it's not "principle of no surprise". "surprise" means "the one in designer's eye". there are good surprises and bad surprises. "least surprise" means "least bad surprise". %%%%%%% What are good surprises They are surprises you feel when you learn new things when you find new good features when your job done faster than you expected when you can have time to go out %%%%%%% Bad surprise are surprises you feel when your problem is harder than you expected when your program won't run when you have to write more code than you should when you suffer inconsistency %%%%%%% Learn from Failures Failure is the source of knowledge When you see repeated errors, you have to do something. You feel stress when you make errors again and again. It means it's against implicit assumption or common sense. Consistency help to form common sense. Creativity is hindered by arbitrary restrictions. Removing restrictions enhances flexibility. %%%%%%% Consistency, flexibility, how about simplicity as you may expect? From my experience, simplicity is not a primary goal. Seeking simplicity in language design does not help much, I think. Because things too simple are difficult. Because things too complex are difficult too. Because human thoughts are not simple. Because programs are essentially complex. Because combination of simple concepts can be complex very easily. %%%%%%% In summary, principle of least surprise is the combination of Principle of fulfilled expectation Principle of pleasant surprise Principle of immersion %%%%%%% Next to the principle of least surprise, here comes the principle of succinctness. We're frustrated when we feel we are wasting time. when we can't focus on problem itself. when we are interrupted. TIME is an important factor. %%%%%%% # Time is Money We can approximate our stress by the time we spent. The quicker we program, the more we can program. The faster we finish our job, the better programmer we can be. As Paul Graham stated, "Succinctness is Power". Place your burden to machine's shoulders %%%%%%% Succinctness is important because you can be 10 times (or even 1000 times) more productive. According to Fred J. Brooks, Programmers generate about same amount of code per day regardless of the language. If this is true, and it does seem to be true, the more succinct the language become, the more productive it would be. Succinctness is important because you write less code, you see less bugs because you see less bugs, you can consider yourself smarter. %%%%%%% The last of three principles, the principle of human interface. Programming languages can be viewed as human to machine interface. The important guidelines for good interface are consistency flexibility succinctness These guidelines can also be derived from the principle of least surprise, and the principle of succinctness. %%%%%%% After understanding humanity, the last key to create Babel-17 is "embedding hidden messages". while "understanding humanity" is the key to make programmers effective, "embedding hidden messages" is the key for languages to influence programmers. As Perl people believe, and as I do too, there should be more than one way to do it, but the language can encourage one by making it comfortable than others. This is hidden message. You don't have to see the messages, since they are hidden. But they penetrate into your brain. %%%%%%% Example #1 Multiple Inheritance (MI) vs Mix-In There's no multiple inheritance in Ruby intentionally, but Mix-in is available instead of multiple inheritance. Mix-in avoids diamond inheritance. Mix-in is simpler, while being as powerful as multiple inheritance. The hidden message here is "multiple inheritance is difficult, not encouraged". %%%%%%% Example #2 Global Variables Unlike Eiffel, global variables are allowed in Ruby. We don't want to restrict people. but you have to put "$" before globals. Too many "$" are ugly, so that globals are implicitly discouraged %%%%%%% Example #3 Bang Methods In Ruby, some "dangerous" methods have "!" in its name, for example "sort!", "reverse!". they might be faster, but you have to care about their side effects. While "sort" returns sorted object without modifying the original, "sort!" sort the elements in place. "!" reminds you of their side effect. you can avoid "!" by using safer version. %%%%%%% OK, slides are almost finish. Let us summarize the talk. Summary #1 We found theorems Languages can influence human thoughts. Above "languages" include programming languages. %%%%%%% Summary #2 Good programming languages help you to program better, think smarter, and finish your job quicker And finally, %%%%%%% while you program to solve your problem, I program your brain to work better. %%%%%%% Thank you %center, size 7 Any questions?