Archive for the tag 'Lisp'

Languages of the Gods

I’m always interested to see what someone new to Smalltalk has to say about it, always, but this takes the cake so far. I like what Dave had to say, but I’ll change it to “Languages of the Gods”, for Smalltalk is but one of a few. I personally give it up to both Smalltalk and Lisp, I think most other languages are derivatives of one of these two.

Languages like Smalltalk and Lisp (always got to give Lisp its props) are amplifiers. They make you more of whatever it is that you already are. If you’re a bad programmer, they’re going to make you worse, they’ll let you shoot your foot off in more interesting ways than you can imagine.

If you’re a great programmer, they’re going to make you that much greater, they’re going to let you become a God, and live entirely in a universe of your own abstractions. Anything you don’t like you can objectify or macro’fy and never have to think about it again.

These languages will never be mainstream, because the mainstream would never see the benefits they provide. The mainstream would kill themselves with such power. There’s a reason the mainstream likes manifest typing, procedural programming, and cut and paste methodologies, quite simply, it’s all they can handle.

Reflection is too deep in the bag of tricks for most mainstream programmers, let alone meta programming, or dynamically typed custom DSL’s in esoteric languages like Smalltalk and Lisp.

You have to appreciate beauty and elegance to appreciate Smalltalk and Lisp, and quite frankly, those just aren’t mainstream values. I think Dave’s right, the “Languages of the Gods” will never be mainstream, but you know, that’s not really such a bad thing. As long as the communities are large enough to support the work I do, I really don’t care about what the bandwagon is up to.

Aha! Moments in Lisp

You know, I’m a Smalltalker, but I have a deep respect for Lisp and always love reading about it. I just ran across this great thread of some Lispers talking about their big aha! moments.

One of these days soon I’m going to have to try and do a small web application in Lisp or Scheme, I love Smalltalk, but I still drool over the idea of macros and generic functions. I guess for a Lisper, Slime is the environment to learn, but I shudder at losing my Smalltalk environment and having to learn emacs. I’ve always felt Lisp is the superior language and Smalltalk is the superior environment. If any of you are proficient in both Lisp or Scheme and Smalltalk, I’d love to hear from you.

Fowlers Introduction to Domain Specific Languages Talk

Martin Fowler gives a great talk about the style of domain specific languages, and clearly covers all the main points about the advantages and disadvantages of those styles. This guy is always worth watching, he’s very good at summarizing all the sides of an issue in a very unbiased and informative manner. He doesn’t specifically mention Smalltalk, but every time he says Lisp, you can just pretend he said Smalltalk, it all applies.

Here’s the Smalltalk version of his sample code, in a Smalltalk DSL for comparison.

(Mapping for: #SVCL type: ServiceCall)
    extract: 4 to: 18 for: 'customer_name';
    extract: 19 to: 23 for: 'customer_id';
    extract: 24 to: 27 for: 'call_type_code';
    extract: 4 to: 18 for: 'date_of_call_string'.

(Mapping for: #USAGE type: Usage)
    extract: 9 to: 22 for: 'customer_name';
    extract: 4 to: 8 for: 'customer_ID';
    extract: 30 to: 30 for: 'cycle';
    extract: 31 to: 36 for: 'read_date'.

Simple, clean, no XML necessary, just objects and messages!

Domain Specific Languages - Ruby, a Sign Post on the Road to Smalltalk

There’s so much talk lately about Ruby being so great for writing domain specific languages, but this is only partially true, Ruby’s not all it’s cracked up to be. Too much hype and not enough substance, if one looks a little deeper.

Every programmer knows one domain specific languages that is so common, it’s built into most languages, predicate logic. The good old if, if/else, and while forms, and several variations of them like do, unless, etc. So please forgive me while I state the obvious. Each form works using true/false as the input, and a block of code to be conditionally or repeatedly executed depending upon the value of the input. In a C’ish form, these look like so…

if(aBooleanCondition){
  someCodeToCall();
} else {
  someOtherCodeToCall();
}

while(aBooleanCondition){
    someCodeToCall();
}

There’s nothing new here, every programmer knows this. What’s interesting is that Ruby, like most languages, uses special forms for predicate logic. If Ruby is so great at writing domain specific languages, why not implement the most common domain specific language, predicates, just like any other embedded domain specific language?

This might sound crazy, but there’s no reason that if/else and while need be part of the language, they can be moved into the library, given a language sufficiently powerful enough. When I first learned Smalltalk, the piece of code that blew my mind the most, was exactly this. Smalltalk the language, has no if/else or while statement, instead the domain specific language of predicates is implemented with simple objects and method calls, no compiler voodoo “required” (this is actually optimized by the compiler, I speaking conceptually here). Here’s the most interesting bits.

True>>ifFalse: alternativeBlock
    ^nil
True>>ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock
    ^trueAlternativeBlock value
True>>ifTrue: alternativeBlock
    ^alternativeBlock value
True>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
    ^trueAlternativeBlock value
False>>ifFalse: alternativeBlock
    ^alternativeBlock value
False>>ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock
    ^falseAlternativeBlock value
False>>ifTrue: alternativeBlock
    ^nil
False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
    ^falseAlternativeBlock value
BlockContext>>whileTrue: aBlock
    ^ [self value] whileTrue: [aBlock value]

And here’s how this DSL is used in Smalltalk…

aBooleanCondition
    ifTrue: [ self someCodeToCall ]
    ifFalse: [ self someOtherCodeToCall ]
[aBooleanCondition] whileTrue: [ self someCodeToCall ]

The main thing to note here, beside the beauty of Smalltalk, is that blocks, objects, and methods calls are the necessary building blocks of “language” itself, any language. Having a succinct notation for the delayed evaluation of code, and allowing that code to be placed into variables and passed around, is all one needs to build virtually any domain specific language they can dream up.

Ruby at first glance, appears to have this trait. Ruby has blocks, but it didn’t do them right. Ruby introduced an ugly hack called yield for pretending to pass a block with a terse form {}, but it only works for the last argument to a method, you can’t pass two blocks to a method with this same terse syntax. The above predicate domain specific language can’t be implemented in Ruby in exactly the same way, because Ruby can’t pass both blocks cleanly, and even has two forms for specifying a block, the short and sweet { } and the longer “do end”. This simple case works…

aBooleanCondition.ifTrue { someCodeToCall }

But the two block case won’t, at least not in a single method call, you’d have to chain two calls together.

aBooleanCondition
    .ifTrue { someCodeToCall }
    .ifFalse { self someOtherCodeToCall }

Having keyword message syntax, is another vital piece of the puzzle. You see Ruby code faking this all the time by passing around associations to avoid the ugliness of positional nameless arguments, or as above, chaining multiple call together to fake the keyword style. But this doesn’t look like idiomatic Ruby, and Ruby won’t allow you to build forms that look like the built in if/else/while.

Rather than suffer this ugliness, Ruby simply provided a procedural syntax for predicate logic, with reserved words at the language level. Ruby, as nice as it is, is still a language that “can” build limited domain specific languages, but not necessarily with a syntax on par with what the language itself provides.

Smalltalk seems much more a notation, that can do nothing but build domain specific languages. Ruby isn’t object oriented at the level Smalltalk is, is still falls back to procedural constructs and special syntax for many things. Smalltalk, is pure, objects all the way down, at every level, even the simplest and most common domain specific language of all, predicate logic. When you create a domain specific language in Smalltalk, your code never looks different than code provided by the compiler writer himself, it’s one syntax to rule them all.

Smalltalk shares this trait with languages such as Lisp and Scheme, truly growable languages that put you, the programmer, in charge of what language you want, not some compiler writer who might take six more years to add some feature you just got to have now. When you need a new language feature in Smalltalk, you simply add it. It’s a feeling that once you’ve become accustomed to, you can’t live without, and one you don’t quite get with Ruby.

There’s been a lot of fuss lately about the next Ruby not supporting continuations, a feature vital in building a framework as elegant as Seaside. Yet, continuations were added to Squeak in about 39 lines of code, no big fuss necessary. This is that feeling I’m talking about, no waiting for the next official VM to support them, it’s just a Smalltalk class, like any other.

Ruby is terse, nice looking, and even massively productive, but elegant it is not. And maybe that doesn’t matter to most, but for those like me, elegance is real power, power that Ruby doesn’t have. Ruby’s an interesting sign post on the way from mainstream languages like Java and C#, but it’s not the destination, it’s just a good warm up for learning Smalltalk.

Related Link: Register Domain Name Instantly Register Domain Names Instantly with $6 USD and Flat Registration Fee for next years

« Previous PageNext Page »