Lambda the Ultimate

I have written an article on in which i was able to write a domain specific language using SQL when the database is modelled using "Table Oriented Programming" techniques.You can find the article here.One notable advantage of this technique is that we do not have to write seperate parser/grammar to get a DSL,we just use TOP and SQL syntax.

I am not a TOP fanatic(ala TopMind), but have found the technique pretty useful at work which prompted me to write this article. Also note that this article was intended to be published in a magazine for general developers, so the terminology is a little loose.

However Corrections, flames and opinions are always welcome.

Have any of our mathematically inclined readers browsed Categories for Software Engineering and would they recommend it to a not-so-theoretical software developer?

Visual Haskell is a complete development environment for Haskell software, based on Microsoft's Visual Studio platform. Visual Haskell integrates with the Visual Studio editor to provide interactive features to aid Haskell development, and it enables the construction of projects consisting of multiple Haskell modules, using the Cabal building/packaging infrastructure.

Visual Haskell is a complete system in one download: it includes a full GHC installation with libraries, and various tools including Haddock, Happy, and Alex.

Worth knowing about.

In writing Scheme programs, I've learned a lot about coding, design, architecture, and aesthetics.

Old news, right? Still, this piece might be worth sending around to your unenlightened frieds.

I spent a couple of hours this evening writing my first real Ruby code for the Lexical Semantics course I am taking this fall. It's excellent. The syntax is very appealing. Tokens are strangely verbose, replacing "{" and "}" of C descent with "def" or (insert block starting token here) and "end". For the first 30 seconds after encountering this on page 1, I wasn't sure how I felt about it. It seemed verbose. But now I see that "end" is much easier to type than "}", whose presence in Java forces me to reach and twist for basic program vocabulary. Maybe it would be different if I weren't on Dvorak, but words as delimiters rather than punctuation is a definite win. And while the tokens are fat—in a good way—they are also few. The syntax is remarkably terse, but not at the peril of clarity as I feel is the case with Perl. Ruby makes me understand the power of judicious syntactic support for common tasks. String interpolation is an obvious and immediately addictive feature. Built-in regular expression literals are also a plus. And there is an elegant interplay between these syntactic features on both a functional and visual level. As syntax is concerned, Scheme has represented a year-long exile in the wilderness. The bare minimalism of S-expressions was good for me. Scheme's uniform and parsimonious syntax let me focus on concepts that are fundamental to high-level programming: recursion, higher order procedures, and data abstraction. Scheme taught me by giving me only a handful of powerful tools and then training me to use them well. Now I think that Ruby can empower me by equipping that sharpened outlook with richer facilities for the completion of common tasks. Its assumptions are friendly to my most cherished and hard-won programming intuition, but they also cater to the harsh realities of programming in an imperative world.

Paul Graham says that languages are evolving ever-closer to Lisp, and he asks, why not skip directly to it? And I think that I finally have an answer. Perhaps the ideal programming experience is purely functional, and the mainstream's gradual adoption of features pioneered by functional languages reflects this truth. But there are other truths. Tim O'Reilly presents another point. He says that as new computing paradigms emerge, new languages seem to rise with them, suggesting that from a pragmatic standpoint, a language's "goodness" is sensitively dependent on the world in which it is used and with which it must interact. Every time I have programmed functionally for practical applications, I am keenly aware of how imperative the world outside my program really is. The operating system doesn't behave functionally, and I/O operations certainly never could. There has to be a reason why these languages are so popular, beyond the simple fact that they are easier to learn for programmers whose first language was C. My conclusion is this. In the real world of computing, one finds explicit notions of state; one finds assignment. The computing hyperscape is not (yet, perhaps) very functional. State-oriented computational objects seem a natural complement to our false intuition of objects existing in the real world as well. Nietzsche would say that there are no objects, and, indeed, there aren't even any facts. There is only "will to power". Sounds remarkably similar to me trying to explain to C programmers that there is no data, and there isn't, in fact, any need for assignment. There is only Lambda. I think Nietzsche is right and I think Steele and Sussman were right, but that truth does not mean that the illusion of objects is an utterly worthless one. If we actually cognized the outside world as consisting only of "will to power" rather than tables and chairs and people, we'd never get anything done. And perhaps, similarly, when we pretend that everything is a Lambda, we face similar difficulties in interfacing this remarkably beautiful, completely true notion with an ability to do anything about it.

These ideas, are, I guess, nothing new. Haskell's monad system, from the cursory understanding I have of it, is a formalization of them, a clean interface between the rough and tumble outside universe and the sublime purity of Haskellspace. But if I'm not going to use an airlock, maybe a clever, elegant, and even artistic bridge between functional wisdom and imperative truth will suffice. For now, Ruby seems to be a pretty decent attempt. Lambda may be vulgarized into a quirky codeblock, but in a language in which shell commands are syntactically supported, at least it exists.

Language design isn't just about big ideas, it's also about little details...

c-jump looks harmful to children. Time for a Scheme board game? I think I've found a good name for it.

I just came across Logix, which appears to be a language for building (and freely intermixing) DSLs. It is similar to Lisp in many ways (a point the website makes several times), but with a substantially different syntax, and an approach based more on objects than lists. From the website:

Logix is more than a programming language. It is multi-language programming system. With Logix, each part of your program can be developed in a language that is finely tuned to the task.


Featuring a procedural macro facility, dynamic syntax extension, and multi-language parsing. A new operator, complete with syntax and semantics, can be added on-the-fly with a single line of code.

The "60 second intro" provides a couple of brief examples of the way syntax enxtension works. There is also a more extensive tutorial that discusses the base Logix language (which is somewhat like Python), as well as providing more detail on how to extend the language.

Logix as presently implemented generates Python byte-code, but the designers are investigating other platforms (Mono, Parrot, LLVM).

[$0.02 in the category of 'perhaps we can get past the silly holy wars and into interesting ones'] I've seen it come up a few times in discussions: the claim that something is more intuitive than something else. I have a passing interest in usability, UI, and visualization, so the term 'intuitive' is something I come across a lot. I think Jef Raskin had it right: it is not an absolute, it heavily depends on individual experience.

Thus, this is a request for folks to avoid getting sucked into the 'is too' 'is not'. You have to say 'to whom' and 'when' and 'under what circumstances'. For PL evangelists, I think this is good to keep in mind.