jordan.terrell
Just trying to make sense of things...

Language Oriented Programming

Tuesday, 26 February 2008 10:05 by jordan.terrell

Unless you've been hiding under a rock inside of a cave in the middle of the desert without an Internet connection, you have undoubtedly noticed that Microsoft and other vendors are hard at work developing new and updated languages that target the .NET runtime (there are also new languages targeting native code), and the upcoming Dynamic Language Runtime, or DLR.

Here is just a few (this list just scratches the surface):

All of these seem to have surfaced within the last few years, and there appears to be added emphasis to new language concepts and languages.  If we look at the history of software development and the eras, if you will, that it has gone through, you'll see three eras that are quite prominent:

  1. Object Oriented Programming
  2. Component Oriented Programming
  3. Service Oriented Programming (or SOA)

The last one, Service Oriented Programming seems to have become fully adopted into the development culture.  There are many toolkits and frameworks that allows one to build and consume services in multiple development platforms.

With this broad acceptance of Service Oriented Programming, I'm thinking that we are beginning the next era of advancement in software development: Language Oriented Programming.  I think this is a great move by the industry and as a result I feel we will see some really expressive horizontal (general purpose) and vertical (domain specific) languages come from this shift.

However, as it was with the adoption of Object Oriented Programming, I think there is going to be a significant learning curve for many of the developers out there.  Just look at the changes to C# and VB - the addition of functional and query (set algebra) programming concepts, although very powerful (and in my personal opinion very welcomed), they present a huge learning curve to those who are more junior in their understanding of languages and software development concepts.  Those of us who "grok" it, I think now have the responsibility to train as best as we can developers who are new to all these dynamic and functional language concepts.  We need to do our best to encourage them to learn about these changes.  But, even more so, all self-proclaimed software developers need to take (at least some) time to learn about these changes and their underlying concepts - because like it or not, they are coming.

Okay, I'll get off my soap box now.  As you may have noticed in one of my recent posts, I'm working on understanding compilers and languages.  This has been an enjoyable process.  I'm reading two books to help me do this:

I've stayed away from books that are too specific or narrowly focused.  I want to get a well-rounded understanding of language and compiler design and implementation concepts, without confining it to a specific platform.

If anyone has suggestions on resources that I should check out - please do let me know!

Language Designers Should Publish Their Compiler Front-End

Monday, 25 February 2008 09:58 by jordan.terrell

As of late I've been doing a lot of research on understanding and designing computer languages and compilers.  Right now I'm just starting to read two books: Programming Language Pragmatics (Second Edition) and Engineering a Compiler.  Even though I have not read very far into either of these books, I've come to the following conclusion:

Language designers should publish the source code to their compiler's front-end.

Now, in case you don't know what the front-end of a compiler is, take a look at what Wikipedia has to say about it.  To put it in oversimplified, laymen's terms: "The front-end basically parses the source code, and makes sure it is a valid."  That's it, it doesn't actually spit out your target code (e.g. machine code, MSIL, ect..), it only parses it to make sure it can understand the source code.  The back-end of the compiler is responsible for the rest (for those who are compiler savvy, I know this is overly simplified).

With that in mind, I now come back to my original statement:

Language designers should publish the source code to their compiler's front-end.

No doubt many of you have noticed the surge of development tools around refactoring and code analysis.  Most of these rely on some language parsing component to understand the source code you are working with and make suggestions.  Developing tools like these would be much simpler and consistent if everyone relied on the same compiler front-end.  Plus, I would think that it would only help to drive further adoption of the language.

I've got a few code analysis ideas that I would like to work on, and this is what has driven me to do research on developing compilers.  In order to implement these ideas, I'm going to need to write a few compiler front-ends for some of the more popular .NET languages.  Granted, there are some tools to help me do this (e.g. Lex, Yacc, Flex, Bison, Coco/R, ANTLR), but it would be so much more productive and consistent if the language designers would publish at least their compiler's front-end.

Tags:   ,
Categories:   Programming
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed