Best quote this whole day, found in http://www.codinghorror.com/blog/archives/001131.html#comments.
If Ruby offered something new I would have learned it fine tbh… its just difficult enough to not be able to “pick up and run with” like almost everything else out there… but honestly, it wouldn’t let me do anything I can’t already do.
My brain almost exploded reading that.
I’ve landed, gotten mostly back in the right timezone without too many incidents (except running through SFO to board very badly scheduled connection).
After allowing the impressions from the last 6-7 days to sink in a little, it’s time to summarize RailsConf. I’ll go through the sessions I saw and then do some concluding remarks.
The first day was tutorials. I had a good time in Neal Fords and Pat Farleys tutorial on Metaprogramming. I can’t say I learned much from the sessions, but it was very good content, extremely well presented, and I got the impression that many in the room learned lots of crucial things. The kind of knowledge about internals you get from a talk like this allows you to understand how metaprogramming in Ruby actually works, which makes it easier to achieve the effects you want.
After that I sat around hacking in the Community Code Drive for the rest of the day, with lots of other people. I wasn’t involved in gitjour (which by the way is incredibly cool), but I did manage to find a memory leak in iTerms Bonjour handling due to gitjour. Neat. Me and David Chelimsky paired on getting support for multiline plain text story arguments into RSpec, and by the end of the afternoon it was in.
Finally, we headed out to the JRuby hackfest, which ended up being over full with people. That’s a good problem to have. We had a great time, hacking on different things, helping people to get started and debugging various problems. All in all it was a very productive day.
I began the Friday with Joel Spolsky’s keynote. In contrast to many other people I didn’t like it. There wasn’t really any content at all, just some humorous content and lots of jokes about naked women. I expect something a bit more profound for the first keynote of the conference, since they have a tendency to actually set the standard for the rest of the days.
After the keynote, John Lam showed off IronRuby running a few simple Rails requests. This is a great achievement, and I’m very impressed with their results. I have argued that IronRuby would probably never reach this point, and I’m very happy to admit I was wrong and offer my apologies to John Lam and the IronRuby team. That said, the fact that IronRuby runs a few different Rails requests is not the same thing as saying that IronRuby runs Rails. My personal definition of running Rails is more about having the Rails test suite run at a high percentage of success (something like 96-98% would be good enough for almost all Rails apps to work, provided they are the right 98%). (ED: Evan Phoenix just told me that MRI doesn’t run the Rails test suite totally clean either, because of the way the Rails development process works. So a 100% is probably not a good measure of Rails compatibility.) I assume that this is going to be the next goal for the IronRuby team, and I wish them good luck.
I saw the Hosting talk after that, but I have to admit I was wrapped up in a seriously annoying JRuby bug at the moment so I didn’t really pay attention.
The DataMapper talk was very full and gave a good overview of why DataMapper might be a better choice than AR in many cases. The presentation style could possibly have been a bit less dry, but the content was definitely delicious.
If the next two days were the JRuby days, the Friday was the day for all other alternative implementations. I sat in on the Rubinius talk by Evan Phoenix and friends, and then the much talked about MagLev presentation.
I first want to congratulate Rubinius on running several different Rails requests. It’s very cool and a great milestone. The same caveats as for IronRuby applies of course. But wow, the debugging features is awesome. First class meta objects are extremely powerful, and will provide many capabilities to the platform. The presentation was also extremely entertaining. One of the best presentations for the sheer fun everyone seemed to have. Props to Evan, Brian and Wilson for this.
So. The MagLev talk. First, there seems to be some misunderstandings about what MagLev actually is. It is not a hosting service. Gemstone might offer a hosting service around MagLev in the future, but that’s not what is going on here. MagLev is a new virtual machine for Ruby, based on Gemstone/S. Basing it on a Smalltalk machine makes it very easy for Gemstone to implement a large subset of Ruby and having it running cleanly and with good performance. Exactly how much has been implemented at this point is not really clear, since no major applications run, and the RubySpecs have not been used on it yet. I assume that the implementation doesn’t handle enough Ruby features yet to be able to run the mspec runner and other important machinery.
Was this presentation important? Yeah, sure. To a degree. It was a cool presentation, whetting peoples appetite by showing something that might some day become a real Ruby platform with built in support for an incredible OODB. But it’s still early days.
The Saturday began with Jeremy’s keynote. He talked about the new things in Rails 2.1 and also showed the same app running in Ruby 1.8, 1.9, Rubinius and JRuby. Very cool.
I ended up in Nathaniel Talbotts 23 Hacks session which was fun. Good stuff.
After that the JRuby day began in earnest with Nick’s talk about deploying JRuby on Rails. This was mostly the same talk as given at JavaOne, but more geared towards Ruby programmers. Useful information.
Dan Manges and Zak Tamsen gave an extremely useful talk about how to test Rails applications correctly. Very good material. Exactly the strong kind of deep technical knowledge, gained by experience, that people go to conferences to get.
My talk about JRuby on Rails was generally well received. I had a fun time, and of course I managed to run out of time as usual. I wonder why I’m always afraid of running out of material. That has never happened when I’m talking bout JRuby.
The final technical session of the day ended up being a walk-around to all the different presentations going on and taking a peek, and then ending up hacking in the speakers room.
The evening keynote was by Kent Beck, and as usual he is fantastic to listen to.
The Sunday started with the CS nerds anonymous session, held by Evan Phoenix. It ended up being a kind of lightning talk session, and had some nice points.
After that Ezra gave his talk – that had nothing to do with the session title. He presented Vertebra, which is a cloud computing control system, based on XMPP, Erlang and the actors model. Very cool stuff, although it might not be that useful for people who aren’t in charge of a quite large number of computers. But if you have your own botnet, this might be the best way to control them all. =)
The final session of the day was the JRuby Q&A session, which basically flew by. The first ten minutes went in normal time, and then suddenly the session was over. I think we had good attendance, and the right level of questions. You can see all the points covered in Nicks blog, here.
And then it was over.
So, what was good? The technical level was definitely deeper and more rooted in experience. I have to say that this was probably the best Ruby conference I’ve been to, based on the depth and level of the presentations. Kudos to the scheduling people.
And what was bad? A little bit too much hype about MagLev, and everyone’s tendency to use dark colors on black backgrounds in their presentations. Hey, they look good on your computer screen, but it’s really not readable!
OK. It’s time to get rid of this terminology problem. Ruby does NOT have meta classes. You can define them yourself, but it’s not the same thing as what is commonly called the meta class. That is more correctly called the eigen class. The singleton class is also better than meta class, but eigen class is definitely the most correct term.
So what is a meta class then? Well, it’s a class that defines the behavior of other classes. You can define meta classes in Ruby if you want too by defining a subclass of Class. Those classes would be metaclasses.
Edit: Of course, if you actually try to define a subclass of Class you will find that Ruby doesn’t allow you to do that, which means that you don’t have any meta classes in Ruby. Period.
This should probably have been part of one of my posts on closures or defining methods, but I’m just going to write this separately, because it’s a very common mistake.
So, say that I want to have a class, and I want to send a block when creating the instance of this class, and then be able to invoke that block later, by calling a method. The idiomatic way of doing this would be to use the ampersand and save away the block in an instance variable. But maybe you don’t want to do this for some reason. An alternative would be to create a new singleton method that yields to the block. A first implementation might look like this:
class DoSomething
def initialize
def self.call
yield
end
end
end
d = DoSomething.new do
puts "hello world"
end
d.call
d.call
But this code will not work. Why not? Because as I mentioned in my post about defining methods, “def” will never create a closure. Why is this important? Well, because the current block is actually part of the closure. The yield keyword will use the current frames block, and if the method is not defined as a closure, the block invoked by the yield keyword will actually be the block sent to the “call” method. Since we don’t provide a block to “call”, things will fail.
To fix this is quite simple. Use define_method instead:
class DoSomething
def initialize
(class << self; self; end).send :define_method, :call do
yield
end
end
end
d = DoSomething.new do
puts "hello world"
end
d.call
d.call
As usual with define_method we need to open the singleton class, and use send. This will work, since the block sent to define_method is a real closure, that closes over the block sent to initialize.
There seems to be some confusion with regards to dynamically defining methods in Ruby. I thought I’d take a look at the three available methods for doing this and just quickly note why you’d use one method in favor of another.
Let’s begin by a quick enumeration of the available ways of defining a method after the fact:
There are several things to consider when you dynamically define a method in Ruby. Most importantly you need to consider performance, memory leaks and lexical closure. So, the first, and simplest way of defining a method after the fact is def. You can do a def basically anywhere, but it needs to be qualified if you’re not immediately in the context of a module-like object. So say that you want to create a method that returns a lazily initialized value, you can do it like this:
class Obj
def something
puts "calling simple"
@abc = 3*42
def something
puts "calling memoized"
@abc
end
something
end
end
o = Obj.new
o.something
o.something
o.something
As you can see, we can use the def keyword inside of any context. Something that bites most Ruby programmers at least once – and more than once if they used to be Scheme programmers – is that the second def of “something” will not do a lexically scoped definition inside the scope of the first “something” method. Instead it will define a “something” method on the metaclass of the currently executing self. This means that in the example of the local variable “o”, the first call to “something” will first calculate the value and then define a new “something” method on the metaclass of the “o” local variable. This pattern can be highly useful.
Another variation is quite common. In this case you define a new method on a specific object, without that object being the self. The syntax is simple:
def o.something
puts "singleton method"
end
This is deceptively simple, but also powerful. It will define a new method on the metaclass of the “o” local variable, constant, or result of method call. You can use the same syntax for defining class methods:
def String.something
puts "also singleton method"
end
And in fact, this does exactly the same thing, since String is an instance of the Class class, this will define a method “something” on the metaclass of the String object. There are two other idioms you will see. The first one:
class << o
def something
puts "another singleton method"
end
end
does exactly the same thing as
def o.something
puts "another singleton method"
end
This idiom is generally preferred in two cases – first, when defining on the metaclass of self. In this case, using this syntax makes what is happening much more explicit. The other common usage of this idiom is when you’re defining more than one singleton method. In that case this syntax provide a nice grouping.
The final way of defining methods with def is using module_eval. The main difference here is that module_eval allows you to define new instance methods for a module like object:
String.module_eval do
def something
puts "instance method something"
end
end
"foo".something
This syntax is more or less equivalent to using the module or class keyword, but the difference is that you can send in a block which gives you some more flexibility. For example, say that you want to define the same method on three different classes. The idiomatic way of doing it would be to define a new module and include that in all the classes. But another alternative would be doing it like this:
block = proc do
def something
puts "Shared something definition"
end
end
String.module_eval &block
Hash.module_eval &block
Binding.module_eval &block
The method class_eval is an alias for module_eval – it does exactly the same thing.
OK, so now you know when the def method can be used. Some important notes about it to remember is this: def does _not_ use any enclosing scope. The method defined by def will not be a lexical closure, which means that you can only use instance variables from the enclosing running environment, and even those will be the instance variables of the object executing the method, not the object defining the method. My main rule is this: use def whenever you can. If you don’t need lexical closures or a dynamically defined name, def should be your default option. The reason: performance. All the other versions are much harder – and in some cases impossible – for the runtimes to improve. In JRuby, using def instead of define_method will give you a large performance boost. The difference isn’t that large with MRI, but that is because MRI doesn’t really optimize the performance of general def either, so you get bad performance for both.
Use def unless you can’t.
The next version is define_method. It’s just a regular method that takes a block that defines that implementation of the method. There are some drawbacks to using define_method – the largest is probably that the defined method can’t use blocks, although this is fixed in 1.9. Define_method gives you two important benefits, though. You can use a name that you only know at runtime, and since the method definition is a block this means that it’s a closure. That means you can do something like this:
class Obj
def something
puts "calling simple"
abc = 3*42
(class <<self; self; end).send :define_method, :something do
puts "calling memoized"
abc
end
something
end
end
o = Obj.new
o.something
o.something
o.something
OK, let this code sample sink in for a while. It’s actually several things rolled into one. They are all necessary though. First, note that abc is no longer an instance variable. It’s instead a local variable to the first “something” method. Secondly, the funky looking thing(class <<self; self; end) is the easiest way to get the metaclass of the current object. Unlike def, define_method will not implicitly define something on the metaclass if you don’t specify where to put it. Instead you need to do it manually, so the syntax to get the metaclass is necessary. Third, define_method happens to be a private method on Module, so we need to use send to get around this. But wait, why don’t we just open up the metaclass and call define_method inside of that? Like this:
class Obj
def something
puts "calling simple"
abc = 3*42
class << self
define_method :something do
puts "calling memoized"
abc
end
end
something
end
end
o = Obj.new
o.something
o.something
o.something
Well, it’s a good thought. The problem is that it won’t work. See, there are a few keywords in Ruby that kills lexical closure. The class, module and def keywords are the most obvious ones. So, the reference to abc inside of the define_method block will actually not be a lexical closure to the abc defined outside, but instead actually cause a runtime error since there is no such local variable in scope. This means that using define_method in this way is a bit cumbersome in places, but there are situations where you really need it.
The second feature of define_method is less interesting – it allows you to have any name for the method you define, including something random you come up with at runtime. This can be useful too, of course.
Let’s summarize. The method define_method is a private method so it’s a bit problematic to call, but it allows you to define methods that are real closures, thus providing some needed functionality. You can use whatever name you want for the method, but this shouldn’t be the deciding reason to use it.
There are two problems with define_method. The first one is performance. It’s extremely hard to generally optimize the performance of invocation of a define_method method. Specifically, define_method invocations will usually be a bit slower than activating a block, since define_method also needs to change the self for the block in question. Since it’s a closure it is harder to optimize for other reasons too, namely we can never be exactly sure about what local variables are referred to inside of the block. We can of course guess and hope and do optimistic improvements based on that, but you can never get define_method invocations are fast as invoking a regular Ruby method.
Since the block sent to define_method is a closure, it means it might be a potential memory leak, as I documented in an older blog post. It’s important to note that most Ruby implementations keep around the original self of the block definition, as well as the lexical context, even though the original self is never accessible inside the block, and thus shouldn’t be part of the closed environment. Basically, this means that methods defined with define_method could potentially leak much more than you’d expect.
The final way of defining a method dynamically in Ruby is using def or define_method inside of an eval. There are actually interesting reasons for doing both. In the first case, doing a def inside of an eval allows you to dynamically determine the name of the method, it allows you to insert any code before or after the actual functioning code, and most importantly, defining a method with def inside of eval will usually have all the same performance characteristics as a regular def method. This applies for invocation of the method, not definition of it. Obviously eval is slower than just using def directly. The reason that def inside of an eval can be made fast is that at runtime it will be represented in exactly the same way as a regular def-method. There is no real difference as far as the Ruby runtime sees it. In fact, if you want to, you can model the whole Ruby file as running inside of an eval. Not much difference there. In particular, JRuby will JIT compile the method if it’s defined like that. And actually, this is exactly how Rails handles potentially slow code that needs to be dynamically defined. Take a look at the rendering of compiled views in ActionPack, or the route recognition. Both of these places uses this trick, for good reasons.
The other one I haven’t actually seen, and to be fair I just made it up. =) That’s using define_method inside of an eval. The one thing you would gain from doing such a thing is that you have perfect control over the closure inside of the method defined. That means you could do something like this:
class BinderCreator
def get
abc = 123
binding
end
end
eval(<<EV, BinderCreator.new.get)
Object.send :define_method, :something do
abc
end
EV
In this code we create a new method “something” on Object. This method is actually a closure, but it’s an extremely controller closure since we create a specific binding where we want it, and then use that binding as the context in which the define_method runs. That means we can return the value of abc from inside of the block. This solution will have the same performance problems as regular define_method methods, but it will let you control how much you close over at least.
So what’s the lesson? Defining methods can be complicated in Ruby, and you absolutely need to know when to use which one of these variations. Try to avoid define_method unless you absolutely have to, and remember that def is available in more places than you might think.
First, let me warn you. This is a conspiracy theory. It’s got all the usual logical fallacies and problems of a conspiracy theory. Add to that the fact that it’s almost guaranteed to not be true, you might ask why I’m writing about it. Well, the thing is, if I was in charge of Twitter, I would do something like this. Of course, I’m not in charge, and the people in charge are probably more sane and well adjusted persons than me. But still, who knows?
What is the idea then? Well, it’s actually really simple. Think about the Twitter network, the kind of people who connect there, and the way things spread. What is the difference between Twitter and mobile texting for example? First, everything is by default multicast. It’s not reciprocal – you don’t need to know how many hundreds or thousands read what you write. And you don’t care how many others read the persons you read. You are restricted in length. And, the whole thing is open enough that you can follow all the tweets going on in the system.
The characteristics I’ve described means that Twitter is more or less the ideal memetic engine. What I mean by this is that it’s a wonderful way to spread your ideas, if you can express them in a concise and readable way. This means that certain memes doesn’t work well in this setting, but most do. And you can convince more people to join, because if your tweets are interesting enough, someone will notice them in the all-tweet. Also, you can see who the people you are interested in follows, which means that you can spread your network selectively, but really quickly.
These are not really part of the theory. They are just the axioms. So what’s the theory then? Well, what are Twitter doing with all this data? If I would have been them, I would have used it to do research on memetic spread and viral marketing. I would use it to try out ideas based on how good uptake they have. Finding this information is not really hard when you have control over all the messages happening. In fact, you could actually do it even outside of Twitter, by using the published tools correctly.
What got me thinking along these lines? Well, the whole TechCrunch debacle was the thing that triggered the idea. How would it work in practice? Well, first, the Twitter gang couldn’t necessarily know what kind of people would take up Twitter the most, so the cultural fit of Twitter is actually mostly self organizing. The people and groups taking part of twitter select themself for this experiment. Now, of course there are lots of overlapping groups, and that gives even more interesting possibilities for the sociodynamics of meme transfer between non-overlapping social circles.
Take the Ruby people, who have a quite significant presence on Twitter. They are one of the test groups in my theory, and the TechCrunch article was a very directed way of inserting a meme and see how fast and to how many it propagated. It was very easy to insert this into the blog-sphere, since Twitter could have had any amount of people “leak” the information in the TechCrunch article. Once it was out, they just needed to set up some suitable filters and follow the spread. They also inserted a couonter meme, through one of their employees, to see if it work out as an “antidote” to the first meme, or which one of them was stronger. All in all, I think they got enough material for several research articles out of this stunt.
OK, so really, you don’t need to grasp for conspiracy theories to explain the TC debacle. It’s not necessary, so Occam’s razor demands that we choose the simplest available conclusion that explains all the facts. This theory does not fall into this category. But it’s still an entertaining notion.
And I predict that sooner or later, someone will use Twitter, or another network like it, to do this kind of research. It’s a question of time. This kind of information is way to valuable for marketing purposes and also for the understanding of the human mind, that it will happen. The question is: will you know about it, when you’re participating in their research?
Let’s not forget the lovely recursive interpretation that this blog post is a way of doing the same kind of research I’ve just described.
Great news for all Ruby implementations around. A project to bring RbYAML up-to-date and perform better has been accepted for Google Summer of Code. Long Sun is the name of the student, and me and Xue Yong Zhi will jointly mentor this effort.
In fact, I’m very excited about this news. RbYAML was an incredibly important piece of the puzzle to get JRuby to finally work with RubyGems, and that kickstarted our possibilities to start testing numerous other applications. I soon ported RbYAML to Java, and created the JvYAML and JvYAMLb projects, to get better efficiency. Sadly, this left RbYAML without any TLC. That changed a while back when Rubinius picked up the project to get their YAML support going, and now that Long Sun will work on it, hopefully we will finally get an extremely compliant and bug free YAML implementation for Ruby.
This will obviously benefit Rubinius, but it will also be very good for both JRuby and IronRuby. The work will be test-driven which means a more complete test suite will be built around YAML in Ruby.
If you’re interested in following the project, it’s now hosted at Google Code (due to problems with RubyForge from China) at http://code.google.com/p/rbyaml/. Long Sun will also blog about his progress here: http://rbyaml.blogspot.com/.
Exciting news indeed.
Yesterday marked the first of the Ruby design meetings, where most of the Ruby implementers got together on IRC and started hashing out the solutions to several current concerns, and worked on getting more cooperation in the design of Ruby features.
This is slated to become a weekly meeting, and it’s a huge deal. This will make the lives of all Ruby implementations much easier, and the meeting yesterday actually accomplished some very nice things.
There were representatives from JRuby, Rubinius and macruby present, and of course also Matz, Koichi, Nobu and Tanaka from the Ruby core team.
Some of the highlights was a decision to start working on a common API for MultiVM, initial acceptance to add the RubySpecs (coming from Rubinius originally) into the 1.8 and 1.9 build process, meaning that regression testing will be much better from now on, and also having most implementations using the same specs for compliance testing. In reality, this takes us one step closer to a real executable specification that everyone agrees on and has official blessing from Matz.
In conjunction with this, a decision to set up continuous integration for 1.8 and 1.9 was made. The exact practicalities is still to be decided, but the decision to get it done is also very important.
All in all, these are excellent news, and I’m feeling extremely hopeful about more cooperation between the Ruby implementors.
If you’re interested in exactly what happened, you can find the agenda, action items and log here: http://ruby-design.pbwiki.com/Design20080421.
Today I spent some time connecting two languages that are finding themselves popular for solving wildly different kinds of problems. I decided I wanted to see how easy it was and if it was a workable solution if you would want to take advantage of the strengths of both languages. The result is really up to you. My 15 minutes experiment is what I’ll discuss here.
If you’d like, you can see this as a practical example of the sticky part where two languages meet, in language-oriented programming.
The languages under consideration is Ruby and Erlang. The prerequisite reading is this eminent article by my colleague Dennis Byrne: Integrating Java and Erlang.
The only important part is in fact the mathserver.erl code, which you can see here:
-module(mathserver).
-export([start/0, add/2]).
start() ->
Pid = spawn(fun() -> loop() end),
register(mathserver, Pid).
loop() ->
receive
{From, {add, First, Second}} ->
From ! {mathserver, First + Second},
loop()
end.
add(First, Second) ->
mathserver ! {self(), {add, First, Second}},
receive
{mathserver, Reply} -> Reply
end.
Follow Dennis’ instructions to compile this code and start the server in an Erlang console, and then leave it there.
Now, to use this service is really easy from Erlang. You can really just use the mathserver:add/2 operation directly or remotely. But doing it from another language, in this case Ruby is a little bit more complicated. I will make use of JRuby to solve the problem.
So, the client file for using this code will look like this:
require 'erlang'
Erlang::client("clientnode", "cookie") do |client_node|
server_node = Erlang::OtpPeer.new("servernode@127.0.0.1")
connection = client_node.connect(server_node)
connection.sendRPC("mathserver", "add", Erlang::list(Erlang::num(42), Erlang::num(1)))
sum = connection.receiveRPC
p sum.int_value
end
OK, I confess. There is no erlang.rb yet, so I made one. It includes some very small things that make the interfacing with erlang a bit easier. But it’s actually still quite straight forward what’s going on. We’re creating a named node with a specific cookie, connecting to the server node, and then using sendRPC and receiveRPC to do the actual operation. The missing code for the erlang.rb file should look something like this (I did the minimal amount here):
require 'java'
require '/opt/local/lib/erlang/lib/jinterface/priv/OtpErlang.jar'
module Erlang
import com.ericsson.otp.erlang.OtpSelf
import com.ericsson.otp.erlang.OtpPeer
import com.ericsson.otp.erlang.OtpErlangLong
import com.ericsson.otp.erlang.OtpErlangObject
import com.ericsson.otp.erlang.OtpErlangList
import com.ericsson.otp.erlang.OtpErlangTuple
class << self
def tuple(*args)
OtpErlangTuple.new(args.to_java(OtpErlangObject))
end
def list(*args)
OtpErlangList.new(args.to_java(OtpErlangObject))
end
def client(name, cookie)
yield OtpSelf.new(name, cookie)
end
def num(value)
OtpErlangLong.new(value)
end
def server(name, cookie)
server = OtpSelf.new(name, cookie)
server.publish_port
while true
yield server, server.accept
end
end
end
end
As you can see, this is regular simple code to interface with a Java library. Note that you need to find where JInterface is located in your Erlang installation and point to that (and if you’re on MacOS X, the JInterface that comes with ports doesn’t work. Download and build a new one instead).
There are many things I could have done to make the api MUCH easier to use. For example, I might add some methods to OtpErlangPid, so you could do something like:
pid << [:call, :mathserver, :add, [1, 2]]
where the left arrows sends a message after transforming the arguments.
In fact, it would be exceedingly simple to make the JInterface API downright nice to use, getting the goodies of Erlang while retaining the Ruby language. And oh yeah, this could work on MRI too. There is an equivalent C library for interacting with Erlang, and there could either be a native extension for doing this, or you could just wire it up with DL.
If you read the erlang.rb code carefully, you might have noticed that there are several methods not in use currently. Say, why are they there?
Well, it just so happens that we don’t actually have to use any Erlang code in this example at all. We could just use the Erlang runtime system as a large messaging bus (with fault tolerance and error handling and all that jazz of course). Which means we can create a server too:
require 'erlang'
Erlang::server("servernode", "cookie") do |server, connection|
terms = connection.receive
arguments = terms.element_at(1).element_at(3)
first = arguments.element_at(0)
second = arguments.element_at(1)
sum = first.long_value + second.long_value
connection.send(connection.peer.node, Erlang::tuple(server.pid, Erlang::num(sum)))
end
The way I created the server method, it will accept connections and invoke the block for every time it accepts a connection. This connection is yielded to the block together with the actual node object representing the server. The reason the terms are a little bit convoluted is because the sendRPC call actually adds some things that we can just ignore in this case. But if we wanted, we could check the first atoms and do different operations based on these.
You can run the above code in server, and use the exact same math code if you want. For ease of testing, switch the name to servernode2 in both server and client, and then run them. You have just sent Erlang messages from Ruby to Ruby, passing along Java on the way.
Getting different languages working together doesn’t need to be hard at all. In fact, it can be downright easy to switch to another language for a few operations that doesn’t suit the current language that well. Try it out. You might be surprised.
I have been involved in several discussions about programming languages lately and people have assumed that since I spend lots of time in the Ruby world and with dynamic languages in general I don’t like static typing. Many people in the dynamic language communities definitely expresses opinions that sound like they dislike static typing quite a lot.
I’m trying to not sound defensive here, but I feel the need to clarify my position on the whole discussion. Partly because I think that people are being extremely dogmatic and short-sighted by having an attitude like that.
Most of my time I spend coding in Java and in Ruby. My personal preference are to languages such as Common Lisp and Io, but there is no real chance to use them in my day-to-day work. Ruby neatly fits the purpose of a dynamic language that is close to Lisp for my taste. And I’m involved in JRuby because I believe that there is great worth in the Java platform, but also that many Java programmers would benefit from staying less in the Java language.
I have done my time with Haskell, ML, Scala and several other quite statically typed languages. In general, the fact that I don’t speak that much about those languages is that I have less exposure to them in my day-to-day life.
But this is the thing. I don’t dislike static typing. Absolutely not. It’s extremely useful. In many circumstances it gives me things that really can’t have in a dynamic language.
Interesting thought: Smalltalk is generally called a dynamic language with very late binding. There are no static type tags and no type inference happening. The only type checking that happens will happen at runtime. In this regard, Smalltalk is exactly like Ruby. The main difference is that when you’re working with Smalltalk, it is _always_ runtime. Because of the image based system, the type checking actually happens when you do the programming. There is no real difference between coding time and runtime. Interestingly, this means that Smalltalk tools and environments have most of the same features as a static programming language, while still being dynamic. So a runtime based image system in a dynamic, late bound programming language will actually give you many of the benefits of static typing at compile time.
So the main take away is that I really believe that static typing is extremely important. It’s very, very useful, but not in all circumstances. The fact that we reach for a statically typed programming language by default is something we really need to work with though, because it’s not always the right choice. I’m going to say this in even stronger words. In most cases a statically typed language is a premature optimization that gets extremely much in the way of productivity. That doesn’t mean you shouldn’t choose a statically typed language when it’s the best solution for the problem. But this should be a conscious choice and not by fiat, just because Java is one of the dominant languages right now. And if you need a statically typed language, make sure that you choose one that doesn’t revel in unnecessary type tags. (Java, C#, C++, I’m looking at you.) My current choice for a static language is Scala – it strikes a good balance in most cases.
A statically typed language with type inference will give you some of the same benefits as a good dynamic language, but definitely not all of them. In particular, you get different benefits and a larger degree of flexibility from a dynamic language that can’t be achieved in a static language. Neal Ford and others have been talking about the distinction between dynamic and static typing as being incorrect. The real question is between essence and ceremony. Java is a ceremonious language because it needs you to do several dances to the rain gods to declare even the simplest form of method. In an essential language you will say what you need to say, but nothing else. This is one of the reasons dynamic languages and type inferenced static languages sometimes look quite alike – it’s the absence of ceremony that people react to. That doesn’t mean any essential language can be replaced by another. And with regads to ceremony – don’t use a ceremonious language at all. Please. There is no reason and there are many alternatives that are better.
My three level architecture of layers should probably be updated to say that the stable layer should be an essential, statically typed language. The soft/dynamic layer should almost always be a strongly typed dynamic essential language, and the DSL layers stays the same.
Basically, I believe that you should be extremely pragmatic with regards to both static and dynamic typing. They are tools that solve different problems. But out industry today have a tendency to be very dogmatic about these issues, and that’s the real danger I think. I’m happy to see language-oriented programming and polyglot programming get more traction, because they improve a programmers pragmatic sensibilities.
|
I am a software developer working for Centro de AutonomÃa Digital, mainly with privacy, security and cryptography issues. I have worked on many different things in my life, including programming language design and implementation, security, privacy and cryptography, artificial intelligence and more. |
|
Quito |