Bill Katz is a fiction author and technologist currently busy on his new venture Writertopia. He's also very interested in the beauty of Ruby on Rails and how it relates to Paul Graham's love for LISP:
Graham talks about bottom-up design, changing the language to suit the problem. It suggests one reason why Rails looks so good compared to other web frameworks: Rails looks like souped-up Ruby and not just a bunch of classes, procedure calls, and bolted-on code.
"In Lisp, you don't just write your program down toward the language, you also build the language up toward your program," Graham wrote. "Language and program evolve together... In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient." That's a pretty good description from 1993 on Rails development and points to a not-so-subtle difference between the web frameworks.
This is with out a doubt one of the Ruby features that excites me the most. The ability to evolve your own dialect of the language to fit the domain. The purity and beauty in code like the following is intensely satisfying (this is not pseudo code, it's fully executable without a precompiling code generation phase):
class Project < ActiveRecord::Base
belongs_to :portfolio
has_one :project_manager
has_many :milestones
has_and_belongs_to_many :categories
validates_presence_of :name, :description
validates_acceptance_of :non_disclosure_agreement
validates_uniqueness_of :key
end
Which is also why calling glue kits like Trails a clone of Rails in Java just makes no sense (and exposes the sender of such a statement as uninformed at best). Replicating a single feature of Rails, such as Trails does with Scaffolding, does not a clone make. Not only is it a pick on one of the most shallow features of Rails, but it also possesses none of the elegance. Katz addresses this with:
When answering the question "Could Rails be built without Ruby?", I think you have to address not only the functionality but the aesthetics as well. It's more than the simple lines-of-code metric. It's whether you've built a language up towards a Rails language that solves problems common in web development. As Graham points out, you could build Rails out of any language that's Turing-equivalent; the real question is in your quest to duplicate the aesthetics, whether you'd wind up doing a back-door implementation of a Ruby interpreter in the process.
When Bill Katz calls Rails "...a work of art in progress", I can definitely imagine Serious Developers tuning out: "Code is not supposed to be artistic, just functional". To me that's a terribly depressing statement. Code that can be both "art" (as defined by striving for elegance and readability as primary motivation factors) and functional is what makes programming interesting to me.
Oliver Steele from Lazlo touched on many of the same issues.
Challenge by on March 10, 14:13
I understand your passion for Ruby but please don't play "its like Lisp" card. Ruby is to (Common) Lisp what ANSI C is to Ruby.
Challenge by on March 10, 14:29
Of course, the discussion of DSLs vs. libraries are as old as Lisp and still not settled. Whether some random "technologist" likes the concept of Rails' DSL is complete uninteresting. What matters is whether real programmers will like it enough to try it.
Rails is great, but it would be nice to cut down on the hand-waving and focus on practical issues.
I don't know Lisp nearly well enough to make such a statement. I'm merely saying that "In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient" describes accurately how I feel developing in Ruby.
calling glue kits like Trails a clone of Rails in Java
just makes no sense
(and exposes the sender of such a statement
as uninformed at best).
I've never heard the Trails folks call Trails a 'clone'
In most cases, they've been careful to state that Trails is "inspired by Rails (and naked objects)".
I'm amazed and excited about Rails.
But for clients insisting on the baggage of Java,
Trails may be a nice fit, and I wish them well in continuing to evolve it to the limits of Java's potential.
Go Rails! Go Trails!
That is a lovely code example, and you're absolutely right that it is quite impossible to do in Java.
However, for the record, Trails does not even do scaffolding, we start with the object model. And I certainly never claimed Trails to be a clone or port of Rails, not really sure how you picked that up exactly. The bottom line: if you're in a position where Ruby is the best fit for your environment, Rails is an awesome tool. If Java is the choice, I hope to evolve Trails into a productive solution, one that learns as much as possible from excellent frameworks like Rails.
"Whether some random "technologist" likes the concept of Rails' DSL is complete uninteresting. What matters is whether real programmers will like it enough to try it."
I didn't know I had to roll out my comp-sci work at Stanford, ACM programming contests, or decades of coding to make a comment on language elegance. If you think elegance of solution isn't a "practical issue," particularly when it can be achieved without analysis paralysis, then that might reflect more on your programming background than mine.
I wonder how many Lisp hackers would agree with that statement? Ruby and Lisp aren't going to be confused with each other, but Graham does suggest it's similar to pre-CL forms of Lisp: "If you'd shown people Ruby in 1975 and described it as a dialect of Lisp with syntax, no one would have argued with you."
Don't interpret this as a language war. It's not. But suggesting the difference is the same as between ANSI C and Ruby is hyberbole. If you could back it up with an aspect of CL that gives you that impression, I'd like to hear it because dynamic typing, OO, closures, etc. are pretty big jumps from C to Ruby.
Challenge by on March 10, 20:33
OO in Ruby is part of langauage specification.
OO in Common Lisp is a library.
Big difference.
Challenge by on March 10, 21:19
If OO is in language instead of library, how does that change the power of the language? I don't think the point is the amount of syntax, it's the difference in power and the elegance of using that power. Ruby and Lisp are more alike than C in that respect.
Challenge by . on March 11, 7:16
"OO in Common Lisp is a library.
Big difference."
It's fun to make up things and pretend they're true! Look at Santa Claus and the Easter Bunny!
OO in Common Lisp is part of the ANSI standard specifying Common Lisp. Implementation should not be part of the language spec, so if it's a library, hey, C++ was a preprocessor hack.
Challenge by . on March 11, 16:29
whatsoever ... here are a couple of things to consider..
Which language came with all these sweet features (and ideas) ... ? and continued to stay a powerfull tool in terms of features (let alone the syntax - which needs another thread) ...?
do not forget that *Matz* was (and still) a lisp lover !!!
if you can twist your mind around lisp, then its not hard to do so with ruby... !
but finally (wether you like lisp or ruby) ... select the one which makes your development fun ... (be it ruby or lisp) ... !! at the end you are spending money and/or time for the goal not the tool
Being a Java programmer by trade, I had to go look at Trails and was amused when I found this website:
http://www.railtrails.org/
*Chuckle*
Challenge by /_ on March 24, 2:20
CLOS, the Common Lisp Object System, is a very nice implementation of the OO model. It has a somehow different approach than other OO implementations: methods do not belong to objects, they are chosen by a generic dispatch. Most Common Lisp implementations also follow the Meta Object Protocol. The MOP lets you control and change the way CLOS works. You could implement your own OO model using the MOP.
Add macros, of course. You don't miss them perhaps, if you don't know what macros are (they are much more than just textual substitutions, because they can completely control the evaluation of arguments). You can use them for nice tricks, like shifting computation to compile time or intentional variable capture.
If you really want to pull the language up to your problem, you'r going to use macros. You need a language that supports multiple computation models. There is no language that supports *all* computation models (Lisp doesn't have native concurrency for example), but it's fun to use a language that supports more than one.
I like multiparadigm languages like Lisp or Oz. Ruby is a single paradigm language. But it's cool. It's fun. The only thing that bothers me: I really don't know why I like it. That's the way seduction works, I gues...
