Turing Theory => Language does not matter, at least in theory. Twitter On Rails. Trouble illustrated by a lolcats photo. There has been a 1000% performance boost since January 2007. What made the difference? MySQL, Solaris and dtrace.
What makes the difference? Not the language itself. It's the attitude of the users. Python users believe in the one true way. Ruby users like diversity. I said that I liked all programming languages, except for a few. As proof, Matz is wearing a python shirt.
People matters. Motivation Matters. Enthusiasm Matters.
Martin Fowler said, "Ruby people are nice." There is a Love/Hate Ratio graph. Ruby, Lisp and Python are the top three. We are using the most beloved language in the world.
Thank you!
Part II What's in 1.9, or What's not in 1.9
We will be releasing 1.9 this Christmas. Unfortunately it is not as stable as we would like. The Grand picture is that 1.8 is the long term stable release, 1.9 introduces major incompatibility and will be the bleeding edge for a time, and 2.0 is the driving force.
1.9 Incompatibility
Some will be severe, and some will be trivial. Severe #1: block arguments are changed. They are local variables only. Blocks are scoped more strictly. Severe #2: string is no longer enumerable. What will be iterated over needs to be specified explicitly (lines, chars, bytes). Severe #3: M17N Unicode is introduced. Character-based indexing ("ABCaio"[0] returns "A" and [3, 1] returns "a"; the preceding "aio" should be read as Japanese Hiragana, because I don't have Japanese support on this computer). Encoding aware comments. You can specify UTF-8 in a special comment at the beginning of your script. You can open files of other encoding formats.
Trivial Incompatibilities: lots of changes, some deprecation, and even more enhancements. Some new features:
- "->" lambdas ("->" is a mutation of the lambda character)
- ".()" to call
- multiple splats in an argument list
- mandatory arguments after optional arguments
- built-in enumerator
- external iterator (e1=[1,2,3,4].each e2=[10,11,4].each loop{p e1.next+e2.next} #prints 11, 13 and 7; loop will catch the end of iterator silently; inherited from the language named Satan?)
Part III Implementations
Realistic alternatives: JRuby, Rubinius, and IronRuby. All are faster than MRI. Finally, we succeeded in getting rid of Matz (It's ok; I'm a designed of languages). Also, we have YARV, the fastest Ruby VM ever. Praise should go to Koichi. In 1.9, Ruby goes on a major memory diet.
Part IV Where are we from? Who are we? Where are going?
Where are we from? Many languages.
Who are we? Rubyists.
Where are going? World domination.
Beware of a bubble economy and the cycle of tragedy (humble start, success, pride, conflict/war, drop to nothing, repeat). We are at success.
Where will we go? Enterprisey. I don't want to, but I can't help it. The suits are surrounding us.
Where will we go? Scalability. It is not a language issue. It is a system issue (data size, access frequency, program size, and number of CPUs).
Q & A
1.8 has green threads. Will 1.9 have native threads, due to the move towards multi-core CPUs? I envision multi-core CPUs will use multiple processes.
No one is working on a shim library for 1.8->1.9 as there was in 1.6->1.8, because of the massive differences.
What will required arguments after optional arguments look like?
def foo(a, b=24, c)
...
end
foo(1,2,3) # a =1, b=2, c=3
foo(1,2) # a=1, b=24, c=2
def bar(a, b=1, c=2, d)
...
end
bar(1,2,3) # a=1, b=2, c=2, d=3You talked about named arguments at another conference. What is the status on that? We didn't have enough time to complete that for Christmas. You will have to wait until 2.0 for that.
Why would you want the ability to have required arguments after optional arguments? It is useful with named arguments. Fill the required arguments at the front of the list, then at the end of the list, and finally fill in the optional arguments.
Are you worried about the niceness scaling as the community grows exponentially? I was worried when the conference went from 60 people to 500 people. I think it has been a success so far. It is kind of like a miracle.
With the external iterator throwing an exception at the end of the loop, is there a stack trace associated with it and is it a performance consideration? Someone from twitter answered that the bug they found had an exception thrown with a 400 level stack trace. If you aren't doing anything crazy with the iterator, you should be fine.
Will the 1.9 byte code be frozen anytime soon? Deferred to Koichi. No.
Will there be an AOT compiler in 1.9? Deferred to Koichi. Not in the Christmas release. Sometime in the future.
What would you like to see in Ruby 3.0? 3.0? Class box. We should be able to isolate our changes to a class in a name space. Looking to do that in 2.0.
Why does method wrapping (aspects) keep getting punted? I feel that the features in Aspect/J is application-level or maybe framework-level. The language should provide primitive features.
How will future pressures of forking be dealt with? Fortunately or unfortunately, Ruby is difficult to implement. People implement lisp once or twice. I implemented Ruby once; never again. Ryan Davis shouts, "How many people have implemented lisp?" 10% of the room raises their hands.
Have you given any thought to passing multiple blocks to a method? I tried several times, but was never successful. It is important to keep the simple syntax that the Ruby block has.
Speaking of crazy syntax, do you like list comprehensions in Haskel? No.
That's all folks.
Disclaimer: I might have misheard any portion of this.
