Can developers use high level tools without lock in?
Last week I wrote about WaveMaker and its new Web 2.0 development environment comparing it to PowerBuilder. One of the big problems that someone pointed out to me is that PowerBuilder was proprietary. Because old software never dies, IT organizations are still coping with old PowerBuilder applications that they have to support. Does this mean that we should avoid all development environments that hide the complexity of traditional programming environments? In my view that would be unrealistic. While there are some very talented developers in the world who can do quick magic with Java, cSharp, and C++, etc.; a majority of developers need abstracted tools to do projects needed by the business on a moment to moment basis.
I remember many years ago when I spoke at a conference of developers. I told them (I think this was in the early 1990s) that whatever tools they were using would be obsolete in a few years. These guys were outraged. They did not believe me.
I think that the reality is that organizations need to use emerging development environments that offer innovation, ease of use, and sophistication that is out of reach with traditional programming languages. It is best if these emerging Web 2.0 tools can generate standard programming code (although I am skeptical that the code will represent the nuances that these tools provide). The reality is that IT organizations should understand that fads and tools will come and go. Change is a reality. Here’s a radical idea — how about retiring old code before it becomes a burden to the business.
Judith Hurwitz's Cloud-Centric Weblog 
You raise a good point. Without sounding too Godel incompleteness theorum-ish, all dev environments will ultimately prove incomplete and have to be replaced.
It is therefore up to the dev environment vendors to make this possible (planned obsolescence?) One of the things that makes WaveMaker (and probably other Web 2.0 dev enviroments) different, is our environment is built on open source, so our internals don’t look much different than any other Tomcat/Spring/Hibernate project. That means it is much easier to open up our guts, take out our code and extend it in a pure Java environment.
I will have to noodle on this and come back with my own blog post. Thanks for getting me started!
Another way to look at it, is that every tool is a language unto itself. Each tool implicitly defines a data model, methods, services, etc. When a tool is viewed through the lens of a language, though, it as seen as a language that is: proprietary, poorly documented, lacks ability to create abstractions, can’t use text editor to modify it, no type system, no command line execution, no ability to call lower-level languages and APIs, etc.
Basically, the tool is being used as a language, but the language is bad.
People generally don’t recognize that most Web applications are a complex collection of at least a dozen different languages and tools — even we they say they are using standard Java. For example, “standard Java apps” use a least a dozen languages: HTML, JSP, Servlets, JavaDoc, CSS, SQL, XML, XML schemas, shell commands, etc.
The current tools are being used to mask the language complexity, but the tool is only masking the complexity, not fixing it.
If you’ve got to use a dozen different languages to build an application, then the languages are not good enough.
That’s why I’m working on Water, a new language, that can provide the functionality of special-purpose language and tools, but in a uniform way. Then, tools can be just a different view of a language, rather the tool being a language that attempts to mask underlying complexity.