Bob Warfield’s SmoothSpam blog has a nice post about how creating software as tools and languages would reduce the risk of development.
I’ve written before that if an area is important enough, it eventually becomes a language. We’ve watched it happen over and over again, sometimes in the most unlikely places. For example, Adobe made it’s start by turning printing into a language called Postscript. It gave them enormous advantages over the competition.
He suggests that in a team of 10 developers only 2 or 3 would be the language builders, something that clearly reminds Fred Brook’s Surgical Teams. I’d generally agree with that but I’m not sure it will work until a get a real feedback from a large LOP-Driven development project.
He goes on and says:
Second, delivering a tool sounds like a nightmare for users. What do you do if your users are not technical? Just because you’ve delivered a tool doesn’t mean you have to leave sharp blades and flaming torches hanging out of the toolbox. Nothing is easier to attach a user interface to than a language. That’s one of the great beauties.
Here I strongly disagree. After decades of programing languages it is still very hard to find a useful visual development environment. The best tools for development we have (emacs, Eclipse, IntelliJ, TextMate…) are merely Domain-Specific text editors. The tools he talks about are generally only available for languages that were created in a philosophy where the runtime, the editor and the language are tied, like Smalltalk or Common Lisp.
Phillip, thank you for picking up my post on your blog. I want to correct a slight misapprehension. I’m not suggestion a visual programming environment in that second paragraph, although I have absolutely nothing against visual programming. There are some great ones out there.
Rather, I am suggesting most users don’t need to write programs. They need a normal sort of user interface that instead of making API calls, generates calls into your domain specific language. That combination is extremely powerful.
Cheers!
BW
Hi Bob, good to see you around.
I think I was bit vague on my criticism, let me try to explain it better.
I ddn’t think you were talking about visual programming. You wrote about domain-specific programming languages and your text stated that it is easy t attach user interface to a such language. It is a true statement in two scenarios:
1 - A very simple language (like BPEL)
2 - A language that was conceived with that interface in mind
What computer science has taught us the the last few decades was that it is very hard to get a visual tool for a language (domain-specific or general purpose) that wasn’t built with that tool as a requirement.
Let’s take Java as an example: it’s a 10+ years old language and it has nothing but fancy text editors like Eclipse or IntelliJ. Those editors are very useful and powerful but to use those you still have to know a lot about the underlying language (Java). Educational projects (BlueJ) and all major software companies in Javaland have tried to build a completely visual tool to use the Java language but all failed miserably. Java was created to be a text language, you can have an editor like IntelliJ that will parse the source files and try to bring abstractions as visual elements but it won’t help you get rid of writing code by typing it in the correct syntax.
On the other hand take a look at Squeak. Squeak is a Smalltalk implementation and Smalltalk is not only an object-oriented language it is a full development and deployment environment. Inside Squeak code will be shown in different ways, most somewhat graphical. Its eToys scripting feature was even added to the OLPC project and once you get used to the tool you won’t take notice that you’re doing Smalltalk.
If we have a fairly complex language, being that a DSL or GPL, and do not think of the user as the developer using that language -I mean, get an user-friendly editor- at one of the language’s fundamental concepts it will not be easy to get one after the language is built.
I’m not saying that this is not possible or anything. The point is that it is not just because you’ve got a language that it will be easy to have a UI to it, depends on how your language was built.
This subject reminded me of the Naked Objects approach. Although it is not really LOP-related it represents a step into that language-UI thing. Check it out.
Cheers and keep the good work