Ruby Conf 2014: Opening Keynote
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 65 | |
| 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 | 10.5446/37622 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Producer |
Content Metadata
| Subject Area | |
| Genre |
Ruby Conference 201429 / 65
2
3
4
6
9
11
14
17
18
19
20
25
27
29
30
32
34
35
39
40
46
47
50
53
55
56
58
61
63
00:00
Computer programmingKey (cryptography)Type theoryShared memoryLecture/Conference
00:51
Software developerVirtual machineThread (computing)Software developerFormal languageElectric generatorVirtual machineComputer programmingCodierung <Programmierung>Abstract syntax treeThread (computing)Presentation of a groupSpeicherbereinigungInterpreter (computing)Java appletSoftware frameworkProgramming languageRevision controlMachine visionData conversionResultantVariable (mathematics)Frame problemSystem callGame theoryBuffer overflowBitProcess (computing)Local ringFamily1 (number)TelecommunicationGodCountingRight anglePower (physics)Object (grammar)Metropolitan area networkAddress spaceCoefficient of determinationLine (geometry)Lecture/Conference
06:57
Parameter (computer programming)Lambda calculusSymbol tableDivision (mathematics)Execution unitTrailGame theoryImplementationImplementationLambda calculusSoftware frameworkParameter (computer programming)Type theoryFormal languageHydraulic jumpBit rateDifferent (Kate Ryan album)Symbol tableWritingPresentation of a groupComputer configurationObject (grammar)Revision controlFluid staticsPower (physics)MultiplicationReal numberLocal ringVariable (mathematics)Rational numberRight angleRaster graphicsDecision theoryLevel (video gaming)Multiplication signDreizehnException handlingComplex (psychology)Order (biology)Game theoryLine (geometry)Arithmetic meanMixed realityCASE <Informatik>Observational studyOffice suiteDivision (mathematics)Virtual machinePhysical lawSystem callActive contour modelDependent and independent variablesOnline helpStorage area networkLecture/Conference
13:04
Execution unitConcurrency (computer science)Just-in-Time-CompilerPauli exclusion principleFunction (mathematics)CompilerAerodynamicsMathematical analysisSoftware testingMultiplication signComputer configurationType theoryForm (programming)String (computer science)Formal languageConcurrency (computer science)Core dumpFluid staticsOcean currentFunctional (mathematics)Bit ratePoint (geometry)GoogolCrash (computing)Musical ensembleCovering spaceParameter (computer programming)SpeicherbereinigungObservational studyGodGraphics tabletSoftware testingPower (physics)PiElectronic mailing listConsistencyContext awarenessMessage passingComputer programmingSound effectExclusive orClient (computing)Metropolitan area networkStorage area networkProcess (computing)WritingDivisorCASE <Informatik>Similarity (geometry)Compact spaceMathematical analysisSoftware bugError messageNumberJust-in-Time-CompilerStreaming mediaDynamical systemFiber (mathematics)Parallel portSystem callData compressionLecture/Conference
22:52
Information overloadType theoryComputer configurationFluid statics
23:52
AerodynamicsCodeObject (grammar)Operator (mathematics)Computer configurationSystem callType theoryCovering spaceBit rateLibrary (computing)Computer programmingSimilarity (geometry)Formal languageClosed setProgramming languageCASE <Informatik>Fraction (mathematics)CodeCross-correlationFluid staticsLecture/Conference
26:16
CodeTwin primeTypinferenzIntegerLink (knot theory)Drill commandsData typeSocial classSubsetFormal languageCompilerObject (grammar)Operator (mathematics)InferenceComputer programmingFundamental theorem of algebraParameter (computer programming)Type theoryElectronic signatureMereologyGoodness of fitSocial classAreaSign (mathematics)Observational studyInformationSubsetCollisionFormal languageBitCompilation albumCompilerOvalMathematicsNatural numberProgramming languageString (computer science)NeuroinformatikDeclarative programmingNatural languageExpressionMultiplication signMassMessage passingNumberData miningWeightTraffic reportingMetaprogrammierungSet (mathematics)TypinferenzVariable (mathematics)Compact spaceIntegerLetterpress printingCodeFluid staticsRun time (program lifecycle phase)Lecture/Conference
32:19
InformationIntegrated development environmentTelecommunicationCompilerFormal languageAerodynamicsFluid staticsDynamical systemFunctional programmingType theoryProgramming languageFormal languageComputer programmingFehlererkennungIntegrated development environmentSoftware bugOcean currentOnline helpCompilerFluid staticsObject (grammar)INTEGRALLogic gateProgrammer (hardware)TelecommunicationConcurrency (computer science)Multiplication signException handlingInformationNatural numberSystem callVariable (mathematics)Physical systemHacker (term)WordForm (programming)Observational studyTask (computing)Arithmetic meanCross-correlationPoint (geometry)Right angleCuboidLine (geometry)CausalityLecture/Conference
38:22
SoftwareEvent horizonVideoconferencing
Transcript: English(auto-generated)
00:19
This is the keynote, the first keynote for myself.
00:25
Every year, I feel weird. I am a programmer, not a presenter, but the last 20 years, the things have been changed a lot. So this year, I'm talking about the feeding a shark,
00:40
feeding sharks or classroom types. Oasis community is kind of like a shark. Yeah, in Jaws. Just because, you know,
01:02
Oasis community, especially developers community, we have to move forward or die. Just because, if you lose interest, we will go away to somewhere else more interesting. Yet, the Ruby was pretty interesting back then,
01:21
but it's quite boring, so let's move on to another programming language, framework, technology, say, whatever, no JS, JavaScript. But we have to feed the community. So we have to attract the community somehow,
01:43
by showing how to earn money, where else? Or by enlightening people, by philosophy behind the language design, or maybe framework design or something like that, or by showing the future,
02:02
the possible future on the technology. So I give many presentation in past RubyConf. Like, I give presentation about the future, basically. So in the RubyConf 2001,
02:23
that held in Tampa, Florida, it was the first RubyConf ever, and it was, I don't know, 30-something people were there. Do you remember? 30, 35? 35. 35 people attended the first RubyConf.
02:40
Yeah, some of them are still attending this conference. So I give a presentation about the future of Ruby. There was a virtual machine. So back in 2001, the Ruby interpreter is pretty naive interpreter of the abstract syntax tree. And introducing the virtual machine to the language
03:03
will boost the performance of the language, so I give the future vision of the introducing virtual machine to the language. Then it became true in 2007 by the Ruby 1.9,
03:24
due to the work of Koichi Sasada. And in the next year, RubyConf 2002 in Seattle. So I give some vision of the future, the M17N and the native thread,
03:42
and the generation garbage collector. So M17N stands for multilingualization. Did I pronounce correctly? Multilingualization. So the ability to handle the many encodings from the language everywhere.
04:03
So back then, Unicode was not that popular, so we have a lot of lot of encodings nationwide. So the people in the United States has ASCII, that's okay, English is so lucky for language.
04:23
And the European people has a Latin one, and the people in Asian country has kind of like a nightmare. We have so many characters. So back in Japan, we have to define 6,000 characters,
04:43
including the Chinese characters and the Japanese characters. So the 8-bit is too small. So back in Japan, we had at least three or maybe four character encoding
05:02
to represent the Japanese characters. And the Chinese has several ones, the Taiwanese has the others, and there are so many character encodings back, and still they are. So the many programming languages like Java took Unicode
05:27
to represent every characters. But the very early version of Unicode only has 16 bits, so that means 60,000 characters. But the world is wide,
05:45
so everyone wants to add their own characters into Unicode, so they overflowed. Now we have, I don't know, 100,000 characters or maybe more characters in Unicode right now,
06:01
so the 16-bit was too small. So we like to support many encoding natively without any conversion to and from Unicode. And then I would like to address the native threads
06:23
and the generational garbage collector. These technology became true in these ages. Multi-lingualization in 2007, a native thread in 2007, and a generational garbage collector in last year.
06:41
The next year, RubyConf 2003 held in Austin, Texas. So this year, I gave a lot of crazy ideas, and then local variable scopes and the multiple assignments, if I meant keyword arguments, method combinations,
07:01
selector namespace, and optional static types. And some of them became true, and the local variable scope was, and the local variable scope ideas and the optional static types are abundant, gave up, I gave up. But the other ideas, multiple assignments,
07:21
refinement in 1.9, keyword arguments in 2.0, method combination, which is done by a module prepend, became true in 2007. And selector namespace, which now we call refinement,
07:40
is in the language in 2013. And the next year, the RubyConf 2004 held in Washington, D.C., and I missed that one. The only RubyConf I missed, I regretfully. But my youngest daughter was born that year,
08:03
I couldn't make it. Instead, Brad Cox, the designer of the object you see, gave a keynote at the Ruby conference. And Koichi gave his first talk on the world. Next year, RubyConf 2005, in San Diego,
08:24
I presented the Stubby lambda and real multi-volume and the traits. And I remember almost all member, all attendees,
08:43
act against Stubby lambda. It was too ugly or something like that. But 10 years later, so many people used Stubby lambda, instead of the L-A-M-B-D-A. So, yeah, I was right.
09:04
I was right in language design. So the Stubby lambda became true in 1.9, 2007, and then the other two ideas, I just gave up, given up.
09:20
RubyConf 2006, in Denver. In this year, I gave a presentation about the bike shed argument encouraged. But we discussed to nourish new ideas about the language design and new frameworks.
09:42
So in most of the cases, the bike shed ideas are considered bad. But in some cases, like a bike shed argument, ideas are encouraged, kind of like a brainstorming. So I didn't present any new ideas that year.
10:08
And RubyConf 2007, in Charlotte, North Carolina. So in this year, Ruby 1.9 was introduced and then, but that was a huge jump from 1.8.
10:25
So I gave a introduction about the language difference and the improvement and the performance gain or something like that. So I didn't give a presentation about any new ideas.
10:42
So RubyConf 2008, in Poland, Poland in Oregon, right? The philosophy is explained. The philosophy behind Ruby language design was explained, so I didn't give you no idea. RubyConf 2009, in San Francisco,
11:03
the power of DSL explained, so no new idea was given. At the same time, the RubyKaigi 2009 in Tokyo, I gave a whole lot of new ideas, like a complex literals, the rational literals, true division,
11:22
and bitmap marking, and the symbols you see. And most of them, except true division, was introduced to the language later. RubyConf 2010, in New Orleans, so I gave new ideas like a trace and the module prepend,
11:41
the refinements, and the write version machine, which later became mruby. So these ideas, except mix, which is kind of like a trait, was introduced to the language. Then in the years of RubyConf 2001 to 2013,
12:02
last year, held in New Orleans, Denver, and Miami, and boy, Miami was good. So there's new ideas. After all, some may become true, some may not. The false rate was a 32%.
12:27
So I classified conferences like this, so since the first one to 2005 in San Diego, I give a presentation about exciting but uncertain new ideas.
12:41
Then the year 2006 to 2008, nothing new but philosophy. And the year 2009 to 2013 was improving implementation. So there are new ideas, but they're so near-sighted, so improving the current implementation of the language.
13:01
So there's no big deal. So we need to fuel to move on. So it's about time to start talking about Ruby 3.0.
13:24
By the way, we are going to release Ruby 2.2 in coming Christmas. We will add some new improvement to the language, still keeping the compatibility.
13:41
So the Ruby 2.2 will be a drop-in replacement to Ruby 2.1 for most of the cases. So the session that Koichi Sasada will give him,
14:02
they'll talk about the garbage collectors, but he will cover some aspect of the new things in Ruby 2.2, so if you are interested in the new things in Ruby 2.2, so go to his session. So I'm gonna introduce the things in Ruby 3.0 to come.
14:23
That may happen in the next 10 years. So maybe we will see Ruby 3.0 in 10 years later, or maybe next year, I don't know. I have no idea. So the huge topic of the Ruby 3.0 will be the concurrency
14:41
and JIT and static typing. I'm not going to talk about concurrency, just because I have no specific idea about having concurrency, but I know that everyone complains about the giant global interpreted lock.
15:01
So we, core team, is talking about, discuss about introducing the true concurrency, I mean the true parallelism in Ruby, the CRuby, so I will try to make something neat in the near future.
15:22
But I have no concrete idea yet. So JIT, we might use LLVM, or we might use some other technologies, but the JIT will boost the performance of the Ruby by the factor of two to four,
15:41
so not that great, but Ruby twice faster, Ruby two times faster is good for you. And static typing, static typing?
16:03
But all new kids in the street, Scala, TypeScript, Dart, Go, the new coming language in the 21st century, the old new language has the static typing. So the people come to see me to talk about the typing,
16:25
especially optional static typing. So JavaScript can have the type with the form of the TypeScript, or maybe the ECMAScript 6, so why not Ruby? Well, some people might say, the Go has some kind of static typing
16:40
with the form of dark typing, so why not Ruby, or something like that? So it's kind of like a crash of type. So we had some kind of the proposal in the bug list, our feature list, the number 9,999,
17:02
by Davide D'Agostino, I'm sorry. It's a proposal about the type annotations, like this, so connect has a stream and a client, then it read through the fiber or something like that,
17:22
and then Python, yeah, our fiber, the Python enhancement proposal, 30,107, which is a function annotations, like this. So it's kind of similar.
17:42
And interestingly, Python does not check types, even with the type annotations. It's kind of like documentation, quite interesting ideas. And that, from Google, it works like that, so they can declare types,
18:00
but it doesn't complain about the wrong type. What is static typing? And then the Python people are also working on something named mypy, which is the optional static type checker. So the benefit, what is the benefit of static typing?
18:22
So I classified in threefold, the performance and the compile time check and documentation. Performance, but no one complains for faster Ruby, so by adding some kind of the optional static typing, if the Ruby learns faster,
18:40
so very few people will complain. But do we really need static typing for speed? So JavaScript V8 is quite fast, and LuaJIT is extremely fast. And that both languages, JavaScript and Lua,
19:00
dynamic type, no static typing. So if they are so fast by the technology, like JIT or specialization or some other technologies, so why do we need static typing? So we can compress performance with dynamic type language,
19:20
so we don't need static type for speed. But the compile time check is very important, just because how many times you find some silly bugs of the type error, with type errors, so when you forget tests.
19:41
But the static analysis is pretty good, so the compile time checks can find many errors without the program execution. So it's quite nice to refactoring,
20:00
so you can be sure, so you can be safely refactor things. So when you change the name of the method, you have to change every occurrence of the method calls, but you might forget some of them.
20:23
So it increased the test coverage. But the static typing is less flexible. It's against dark typing. So the dark typing is very crucial, very important in the Ruby language,
20:43
so it's quite sad to lose them. So about documentation, so much better than comments. So we often use comment to, I know the value or type that method requires.
21:01
But we sometimes forget to update the comment when we add arguments, or when we change the type of the argument. So for consistency's sake, so the static typing is much better than comments. So no contradiction, no investigation,
21:22
no investigating judetio, you don't have to read through the method to find out the type or requirement for the argument. So that is the PIP 3107, the intention.
21:40
So Python people use types as documentation. But there are bad side of the static typing. As I said, dark typing being option on dry,
22:01
so dark typing, the static typing is against dark typing. So you declare that you really need strings here, so you can only call that method with the argument string.
22:21
But if you want to call it with a string IO, or maybe the other some compatible types, which behaves like strings, but which is not really a string. So that is dark typing.
22:41
But if you declare the argument as a string, so the something which is not string cannot be called. And we had a guy named Giriku, and who created some kind of optional static typing
23:07
back in 2001, which is way old. And he didn't disclose his implementation, but he told us from his experience, so optional static typing,
23:23
he created that to overload methods. But he told us, that is not a good idea. Yeah, he didn't speak much in English, he mostly spoke in Ruby,
23:41
but I really respect his ideas, his opinion, I mean. Option, being optional. So optional typing is only useful since it's 99 coverage, I believe.
24:01
That is like TypeScript. It has the type name, the dynamic, which can hold any type of object. But the most of the cases, the types are defined for methods, libraries, something.
24:22
Only a fraction of the program can be dynamically typed. In that cases, so we can utilize the static typing. But Ruby with 99% option typing is,
24:45
I don't think it's no longer Ruby. So it's quite difficult to make Ruby 99% optional typing. So Ruby without dark typing, were we Ruby?
25:02
So I don't think so. The Ruby should keep being Ruby forever. So the JavaScript and TypeScript are very similar, closed programming languages, but they are still different. So Ruby, there might be a room for the Ruby
25:21
with some kind of the static typing addition, but I don't think it will be a Ruby as a language. So, and then DRIVE. DRIVE stands for don't repeat yourself. So DRIVE principle is kind of like
25:41
avoiding the deprecations. So static typing, as I believe, is against DRIVE principles just because, so we write code and we write the correlation. So for me, writing code, so the vaguely,
26:04
so what this object, except this operation or something like that. So I have the vague idea of types in my mind, so I write down the code to represent that. So the code represents the behavior
26:22
and the code represents the big requirement to the object. So then I have to extract the operations, then I form the type to, if I have to declare.
26:43
So when we already described the type requirements in the code, so why should I write down? So the fundamental idea of Ruby
27:00
is do the computer the things they can do. So I made some ideas named soft typing. The soft typing is the idea was described
27:21
in the paper like this or that. So which is kind of adding, getting some benefit of static typing without adding any declaration in the program?
27:42
So no declaration needed. So it's kind of best effort type checker. So the looking through the program, so extracting the vague idea I have in mind and write down the code, then they guess part of the type inferences,
28:10
which is the soft typing. So for example, so we have assignment A equal one, which assigns the integer value one
28:22
to the variable A. So the type of A is integer. So it's quite easy and done by the most type inference programming languages. But this is a little bit more complex. So the define method foo that takes argument x,
28:43
then the print x and then call to int. That means the argument of the foo method requires to int method inside. So with that knowledge, so calling foo with one
29:02
is okay, just because one has the to int method. But the calling foo with the strings is not good just because the string does not have to int method.
29:21
So this kind of inference, having this kind of inference globally can checks types over time. Of the most of the Ruby program, without adding any type of correlation, without hindering duck typing.
29:42
So type is, in soft typing, type is represented by the set of methods, which is the name of the method and the number and the types of the arguments. And then some types can be represented by class or module, but it means a set of methods.
30:09
So if a variable is typed as a class, say integer, but any object that with a signature
30:27
of integer can be assigned to that variable. So it's enables the compact static comp check of types and it detects more errors.
30:42
And it will be some kind of the best effort type checker. And then the target will be the subset of the Ruby programming language. By restricting some kind of the dynamic nature of the language. For example, the require with variables
31:02
or expression will be restricted, just because by adding arbitrary require runtime with that would hinder that kind of global type check. Or define method with variables will be restricted.
31:25
Well, method missing. So with these kind of the soft typing, these say meta programming will be narrowed.
31:43
And for documentation with soft typing, so unlike other programming language, so you don't tell compiler types. The compiler will get you intention and report back to you. So you write down the program, then you run the program through the compiler.
32:05
So the compiler will tell you, okay this variable, I guessed your intention to this variable is this and this. So is this right or wrong or something? Or maybe you generate the information
32:23
for the documentation or IDE. So without writing any documentation, you can't understand what is expected as the types. So the future compiler will tell you
32:41
what is your intention. So your future compiler somehow reads through your mind, so tell you what your intention. So it's kind of like a two way communication between the compiler and you. So right now, you write the program
33:02
and the compiler will tell you some kind of syntax error, then execution systems will raise you some kind of exception about the dynamic nature. So in the future, you can communicate with the compiler about your intention. So I think your intention contradicts somehow,
33:25
so you have to fix this or fix that. Or maybe, so the IDE will tell you, you can't call this method and this method, this method for this variable. So without any information, type information,
33:45
type the correlation from you. So the compiler will much smarter in the future. So the soft typing means that two languages in one. So statically soft type language
34:01
and then dynamical type language as current Ruby is. So when soft type typing is not applicable, like your program is so dynamic, so you cannot apply soft typing. So the soft typing will not find any bugs, but it means just four bugs
34:22
to the dynamic type in current Ruby. So you will not have benefit of soft typing, but you still have the benefit of Ruby itself. But if you write down in the soft type style
34:45
of the soft type applicable, so you can get the benefit of the static type checks. So it will be strongly encouraged in the former.
35:03
So this kind of the soft typing will come first in the form of the static analyzer, but I think we need some help from the committee
35:22
just because I just met through the paper, the soft typing paper, and it is quite different. The paper was written on the language like a scheme, like the procedure, somewhat functional programming language, but soft typing on top of the object oriented
35:42
programming language is so different. So we have to discuss and consider new ideas and implement them in the future. So we have to work on, that would take years, but I believe it will benefit the language
36:03
and it will benefit the community as well. For quicker error detection or for better ID integration. So this is just an idea. So just like the prior keynotes,
36:21
this idea might be given up, but this is the food for thought. We considered that this is as a food for thought. So we opened up the gate to discussion for Ruby 2.0.
36:43
These ideas may or may not happen in the future, but that's okay, that's okay. The importance is think seriously about the future. Think seriously how can we help ourselves to be better programmer, more efficient,
37:02
or more say money making. There should be room to improve the language. There should be room to improve ourselves as a better programmer, efficient programmer.
37:22
So let's discuss about the future. It's about the time to start new things. That leads us to Ruby 3.0. So I believe future is bright. So we will promise we will feed you the interesting,
37:45
like crazy ideas like soft typing or concurrency or making Ruby faster or anything like that. So let's enjoy programming. So the Ruby makes us happier, being happier.
38:00
So the keep Ruby works for us to make us happier. So prepare for the future, happy hacking, thank you.
Recommendations
Series of 65 media