If you had to stay alive in the jungle, who would you rather have as a companion: a) a person with a genius (Isaac Asimov/Carl Sagan level) intelligence with no survival experience, or b) an individual of moderate intelligence who has lived 5 years in the jungle?
Easy answer, eh?
Now a harder question.
If you had to hire a developer to write a line-of-business application, who would you rather hire: a) a Phi Beta Kappa (very bright across the board) Computer Science graduate who has developed important parts of an operating system, or b) a developer of moderate intelligence who has successfully written 5 line-of-business applications?
Well, that wasn’t so hard either. So now a tougher question:
If you had to hire a developer to write a new computer language, who would you hire: a) a genius developer who has already written a computer language; or b) a developer of moderate intelligence who has written 5 line-of-business applications?
Well, that isn’t really that hard a question either, as it turns out.
And now you know why computer languages are rarely designed to write line-of-business applications. The skills for writing line-of-business applications are quite different than the skills for writing a computer language. And so, unless there are special circumstances, or purposes, to the language, the computer language becomes an environment that is friendly to writers of computer languages. It’s really a matter of Range of Convenience, as it is impacted by life experience.
The exceptions are telling. Which languages have attracted developers who have to get real work done? I would start the list, in order of their birth (I think), xBase (specifically including Visual FoxPro); Visual Basic; PHP; and Ruby.
For getting a business application done efficiently (i.e., minimize time-to-delivery), what languages would you choose? Well, the same 4 as it turns out. I might add Python to the list, as its built-in data-handling capabilities make it just as easy to use, and in fact is used by many large companies for creating apps efficiently.
And that, dear readers, is why I, well we -- I have at least one volunteer, David being constitutionally incapable of not helping <s> – are creating the ProSysPlus.net Framework. .Net is a great language designed by geniuses who have never written line-of-business applications and who, unlike the original Fox team, did not have the purpose of meeting the needs of those who write line-of-business applications. And having been in the beta when READ EVENTS was created for FoxPro, I can attest that the developers, especially the late and beloved Tom Rettig, and others like Pat Adams, shaped the product by bringing their real world experience into the conversations with Dr. Dave and Janet Walker.
There is movement in the right direction within the .Net development, to be sure: reality is catching up with them. I imagine that the conversation went like this: “why aren’t VB6 and VFP developers excited about writing applications in C# or VB.Net?” “Well, they are saying it’s an awful lot harder than what they are doing now, without any benefits for what they actually do.” “So what do we have to do to satisfy them?”
That’s not completely imagined, btw, if you’ve read ScottGu’s (Scott Guthrie, now a VP at Microsoft) blog over the years. He has asked those questions in his own words, and has been overseeing the answers to them in the form of language changes and tooling that apply to the ASP.Net development world. That still doesn’t get at the crux of the problem: the changes address the development process at its periphery, not at its core.
IronPython addresses the language issue at its core, while not sacrificing the wonderfully rich .Net ecology. That’s the kind of tool I need to stay alive in the jungle of writing line-of-business apps.