We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Keynote - Living in the Fantasy Land

00:00

Formal Metadata

Title
Keynote - Living in the Fantasy Land
Title of Series
Number of Parts
50
Author
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language
Producer
Production PlaceMiami Beach, Florida

Content Metadata

Subject Area
Genre
Process (computing)Goodness of fitTask (computing)Presentation of a groupComputer programmingFamilyFormal languageComputer animation
Right angleEscape characterHand fanComputer animation
SoftwareEnterprise architecturePhysicsCodeBoss CorporationStrategy gameFaktorenanalyseLine (geometry)NumberAxiom of choiceSoftwareStrategy gameEnterprise architectureAbstractionSoftware developerMathematical analysisCodeClient (computing)Latent heatBuildingProjective planeDivisorDecision theorySoftware bugNatural languageProgramming languageTranslation (relic)Process (computing)Multiplication signRoyal NavyComputer programmingParameter (computer programming)Forcing (mathematics)Object (grammar)Conservation lawGoodness of fitComplex (psychology)Observational studyBoss CorporationDot productWater vaporOrder (biology)Field (computer science)Coefficient of determinationConcordance (publishing)Product (business)Arithmetic mean
AlgorithmStrategy gamePhysical systemSoftwareComputerOpen sourceCollaborationismGodComa BerenicesDisk read-and-write headSummierbarkeitAlgorithmSoftwareStrategy gamePower (physics)Software developerNeuroinformatikPhysical systemConnected spaceCodePosition operatorSource codeOpen sourceOperating systemConservation lawRevision controlCloud computingReal numberFormal languageMainframe computerData recoveryGoodness of fitCoefficient of determinationPhysical lawWeightWindowOvalThomas BayesObservational studyEmbedded systemInternetworkingDot productCellular automatonComputer animation
CollaborationismCoding theoryPower (physics)Data managementObject (grammar)Universe (mathematics)Error messageEmailEnterprise architectureNatural languageCodeSoftwareProgramming languageGame theoryCorrespondence (mathematics)Physical systemFreewarePerspective (visual)Connected spaceInternetworkingLatent heatTerm (mathematics)Text editorSpeicherbereinigungClient (computing)Power (physics)CASE <Informatik>Computer programmingProgrammer (hardware)Operator (mathematics)Open sourceState of matterComputer hardwareExistential quantificationGodStudent's t-testElectronic mailing listVideo GenieMassCoefficient of determinationDependent and independent variablesMiniDiscBitInterpreter (computing)Computer fontMathematicsSource codeFormal language
Data managementObject (grammar)Formal languageAdditionComputer programmingVideo gameOperator (mathematics)GodOpen sourceSpeicherbereinigungSoftwareBookmark (World Wide Web)Message passingFormal languageKey (cryptography)Programmer (hardware)FrequencyFault-tolerant systemLecture/ConferenceComputer animation
MathematicsOpen sourceProgrammer (hardware)SpeicherbereinigungMereologyWritingResultantInformationMathematicsPresentation of a groupKey (cryptography)SoftwareSoftware developerWeightProcess (computing)TwitterCodierung <Programmierung>BlogGroup actionGodComputer programmingYouTubeDiscounts and allowancesRight angleMultiplication signSoftware bugSource code
Transcript: English(auto-generated)
Thank you for coming. The RubyConf is always great, and the keynotes make me depressed.
You know, I'm a programmer, I'm a language designer, so, you know, my main task should
be designing language, great language. I admit that I did great things, that I, you know, that influenced so many people all around the world, including you guys, so I'm pretty happy with it, but still, you know, I'm not
really a great presenter, nor, you know, a guy, I'm very, no, not really good at English, so well, that always makes me nervous.
Anyway, today, I'm going to talk about Fantasyland, or this way, okay, Fantasyland. That is a place being away from reality, where the unicorn lives.
So in Japanese, it's called Genji Tohi, which is escaping from reality. So my dictionary says that is escapism, is it the correct word? So for example, so the starting cleanup right before the deadline is kind of like
escapism, yeah, starting debugging mRuby right before the keynote is escapism. That's what I did. So today, I'm going to talk about, oh, excuse me, two fantasy lands.
The first one is kind of like a dystopia. In 1919, I graduated from university. I feel old. I was hired by a software development company, which did some kind of enterprise software,
and in that age, the software development is totally different from now. So we had some kind of three-year projects or something from the huge company or huge
government department, so we had some kind of analysis for months or even years. Then we wrote some kind of very detailed documentation, abstract documentation, the detailed documentation. Then we code, which is the translation from natural language to computer language.
So the process was driven by waterfall process, so the company's decision was very, very, very conservative. So at that time, I felt something was wrong, but I couldn't explain why.
Just because, you know, it was so natural. So everyone was doing that way in software development back then. So I couldn't explain why. Everyone was doing that. It's quite difficult to tell what is wrong when everyone was doing those things, right?
So yeah, I couldn't imagine what was right and what was wrong. So after more than 20 years of experience, I was a pretty experienced programmer, maybe. I now understand.
I now understand what was wrong. We were wrong in software development that that depends on some false assumptions. So we were depending on such false assumptions. Assumption number one, we know what we make.
Back then, we believed we are knowing what we are going to make. In reality, we don't know what software is. So software does not have any physical entity, so it does not really by physical law.
So it can be very, very easily complex. So for example, if I were a building architect, so I design a building like this hotel.
So we need to think about, for example, about the weather or the strength of the concrete or iron, something, the building materials. So then the strength of the building itself can be calculated by physically, easily simulated.
But when we are starting developing software, it is quite easy. Like a Hello World, that's quite easy. There's no room to bag. But the software is getting bigger and bigger.
So it's quite difficult to understand, say, 10,000 lines of code. But nowadays, software is so huge. Like if I had a Prius here, it is an automobile, but it has tons of lines of code,
maybe hundreds of thousands of code, maybe millions of code. So it's quite, as a software developer, it's quite difficult, you can imagine how difficult to ensure no bugs in the millions of lines of code.
Yeah, I'm sure I cannot do that. So the software can be most complex creation, maybe. And no document but code can explain the detail.
So we believed, we knew what we are going to make, but in reality, we didn't. False assumption number two, which is we know what we want. In reality, it's quite difficult to imagine.
Like, you know, I, in a waterfall age, I write a specification, and I give that specification to our client. Then client said, okay. Then we started development. The few weeks, few months, few years later, so the software was finished.
Then I brought it, we brought it to the client. Then, can you imagine what client said? It's not what I wanted. But they said, yes, they said okay.
But afterwards, they said this is not what I wanted. Even say, even I admit I said okay. But, you know, I couldn't, we couldn't imagine what the software appears in reality.
So, like a stupid bosses, stupid bosses, stupid clients. And yeah, I complained a lot. I happened pretty so often back then. But one day, I asked my colleague to create some kind of software.
At that time, I was so busy, so I explained what I want to my colleague. Then he created the software, then back to me, and I said, this is not what I wanted. Stupid me.
I said, I don't know what we should make to maximize business value. So, we couldn't know, we couldn't understand what is going to bring you success. So, we are stupid too.
So, false assumption number three, which is the situation will not be changed. In reality, we don't know what, we don't know the future. So, we're not profits, we have wrong forecasts. So, we have, yeah, in this technology field, we have a lot of, okay, next,
we're going to have this technology, we're going to have this tool, going to be conquered world, the most forecast would be wrong. So, let's face it, we don't know anything.
Twenty years ago, we should have admitted our ignorance, but we couldn't. Instead, we ignored our ignorance. So, when we knew little, we have very few choices. So, choices number one is a conservative strategy.
Learn from the past. So, this is very good strategy, and the politicians often take conservatism. But it is pretty good unless factors don't change.
Unfortunately, not in the IT industry. So, we change a lot. The situation will change drastically, day by day. So, in our industry, so, it's kind of like the quote from Red Queen in Alice of Wonderland.
Now, here you see, it take all the running you can do to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that. It's our situation. Yeah, it probably, yeah, it's our situation.
We have to run as fast as we can to be in the same place. So, strategy number two is ostrich algorithm.
Do you know ostrich algorithm? So, when the sandstorm come, ostrich dig in their heads into the sand and wait until the sandstorm end. So, the ostrich strategy is ignore everything and wait.
This is good strategy. Only when situation will recover. So, sandstorms will end. So, we will have the clear skies and we can enjoy our climate again, with our gang.
But, you know, in our industry, that's not what happen. The weird situation will change and change and change and not recover. So, we cannot go back to the mainframes.
We cannot go back to the 8-bit CPUs or something. So, we must keep going forward. So, the ostrich algorithm is very good strategy in the past, when the situation will recover.
So, this strategy, this algorithm is written in our instinct. So, we are so easy to choose that strategy. But, otherwise, when the situation will not recover, it's kind of like living in the fantasy land.
So, going forward with false assumption is kind of like living in the fantasy land. So, ignoring reality. So, we had two strategies. Conservative strategy and ostrich algorithm.
Which strategy do we take? Neither of them are good. 20 years ago, our goal was to create the software somehow. Having computerized systems is the power. So, it is so powerful.
The computer itself is so powerful comparing to the human computation. So, it's the great power. So, software development was pretty expensive back then. The computers were expensive. The network connection was expensive. The failure will never be allowed in that age.
So, they needed to optimize not to fail at the cost of satisfaction. So, I don't care if you satisfied our software or not. But, I can bring you some kind of the power of computers with the computerized system.
So, everyone was dreaming. We believed that the only way to create software. We tried hard to believe that was the only way. But, 20 years later, now, our goal is not just to create the software.
Our goal is to create the great software. You know, nowadays, everyone has a computer. Everyone uses software. So, mere position is no longer the power. Everyone has a computer. Everyone has software. So, we are the same. So, to differentiate, to have the power over others, we need to create great software.
We need great software. We got to create great software. So, but how? Of course we don't know. We admit false assumptions.
But, admit our ignorance. But, there's good news. There's good news. The computer is cheaper. Cloud computing is even cheaper. A network connection is cheaper now. And ubiquitous. Everyone has a net connection. Even in this room.
So, software development is cheaper comparing to 20 something years ago. So, we can be more productive, more abstract. And we now have better tools and a better language. Like Ruby.
And we have a lot of open source software. So, we can rely on that kind of software. We can learn from that software. So, the old days, it is quite difficult to study from the real source code.
You know, if you would like to learn about the operating system. So, you cannot access to the source code of, say, Microsoft Windows.
Or the Solaris. Or some other operating system. But, you can access to Minix. Or the very old version of Unix. But, not the real software. But, nowadays, you can access to the Linux. A whole bunch of Linux code.
You have tons of operating systems that are used in reality. You can use open source software in your system. You can learn from the open source code. So, it's much easier for us to learn.
And to create the great software. And we can now have that collaboration via internet. It's... It changed the game. So, 20 years ago, soon after I graduated this university.
When I was working as a professional programmer in enterprise software. I was prohibited to write email abroad outside of Japan. Only 20 years ago. Not 200 years ago.
When I was a university student, I wrote some kind of free software. So, it was distributed by... It is quite a minor email client on top of the Emacs list. I got mail from some other guys probably in the States.
I don't remember quite. And I tried to reply. Soon after that, I got error mail. Your company did not pay money to the internet connection.
International internet connection, I mean. So, I forwarded that reply to my friend in the university. My university paid that kind of bill. So, he could receive the mail. It was quite awkward corresponding.
He wrote mail to me. Then I cannot respond. So, the friend responds instead of me or something like that. But now we can connect to everyone all over the world. So, we can access Japan, China, Moscow, everywhere.
So, we can now collaborate over the internet. So, that allows us to do some kind of social coding. So, GitHub changed everything. So, these good things bring us the new fantasy land.
The new perspective. So, now we can ignore about the gory detail of the hardware or the underneath operating system for most of the cases.
We can stand on the shoulders of giants. So, we can use the great huge software, operating system, frameworks, language, the tools, editors. So, a lot of things. So, we can do great things with very little effort
comparing to the past. So, we can do greater work than our real ability, real power. So, I think the engineers 20 years ago is not weaker than us, does not stronger us.
They are almost same, the ability as a human engineers. But now we can rely, we can collaborate. We can collaborate over internet. We can collaborate on top of open source software, free software.
So, we can do greater works than our past. But that does not mean we are greater. So, the situation has changed. We can have power. We can have more freedom. We can have more joy in software.
So, I remember that working on the enterprise software was not fun. So, it is quite boring. So, translating human specification in human language into the computer language was so boring.
You know, the specification once said, okay, assign this value to this variable or something like that. So, why these kind of engineers don't write the code by themselves? It was quite boring when I was pretty young.
So, now we can do by ourselves. We can have joy in our program. So, it's kind of like an engineer's heaven. That's what we are. And that's why we are here. But wait.
It's still not real. Reality is as complex as the past. So, who made it in the fantasy land? In reality, we cannot just ignore math. So, we don't need something.
So, just we tend to ignore something throughout. Just forget. But something got to maintain this kind of mess. So, somebody got to work on that kind of mess.
Garbage collectors. No, that's not the garbage collector you imagine. So, that kind of topic, you can go to that. Yeah. Koichi's talk. So, by the term garbage collector, I meant this.
And that we have to rely on this kind of people in our daily life. Even in our programming. Without them, we would have mess. So, welcome back to the reality.
We rely on garbage collectors. So, we better appreciate them. We rely on a lot of garbage collectors. So, who keep the fantasy land? Who created your favorite language?
The garbage collector. Or, who created your favorite gems? Gem creators, raise your hand. You have to appreciate them. Thank you.
Who created your favorite frameworks? Who wrote your favorite books? Book writers, raise your hand.
Who created your favorite open source software? We have tons of open source software in and out of the Ruby community. So, we have to appreciate them. So, appreciation and respect is the key, I believe. The key to the open source community, the key to the moving forward.
So, open source community is kind of like a shark. We need to keep moving forward or die. So, we have to,
and I advise you, keep moving forward. So, you have to run as fast as you can to stay in the same place. And, you have to run twice as fast as that to move forward. So, run fast.
Try often. Fail early. Keep moving forward. Yeah, that is my message. And, in addition, appreciation is not enough. So, we are not created to the gem writers. We are not created to be a language designer.
We are not created to be open source software programmers. So, we became one. So, take that idea.
So, you can come join us. If you are a programmer, that's fine. You are a programmer. You took a great step to create something. You know, the programmer is a creator. So, you create software.
Then, by your creation, the world will be better, I hope. I really, really hope. The world will be better by your creation. You programmers, you create software. And, you make the world better. But, you might still be living in the fantasy land
which is kept by the garbage collectors. And, if you are willing, I'm not forcing you, if you are willing, you can be one of them.
You can be a garbage collector. You don't want? But, this garbage collector is much cleaner. So, be a garbage collector. Take part in keeping the fantasy land. So, this fantasy land,
unlike the first one, which ignores everything. So, this fantasy land we currently enjoy is a result of the effort of the long time, maybe 20, 40, 50 years of the great effort of the garbage collectors.
So, I invite you guys to take part in keeping the fantasy land. And, for example, so you can join the development of CIRUI even in writing some
reporting some issues about trackers or something like that. So, to know what we garbage collectors are doing behind CIRUI, you can check that session.
So, I ask you to create a great fantasy land currently we enjoy and it can be even greater
with your effort. So, you can do many things. So, writing software on top of the RUI on Rails or Snatra or something like that that enriches the RUI community and they communicate with blogs, Twitters and social net encoding
or even participate in the community. Like, the GitHub is our friend. You can do many things. Submit bugs, write documents and, you know, have a presentation in the conference or write a small piece of software
and write a patch and submit a pull request. So many things you can do. But, in any way, create and try to keep a great fantasy land that we enjoy. Change the world. So, I believe
we've changed the world in a better way in the past, say, 10 years. So, a lot of people in this conference in the past will be conferences presenting great things and I expect even more great work
will be introduced in these sessions in this conference. So, do not be just a listener. Do not be a passive receiver of information.
So, you hear something in this conference. You learn something. Take action. So, change the world. So, this is the key of the open source community and this is the key
of the Ruby community. So, I know myself. I'm not a great programmer. especially the Ruby committers, my colleague knows I'm not a great programmer. I create so many bugs.
But, still, I could I did a great job that influenced the world and I respect myself
by changing the world better. So, I believe you can do that too in some ways. You can do it. So, change the world. Thank you.