Lambda the Ultimate

Friendly surface syntax shall enable programmers identify entities quickly and hide boilerplate. But Fowlers MPS demo language does not appear to fit the same niche as general purpose languages but more Web forms and such alike. So it competes with better situated and also more user friendly technologies. No wonder that both the intentional programming system as well as MPS are created by user interface designers who address their solution to an imaginary user group: the programming non-programmer. This ephemere P and Non-P being might exist in the realm of Excel but I can't really say it is a giant leap for the mankind to replace VBA by an even simpler language tried at home. On the other hand I might rethink my reservation against MPS in the presence of XML scripting languages for Java! *shudder*

Ah, that makes sense.

I'd hardly call Sergey a UI designer. Jetbrains produce the best development tools by far. They are *much* more than a pretty UI for text editing. They are finally helping the mainstream understand that programming is about creating relationships, not arranging text.

You could take it one stepp further and say that it would be even more simpler with a language which has sufficient functionality built-in. Instead of forcing the programer to make his/her own functions.

Even if you used a language like Lisp instead of a language like Java, this still wouldn't be enough. Yes you would have macros, code-as-data, support for higher abstractions, etc., but only in your main language. The type of systems which benefit the most from Language Oriented Programming involve several tiers, technologies, and languages. What you really need is a way to encode your intent only once in such a way that it could be used to generate/represent not only your main programming language code, but also your HTML, CSS, Javascript, Corba IDL, WSDL, SQL, stored procedures, etc. Also it would be good if you could also generate some of your on-line and off-line documentation with the same process. A single language solution is only suitable for single language problems.

Often I end up making little languages interpreted by another language or generated by a particular language, any higher level tool for managing these languages needs to take this into account. I am not sure what such a tool would look like, but I know it isn't what I saw with the meta programming system.

Maybe less like an editor and more like an OS.

...and I agree with that: the source code must not be a passive document, but something that is executed at compile time, i.e. a scripting programming language. For example, with this language, one would be able to:

1) create the database or modify it to fit the latest information model.
2) check queries at compile-time.
3) create the necessary documentation.
4) create the html code for the interface.
5) create the server code.

So a single language solution is possible, provided that it is structured correctly.

I can think of a whole host of things that many languages express awkwardly. Try coding "if condition iterate forwards through array else iterate backwards," without reversing the array (easy -- and expensive -- cheat in list languages). Is the increase in logic errors on programmers' part due to obfuscated code due to inexpressive languages insignificant?

Obfuscated code means something different for different people. For example, you make a very good DSL to solve a particular problem, but when I get hold of it, I am lost, because my way of thinking is different than yours (or I even speak a different language).

But if there was a way to declare invariants and have the compiler check them at compile time, then no matter how bad a programmer I am, the propability of an error would be very close to 0.

I kind of had the same feeling as you: There isn't much in there which isn't mostly solved by Lisp already. One may like or dislike the surface syntax of Lisp, but with the aid of hygienic macros creating DSLs is easy as pie, and your IDE/editor will even be able to understand the basic syntax of your DSL to some degree -- at the very least to the degree where you can do syntactic refactoring very easily. If you don't want your DSL to have a Lispy syntax you could always put another surface syntax on it (as you mentioned).

If you want your IDE to understand more of the DSL's syntax beyond the syntactic elements you could always create a plug-in for your IDE. The IDEPlugin interface might be worth standardizing though I'm pretty skeptical as to whether that's (politically and practially) possible.

Ignoring the fact that it is often said on LtU that syntax is easy & semantics difficult... I'll wonder aloud if it would be useful/possible to dream of a "wizard" that would generate a DSL template for you after asking questions like "what kind of base syntax do you desire: 1) s-exprs 2) c-style block imperative structure [etc.]"? If it asked enough questions it could perhaps generate an IDE plug-in for the syntax which might be nice. Ideally it would generate a parser etc., and work in a very iterative fashion to let you refine your semantics.

DSLs are extremely cool if they are used at the right time in the right place and are designed well; lowering the barrier of entry to them might be beneficial to the software engineering world in general. (At least people could more easily try out a DSL and dis/prove that it is the way to go for a given issue.)