litany against fear

Ruby: Fragile or Agile? Notes

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is by Josh Susser from Pivotal Labs.

Tons of wonders in the world. What the heck happened to Smalltalk though? Spawned many languages, but it was still superior. Yeah, there’s Lisp too. Why aren’t we all programming in Smalltalk? C++ mostly.

Why is it a bad idea to go with C++ (At Apple!) Alan Kay said that 3 things make up OO: encapsulation, polymorphism, inheritance. For C++: WEAK encapsulation, WEAK polymorphism, WTF inheritance. At Xerox he programmed a smalltalk interpreter (or something) in Microcode. C++ is not a high level language. Just a thin layer on top of C, which is just portable assembly. Smalltalk had a lot of great things…IDE, garbage collection, and a huge blind spot.

Josh likes looking at things like their greatest strength is their greatest weakness. Comparing to Superman’s strength and willingness to do good, which Lex Luthor can manipulate.

“An operating system is everything that can’t fit in a language” Very meta: Most of smalltalk implemented in smalltalk. Made of a kernel, which made up the fundamental pieces of the language: primitives, datatypes, IO, fundamentals. Virtual image had everything else: compiler, graphics, network stack. VM can be ported from platform to platform, and the image runs the same.

Virtual image is really cool, but it’s not without cost. Made applications almost impossible to deliver. He was one of the first at Xerox to deliver commerical Smalltalk apps. Very hard since the code was integrated with the user’s data. No concept for namespaces, so screwed if vendors use them together.

So, it’s a bit of a monolith. You’re not using Linux, Windows, etc windowing system, you’re using Smalltalk’s. It’s getting old. C++ sucked up all of the oxygen and steam that Smalltalk had built up in a very short period of time.

Why did that happen? C++ was not better than Smalltalk, but it was just enough better than C. Didn’t require a big conceptual leap, plenty of tools, easy to implement, tons of tools already available for C. Most important things: Could actually ship applications with C++ to customers. Just enough more productivity! Sometimes, good enough is good enough.

That brings us to Ruby. It would really suck if we were all programming in the modern equivalent of C++. It’s not in immediate danger of facing Smalltalk’s demise, but it couldn’t hurt to think about ways to strengthen Ruby. Not going to fix the language, but fix the language.

Rails. Most people came through it, and web development is the center of what’s being done with Ruby. However, in the long run it’s a niche….like PostScript. The next Ruby ‘killer app’ will be outside of the web development domain. Not sure what yet though.

Proposing that the reasons why people like Ruby is also because of agile development. There’s a higher percentage of Rubyists that actually do use agile development techniques. It brought joy back to his programming experience because of that. Best thing about Rails is the test directory and how it encourages TDD. RubyGems too since most ship with tests. There’s a culture of agile development around Ruby and it’s essential to its future. Performance issued may be solved by Maglev, Rubinius, YARV, etc.

The amount of metaprogramming in the language helps with the TDD movement. The problem is in development tools: we don’t have a good IDE! It’s a joy to program in it, but it makes it hell on an IDE to understand what’s going on with the language. Smalltalk made decisions to limit the language so good development tools could be created. Simple refactoring methods like extract method, renaming are easy in Smalltalk. Not so much in Ruby because of its dynamic nature.

Going through how update_attributes works…it uses send to dynamically set attributes. It’s incredibly powerful and expressive, but it makes refactoring difficult. This may be preventing people who are working with Java and used to refactoring tools to move over. No way to fully statically analyze a Ruby program…you’d need to solve the halting problem: Run the program to see what the program does. Why don’t we just do that? Run tests to see what’s interesting about the program.

Showing off a little example to see what methods have been called on what classes. Can easily hook into Ruby metaprogramming to figure it out, but the main problem with this is that it can be very slow and you need to run the whole program.