Sunday, February 24, 2008

Ruby 1.9 -- talk by "Matz" Matsumoto 2/22/08

Matz talks about Ruby 1.9 @ a recent Google talk... I took some notes while watching it via YouTube. You can read the notes, and watch the video below

Ruby 1.9 -- Released on Christmas 2007

1.8 - Stable -- daily use, stable, compatible (1.8.6 latest)
1.9 - Bleeding Edge -- faster, more powerful, done right, but incompatible
2.0 - "Innovation Bait" -- vaporware, Open Source Software should move forward or die, scalability is the Keyword (data size, program size, team size)

Ruby 1.9 incompatibility: some big ones, some small ones.
Big incompatiblity: block params, strings, unicode
block params: local variables only, block scoped
"functional programming people love to abuse the blocks"
ary.each{|$var|...} #=> ERROR}

Non enumerable Strings in 1.9... no longer Strings are enumerable... now you need to specify (no ambiguity anymore):
or similarly:

Ruby 1.9 Unicode is based on Characters... 1.8 was based on Bytes
1.9 supports character encoding
"ABC@#$"[0] # => "A"
"ABC@#$"[3,1] # => "@" (index, num characters)

like Python, accepts character encoding:
# -* coding: UTF-8 -*-
(won't work with UTF-16 yet)
also can specify with file:
open(path, "r:UTF-8") { |f|
...#read all strings in this file as UTF-8 data
Lot of little small incompatibilities with this improvements... most of them trivial

Some Features are Gone in 1.9 (we were warned about these in advance)
- VERSION and friends
- Object#type
- Hash#index
- Symbol#to_int
- Removed Array and Hash #indices, #indexes

Lot of new features (too many to list)

New feature Highlighted:
- Lambda by ->
- Method Invocation by .()
- Enumerators

Lambda by ->
->(x)(x*2).(2) # => 4
->(x=5){x*2}.() # => 10
(Perl does same syntax with the '->')

Chain of Enumerator:{|x, i|
... # can have "with_index" with any method

External Iterator:
e1 = [1,2,3,4].each
e2 = [10,11,4].each
loop {
p +
#prints 11, 13, 7

The New Implementation
YARV -- Yet Another Ruby VM

-Yarv is integrated into the core of 1.9
-History of Ruby.. many people tried to improve performance by creating a virtual machine. So many attempts... very tough job... Matz had a plan for a long time to create a VM... but he couldn't do it, didn't have enough time... he didn't expect much from YARV, because so many people fail... yet YARV is nice. It replaced the official Ruby interpreter.
VM developed by Koichi Sasada, Bytecode interpreter, Optimized for Ruby... Scheme compiler.
-Maximium 50x faster core performance
-x2-10 Faster in benchmark tests
-Improves CORE only (using same library)
- programs do not run 50x faster (b/c they have libraries, classes, garbage collectors, etc)
-about 1.5x faster on average... makes us "comfortable", "fairly fast".. vague perceptions from Matz

Memory Diet for new interpreter
- reduced memory footprint
- showed a comparison for 'rdoc', for instance

What is Ruby Anyway?
- the language (dynamic, flexible, productive)
- the community (nice people!... Martin of the best communities, proud of that)
- the implementations (Ruby has Multiple Implementations... 1.8, 1.9(YARV), JRuby (JVM), IronRuby(.NET), Ruby.NET(CLR, DLR), Rubinius)

Google Restricts languages to Java, Python, C++, JavaScript(Client side)
Steve Yegge, JS on Rails (using modified Rhino, for good reasons)... Matz believes those are fair reasons.

But we have JRuby. Ruby running on JVM... compiles class files... 1.8 compatible... can execute Ruby on Rails... now Runs faster than 1.8... accesses all Java Libraries

Matz hopes Ruby helps all world programmers to be Productive, Enjoy and be Happy programming (I agree!)... was written to satisfy Matz as a programmer, to help him enjoy programming. He hopes it helps Google programmers as well! (with JRuby maybe!)

20 minutes of questions (not a transcript, just my notes):
-Q: stability of 1.8... new features in 1.9... will there be any 1.9 features added to a 1.8x branch? Matz A: Yes
-Q: why release on Christmas? Matz A: enjoys the Holiday break! He lives in non-Christian country yet he is a Christian.. wanted to mention Christianity in a modest day. Next year its going to be a week before Christmas!
-Q: any spec for Ruby language? Matz A: JRuby people worked with Rubinius (implemented in SmallTalk way... Ruby implemented in Ruby)... set of test suites... working with Matz, et al... will have a specification of 1.8 language when its finished.
-Q. what are you doing now? Matz A: improving 1.9. after release of 1.9.1... he will start working on 2.0, which is vaporware now...
-Q. is 2.0 close to being started? Matz A: the time is finally near, yes.. moving forward
-Q. what RegEx engine will Ruby 1.9 use? Will the RegEx syntax be documented this time? Matz A: Oniguma... and we are working on documenting 1.8 and 1.9... it will be available.
-Q. wondering... do you have any timeline when callCC will come back? I noticed it was not on slides. Matz A: you can use it, from 1.9, you have to explicitly declare 'i'm going to do something dangerous'... a guy suggested how about naming Continuations library as "Continuations-i-agree-with-dangerous-thing".
-Q. wondering about String data type.. noticed that you have direct you use UTF-8 and how do you efficiently implement that access? Matz A: UTF-8 data...process it as UTF-8... set of C functions to filter and give illusion of the sequence of characters... from Matz+team's experience... it's okay. Most of the character based process is based on RegEx. If RegEx is optimized, problems can be avoided.
-Q. sounds like your index of a character by RegEx is inefficient? Matz A: ~ in many cases we can have 'tricks' to reduce the complexity
-Q. what is the status of named parameters in Ruby 2.0? Why not just copy from Python syntax which is easy to understand and use? Matz A: named parameters will be added in 2.0... and it's very primitive to those in Python... a hash of symbols that can be specified at the end of argument ... attribute:value, attribute:value, ...
open(path, {encoding: "utf-8", newline: "auto"})
...get it? it is a Hash at the end.
-Q. why do you want to add a Hash to these little parameters... could be confusing? Matz A: this is Hash... It's merely an extended Hash

That's a wrap!

Saturday, February 09, 2008

Language-Specific VM's as a Google Gear?

Has Google Gears or Adobe AIR team considered adapters to language-specific VM's? E.g. client side VM's (for instance, like Rubinius) hooking up to the Gears runtime? The idea being that if you could hook up to a VM running on the client, it could be used to interpret the implementation-specific code -- E.g. a Rubinius VM running on someone's machine, when hooked to Gears, could enable Ruby code/ or ERB in a page in the offline cache, to be successfully interpreted on top of Gears. The VM an individual chose to install would be a separate install outside of the Gears runtime, but would need an api to connect to the Gears runtime.

Wanted to throw out the idea and appreciate any response-
holtonma (at) gmail (dot) com

Offline enabled web apps -- Google Gears, Adobe AIR

Wondering about Gears and AIR... starting to toy with both a bit more these days... maybe the following is a worthwhile topic... related to ideas on how to best structure an offline-enabled (AIR or Gears) web app from scratch. Anyway, wanted to throw out a blog post. Feel free to respond to me here or at holtonma (at) gmail (dot) com.

Since neither AIR nor Gears runtime obviously has any interpreter for server-side langs, like Ruby for instance, and is just a straight manifest (either running on top of WebKit with Air, or running on top of the Gears runtime)... you have at your disposal HTML + JavaScript + SQLite on the client. (or additionally Flash/Flex with AIR, but I personally don't plan on using those initially)

Am wondering, if I'm building another webapp from the ground up (i.e. not extending functionality), it seems like there would be an advantage, where possible/pragmatic, to structuring my app as HTML+Ajax throughout, and trying to remove wherever possible any references to eRB, PHP tags, CF tags, et al inside the page. This way you could keep your Views DRY (pretty much straight HTML and JS), and within JavaScript you could, for instance, have a Factory to detect online, high-latency, or offline, then direct the code to either run an Ajax query to the server-side store, or to the local SQLite db. It would also, to an extent, disconnect the server-side Model from the implementation -- that is, you could have server-side Model code on the server in Ruby, Python, CF whatever you wanted.

By loosely coupling the server-side to client side with HTML + JS seems to afford an opportunity to more readily adapt to runtimes like Gears or AIR.

Is that a fair analysis? Am I missing something? Was curious to hear the thoughts of someone who knew more than I on this topic, so please, fire when ready.