Crazy Thing number 2

Journal Zarf's Journal: Crazy Thing number 2 1

Journal by Zarf on Tuesday March 06, 2007 @11:38AM

Last time we covered the fall of CORBA and the rise of SOAP. And that was crazy thing number 1. Let's talk about crazy thing number 2.

Back in the day, when I was a toddler and there was no microprocessor monopoly there was more than one binary language in the world. It was a pain to learn these binary languages... folks covered these up with assembly languages that were mnemonic names for bit codes that a simple program could swap over to binary. Assembly was great and you could cross-compile it to various processors as needed.

Eventually, folks started writing more software than one person could hold in their noggin' more code than could be re-written in a weekend and the problem was to re-use code and to share it with other programmers. Higher level languages were developed to help us out with this problem.

C was one such language. And the fact that we had a language like C at all was awesome. Now we started to see software ecosystems. Different programs performed different jobs inside a framework provided by a new thing called an operating system. To solve this problem and to try and match human thinking better we developed new techniques for coding. We were blessed with Object Oriented Programming.

So many programmers were in love with C that C++ was born. C++ was the next incarnation of C and it had objects. Code reuse and layers of abstraction would save us. These layers would mean you could ignore certain facets of your computer at certain times. You could work in your happy little object and not worry about the disk drive spin speed or network latency.

Now the forces that created crazy thing number 1: SOAP are at play in this play ground too. Data doesn't flow between different machines easily because the bits don't lay in memory the same. And, you have to compile your code for every CPU you want it to run on. So somebody said. Hey, why not make one universal byte code and write an interpreter to handle that byte code turning it into native binary just in time?

Great. Java was born. It ran on a virtual machine. The virtual machine saved you from having to learn fifty different CPU, binary, OS, and other software ecosystems. Write code once compile to Java byte code and run it everywhere.

As it turns out language companies had been cheating in a similar way for years prior. Microsoft didn't write an entire compiler for every OS their languages ran on, they compiled to a byte code then they wrote a byte code assembler that took their special byte codes the last mile to CPU native binary. Every language compiler would be written to turn high-level code to byte code... then port the byte code assembler to every platform. After Java became popular Microsoft just shifted their existing architecture a little and you get .Net ... which again shows that Microsoft has brains they didn't even know they had ... but I digress, this particular thing has very little to do with crazy thing number 2.

There's something to notice here. We've spent all this time and energy on a single general purpose programming language. Most programmer's burned out their whole careers in a few of these general purpose languages on various platforms. All this even though we had ecosystems of software.

Back in old skool unix hackerdom the philosophy of having a whole mess of little tools and binding them together had accidentally lead to some interesting tools. Among those tools were things like sed and awk. These were text processing tools with their own languages. They used regular expressions which are exceedingly cryptic to the neophyte and take weeks to master but are exceedingly powerful.

In the rarefied air of database land, Structured Query Languages came to exist solely for the purpose of manipulating data in a relational structure. These were easy to learn, hard to master, query languages that could do a great deal with structured data. In fact DBA's were born out of the need to master this new way of dealing with data... a fact that plays into just how crazy crazy thing number 2 is...

Think back to the early 1990s and how a super spiffy windows program in 1995 might go together. You would write your program in C++ it would use C++ to run queries, it would use C++ to call the MFC to create windows and a GUI... it would use C++ to talk on the network or use C++ running queries to update tables that would act as message queues.

Consider the cool 1997 Java program would use Java to run SQL, Java to draw AWT, and Java to talk on the network.

Consider the cool 1993 Unix haxor program. It would use C to run SQL on a database, Sed and Awk to chop up data, and a CLI or a web interface to show the data. You might even shoot the data to a shell, sed, awk, and postscript printer driver.

Which of these things is not like the others?

Aside from the fact that the Unix program even in 1997 would have the crappiest UI of all three approaches the Unix program is doing something crazy. It's using different language at different levels each to their own strength.

There are real horrific problems with the Unix haxor's program to be sure. His UI sucks. His various languages are undisciplined and cryptic to anyone schooled on all but that particular level and language. But, he's using a federation of simple tools together to get a very complicated job done in fact each language is good at only one thing... they are...

Domain Specific Languages

Just as SOAP begins to free your mind from being locked into a single OS, computer, geographic processing location, or even programming language ... Domain Specific Languages begin to free your mind from procedural chains. Different problems lend themselves well to different languages and different descriptions.

Crazy thing number 2 is found in the classification of the following things: ECMA Script, SQL, XML, XUL, PDL, BPEL, Rules, XSLT, ... and so on. These are quirky limited languages that provide powerful constructs in their domains. These languages can't do the job of a C or a Java but they can do their specific job very very well.

SOAP helps open the door to using different languages for different tasks. However, the utility and power of DSL (Domain Specific Languages) can make very difficult thoughts easy to express.

Today your spiffy application would live on the web. It would use C#, Java, or some other traditional language to talk to a database through a broker that has a configuration or DSL like HQL. The flow of the program would be dictated by a BPEL script. Logical assertions handled by a Rules language. Your traditional language would then send out XML via SOAP and talk to a web front end described in XHTML with widgets written in a child of ECMA Script and transform the data (perhaps in client) with a data transformation language like XSLT.

If one goal of programming languages it to provide structure to human thought (so it can be compiled for different platforms, reused, shared with others) who says we all think the same way? Who says procedural thinking encapsulates all of human thought? Why not have different languages to cover different domains of thought?

Just as German has terms like Schadenfreude that don't really translate into English well, SQL does things that C can't do well either. Sure, you can get the same meaning because you ultimately translate SQL into C but "SELECT * FROM Clue WHERE User = ?" encapsulates the thought so much better. Schadenfreude... damage joy, mischief enjoyment, whatever... you get the idea.

Layout is covered really well by XHTML, ECMA Script covers UI actions well, C covers OS well, SOAP handles data interchange well, Java and C# cover procedural how-to-do-things programs well, Work flows can tie objects together into a process, Rules handle the what-and-why of logic better than procedures.

Tie the DSL together with a uniform interface and mix them together to solve problems. We have finally gotten away from the one-language-fits-all trap. Put DSL with SOAP in your blender and press blend.

This discussion has been archived. No new comments can be posted.