Toxic Elephant

The Arc Challenge

Posted by matijs Sun, 17 Feb 2008 21:14:00 GMT

Hm, so Arc is here, and Paul Graham gives the Arc challenge. The answer in Arc is short indeed. First, let’s see an answer in Rails (loading a framework is allowed according to the challenge), with said_controller.rb:

class SaidController < ApplicationController
  def index; end
  def click; session[:it] = params['what']; end
  def show; end
end

and some templates, for the first page, index.html.erb:

<% form_tag '/said/click' do %>
  <%= text_field_tag 'what' %>
  <%= submit_tag %>
<% end %>

second page, click.html.erb:

<%= link_to 'click here', {:action => 'show'} %>

third page, show.html.erb:

You said <%= session[:it] %>

The Rails answer may be a little longer (although by how much is hard to say due to the different syntax — is end a token?), but it not a case of the same but longer.

First, the Rails version is in temporal order, the Arc version is not. Perhaps there’s a way of reading the Arc version that makes this order natural, but right now, it looks confusing.

But the most striking difference is that it is based on a completely different philosophy of how web applications should be developed. The Arc answer is great if you want a web application based on continuations. The Rails answer is what you would use if you want to use REST.

I’m definitely in the REST camp, which makes this example meaningless as a demonstration of Arc. It shows me that Arc can be used to write a short program that does something I don’t want to do.

The ultimate question of course is whether brevity (in terms of number of tokens, not characters) is the single best metric for language power.

Update: Someone wrote a Ruby version that is about as short as the Arc version, uses the same paradigm, and is in temporal order:

def said
  aform(input("foo"), submit) {
    w_link("click here") {
      "you said: #{arg :foo}"}}
end

Posted in software | Tags arc, continuations, design, language, rest, ruby | 2 comments | no trackbacks

Undressed Ruby

Posted by matijs Sun, 14 Oct 2007 12:14:00 GMT

In Ruby, there is really no compile time. There is parse time, and then there is run time. All class and method definitions are done at run time.

  class Foo
    def bar
      puts "Zoo!"
    end
  end

is basically¹:

  Foo = Class.new do
    self.define_method(:bar) do
      puts "Zoo!"
    end
  end

See, we just removed the class and def keywords from Ruby. What else? Ah yes, method calls. That’s just sending messages. In fact, you can replace any method call foo.bar with foo.send(:bar), like so²:

  Foo = Class.send(:new) do
    self.send(:define_method, :bar) do
      self.send(:puts, "Zoo!")
    end
  end

How much syntax can you remove like this? How far can Ruby be undressed? And can you come up with a macro system to put the clothes back on?

Some ingredients: Why list macros are cool, RubyToRuby.

¹ Actually, it’s not the same, since the define_method way creates a closure, so you can do like this

² Yes, I know I’m using method call syntax here. But this way I do expose the message-passing view on OO that Ruby has. If you want, you can replace it with send_message(object, method, *args), and assume Ruby defines send_message somewhere.

Posted in software | Tags macros, ruby | no comments | no trackbacks

A DSL for making SQL-like DSLs

Posted by matijs Sat, 14 Apr 2007 14:42:00 GMT

Setting the stage

Some time ago, I came across SQLDSL, a DSL for building SQL queries. The benefit of using a DSL over plain old string concatenation is that syntax is checked before the database server is hit. Unfortunately, SQLDSL does not deliver. It will happily accept

  q = Insert.into["frot"]["zop"]["blob"].values("kng").values["kgn"]

resulting in

  q.to_sql
  # => "insert into 'frot' (zop) (blob) values ('kng') values () (kgn)"

which is hardly acceptable SQL.

Posted in software | Tags dsl, metaprogramming, ruby, sql | no comments | no trackbacks

I Want Cells-GTK for Ruby

Posted by matijs Mon, 22 Jan 2007 13:21:00 GMT

For some applications, a spreadsheet is the perfect development environment. The UI is a no-brainer, while the relations between the different values is clearly visible, and changes are automatically propagated from what could be called properties to derived values.

The problem is, of course, that you’re missing out on the features a programming language could offer. Macros are basically a dead end, unless you like to solve user issues like ‘It doesn’t work because I disabled all macros.’

What I want is something that gives me this easy linking within a model and between model and UI, but from withing Ruby. It is my prefered solution to the Gnome on Rails problem.

Cells for Common Lisp promises to take care of the automatic propagation and dependencies between cells:

Cells is a mature, stable extension to CLOS that allows you to create classes, the instances of which have slots whose values are determined by a formula. Think of the slots as cells in a spreadsheet (get it?), and you’ve got the right idea. You can use any arbitrary Common Lisp expression to specify the value of a cell. The Cells system takes care of tracking dependencies among cells, and propagating values.

That seems to take care of the automatic updating of derived values. The second part is the no-brain-UI. What’s needed for that is a dead-simple way to link settable values to input widgets (text boxes, spin buttons, etc.), and to link derived cell values to labels. By dead-simple I mean that it should be done in at most one line per widget/value pair.

It seems for that part, the solution would be to use cells-gtk:

Cells transparently link GUI elements with each other and the application model to greatly simplify development of rich interfaces. Cells also automate how Lisp GUI instances drive their GTK+ counterparts.

Sounds great!

The problem (for me at least) is that this is all in Lisp, and I don’t know Lisp yet. So, I want this, but in Ruby (since that’s the language I like to use most right now). Some basic ingredients are already there: We can use blocks as formulas for the derived values, and there’s the Observable module. Also, Ruby has bindings for Gtk+.

I have some more wishes, but they’re mostly about Gtk+, so I leave those till later.

Posted in software | Tags lisp, ruby | no comments | no trackbacks

Skipping Python for Ruby

Posted by matijs Thu, 18 Jan 2007 18:59:00 GMT

Without an e writes

Well, ruby just isn’t that much better than python. If I’m going to relearn everything, why would I bother with ruby? Why not just jump straight to lisp?

I can really appreciate this argument, since it resonates with my reasons for not learning Python: I knew Perl, and was doing most of my programming in it, making nicely structured, readable, object-oriented programs. To me, Python didn’t seem like such a big step forward: It’s like a Perl with enforced readability.

And then came Ruby.

My introduction to Ruby was not through Rails, but through reading the online version of the Pickaxe Book. After reading the first chapter, I was sold. Here was a language that truly embraced object-orientation, and gave access to all kinds of interesting abstractions that I had only vaguely heard of (such as coroutines). There also was a pleasant lack of boilerplate.

So to me, Ruby is that much better than Perl, whereas Python is not. I wouldn’t know if I agree that Ruby is not that much better than Python, but at least I can understand the argument. Ruby is certainly no Lisp, although it comes close.

So what’s next? Lisp’s features certainly look appealing, giving basically the pinnacle of power of abstraction, in exchange for slightly unappealing syntax. I believe the syntax can be overcome, so my next language to learn may well be a Lisp. Which Lisp is still an open question. On the other hand, there are interesting languages like Erlang, ML and the like.

[Incidentally, Without an e is the creator of Scarlet Lambda, which is roughly a web framework written in, or at least used with, a functional style of programming in Python, with a Lisp-like syntax. Wow.]

Posted in software | Tags lisp, programming, python, ruby | no comments | no trackbacks