Or are we just in danger of running out of acronyms!?!
I just re-read this short article “Software Is Too Darn Hard” by Rockford Lhotka, which talks about software from the users perspective and how most changes in languages over the last 10 – 15 years have had very little impact on improved experience for end users. (Don’t be put off reading it by the comment about a ‘rant’ at the start…)
“Expressing business requirements in software would be more efficiently
done by people who work in the business, who understand the business, language
and culture; and who have tools that allow them to build that software rapidly,
cheaply and in a way that actually meets the business need.”
The reason VB was so successful was that it enabled the people who work in the business, who understand the business, its language and culture, to cheaply and rapidly build software that actually meets the business needs.
Problems are encountered in areas where the language no longer enables non-programmers to accomplish their goals, or does so in a way that is prone to misunderstanding and mistakes. This also applies to programmers and was borne out by framework usability studies done by the designers of the .Net framework (as described in the Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina).
That’s why I believe there is a real need for a ‘new’ VB, and that the LINQ ‘flavours’ are huge steps in this direction. Why should a domain expert have to be versed in the subtleties of writing an N-tier application, consisting of lengthy boilerplate code, when the tools should perform this task and generate it for them?
If tools did what they were supposed to do (model the business needs, make us more productive by reducing the amount of code we have to write, and therefore create software faster) domain experts would be in a better position to create solid, useful software, and in the process bring the software closer to the users’ needs and expectations. In other words, helping to put the user back into software.