Syntactic sugar and hybrid dynamic languages
I just listened to Software Engineering Radio Episode 14: Interview Ted Neward and boy that's got a lot of interesting food for thought.
The main focus was to discuss the LINQ addition to C#.
The first idea that came to mind is he, Ted Neward, described LINQ as little more than "syntactic sugar". What LINQ does is integrate database queries with the C# language in what sounds like interesting ways. And, he says that under the covers in the generated bytecodes, it's clear that this is implemented through compiler tricks. Or, as he calls it, syntactic sugar.
Now, that brings to mind the new Java language features which came with Java 5 (Tiger), and how some have described them as syntactic sugar. This seems to me to be a way to dismiss the language features as less valid, because they're just syntactic sugar.
But, you know what, I think every high level language structure is just syntactic sugar. That every high level language structure ultimately is translated down to low level instructions. Even the "for loop" from C is really just syntactic sugar for an "if" statement and a set of "goto" statements.
That's what computer languages do, after all, is build high level abstractions that allow us to more easily describe to the computer what it is we want the computer to do.
The other thing I take from the interview is the potential value of marrying dynamic and static programming language features. Languages don't have to be either static or dynamic, they could have features of both. That's an interesting thought to ponder. And to give one even more food for thought, he sketches out a method where a suitable Java compiler could implement hybrid static/dynamic language features.
My last thought is it sounds highly attractive to be able to weave multiple languages together into one program.
It's always seemed very clunky to me to use JDBC to make SQL calls. I hate doing that so much, that one time I spend 3 weeks writing a persistence layer which would handle the JDBC for me.
What the LINQ thing does, I gather from the interview, is to make SQL statements be something you can write in the middle of a C# program. You can put C# variables into the middle of the SQL statement, and the compiler interpolates the values for you into the SQL call. And the result set gets automatically interpolated to an appropriately pseudo-dynamic object. Sounds cool.
To me the general principle is that each niche of activity has tools suitable to that activity. For example the tool for a painter is a brush, the tool for a writer is a pen, the tool for a carpenter is a saw or hammer, etc. The tools are shaped and designed to make certain jobs easier. And it's easy to fall into the trap of "if all you have is a hammer, then all the world begins to look like a nail".
To computerise our human activities it's helpful to have domain specific tools. A painter who wants to paint on a computer shouldn't be writing code in C that draws their painting. Instead the painter should have something like a Wacom tablet and be using something like Photoshop.
Hence, a database programmer should have a language that looks like SQL and integrates SQL nicely with the rest of the software system.
Hence, an XML programmer should have a language that looks like XML and integrates XML nicely with the rest of the system.