Jeremy D. Miller -- The Shade Tree Developer

You are still ignoring Boo as a way to build DSL.

Check my recent posts about how to provide good editor experience to that, including intellisense.

I don't don't like Ruby (is that a valid statement?). I just don't think it is the best thing ever.

I know that this is what I am trying to do when I am building DSL.

Can you show some samples of the ideal syntax that you would like to have?

I look forward to seeing what Oslo might offer. There seems to be some similarities to it and what Charles Simonyi tried to get Microsoft to do in the late 90's (before he gave up, left, and started Intentional Software while Microsoft was busy creating the first version of the CLR).

I agree that external DSLs can be quite a bit more expressive than what you can do with an internal DSL in something like Ruby.

In the short term, I think we'll see gains with more language oriented programming ideas attracting the early adopters in business usage (e.g. more Rails-esque things). However, the real beauty and power will come when the entire stack (metal to user mode applications) is built in a language oriented way (e.g. imagine a DSL built for networking deep inside the OS). The result could be an entire system in around 20,000 lines of code. This is exactly what the NSF funded "STEPS Towards the Reinvention of Programming" project is doing now. It'll probably take a programming generation to start seeing its return, but it offers the chance for a "Moore's Law" increase in expressiveness.

I would be quite a bit more skeptical of the feasibility if they didn't have greats like Alan Kay and Dan Ingalls on the project.

The reason why I mention this is because one of the ideas from the project is a meta-language called "OMeta" that makes it really easy to create and experiment with new languages in a very object-oriented way.

I have started a basic port of this to .NET that I call "OMeta#" and I have put it on CodePlex. It's been a labor of love, but I think that the core ideas it brings could really help make creating languages to solve problems a reality. It also has some meta-system aspects to it (e.g. the interesting parts of OMeta# are written in OMeta).

It's not up to production quality yet, but I think that infrastructure tools like Visual Studio Shell and the DLR will help.

Unfortunately, it's probably not  on your timetable to be of use on this project if you're looking for a near-time release,  but I'd be interested in your take on the project given the objectives you mentioned in this post.

If you're interested in more information on OMeta# or the thought process that drove its creation, feel free to visit my blog or the CodePlex page for it.

I admire your perspective on design (especially RDD in a TDD context). Keep up the good work and I look forward to seeing how this project of yours will turn out.

@Jeff,

I looked at OMeta, and it has one big problem.

Error handling is not there.

That is, if parsing fails, I don't know why and I don't know where.

> I want the test language to be displayed in natural language as much as possible

Not going to happen.

You can get there very easily if you define sentence structure, but natural language is just not possible.

Certainly not if you want something that will allow reasonable dev time investment in any such feature.

Can you give a more concrete example?

@Ayende: You're absolutely right. I don't do a good job of error handling right now. The best I've done so far is to put in quite a few debugger step-through messages to make it at least possible to use the debugger without getting bogged down in noise. This is what I use.. but admittedly far less than ideal.

I think it's more of a statement on my poor implementation rather than the core idea though.

However, I think the germ of the idea is there if implemented well with Visual Studio Shell (e.g. debugging a grammar to be as easy as debugging a simple C# program.. highlighting productions, automatically getting syntax highlighting and intellisense from the grammar).

To do it right, you'd have to have a good meta-implementation... then all the grammars ride the wave.

I respect the work you're doing with your DSL book with Boo. I think it hits a good market for the early adopters for Language Oriented Programming in businesses. I suppose I was more attracted to the aspect of the ability of designing an entire system from the metal up using a single meta-language like the STEPS project is doing.

The side benefit that it also can help solve real business problems is pure bonus :)

"I want to use External DSL's for testing because they are much more readable and intention revealing than writing the test out in normal code, even with tools like MSpec or RSpec. "

Definitely interesting stuff and look forward to seeing what you come up with. Thats about all I can say as other than a bit of fluent interface fun my only investigation in this field has been buying Ayende's book.

Pingback from  Dew Drop - September 8, 2008 | Alvin Ashcraft's Morning Dew

I'm interested in more details about what you "love" about the Fit concept and what "sucks" about the implementation.  Is there more beyond the external test DSL (good) and the pain of wiki/HTML editting (bad)? I ask because I'm trying to get some ideas for a "reboot" of Fit.

Jeremy, I think you'll have a lot of fun with the bits in October.  

There's definitely an overlap between what we do and what MPS does, but there are also enough differences that will make both interesting.