The designers of Parrot, the Perl 6 virtual machine, think not and have struck out on their own. "Why not compile to JVM/.Net?" the Parrot FAQ asks itself. And it answers: "Those VMs are designed for statically typed languages."
The irony about this is that the statically-oriented VMs are actually very dynamic-oriented under the hood. Techniques perfected for dynamic languages turn out to be just as beneficial for running static languages. The static language syntax just requires more hoops to jumped through to get to the dynamic features. Even C++ is an appropriate target for dynamic runtime techniques.
Static languages have been gaining more dynamic features for years... either by circumventing the type system as with Java and C#, or by strengthening the type system as with Haskell and ML.
One way or another, the future is dynamic.
The evidence presented from This American Life suggests that first people choose to disappear, but soon switch to the ability to fly.
I think in normal American society (where normal to me means the society I've been a part of for the past 42 years) I would also choose the ability to fly.
But what if I were living in a more tyrannical society? Like Iraq? I certainly would choose to disappear for any number of reasons.
Of course this list glosses over some other possibilities that might seem more viable if Microsoft had not illegally monopolized the software industry. People and corporations in the open source movement might prefer to market their software commercially at a fair price if there was fair competition. Investors might actually fund these ventures if they had confidence that there was some hope of a return.
I don't assume that all open source supporters are altruistic. They do seem to be realistic in today's software industry climate.
I recently read a history of the Civil War in the US. What a fucking mess that was. Sure a lot of piss and vinegar at the start. But the people in the southern US are still bitter about that war, 140 years later. A lot of people died, nasty deaths; and a lot of what people cared about was destroyed. All of us are too young to remember, that's why we have to study this stuff, and think about it.
I learned from Founding Brothers something I somehow missed in American History in high school. Slavery was clearly the most severe topic of discussion when the United States was founded, and many of the founders and first representatives had a fatalistic attitude that the issue would ultimately lead to a civil war.
Rather than face the slavery issue head-on, the government maneuvered to suppress discussion and preparation for any kind of acceptable transition. As Dave Winer points out, the result was a tragedy that has lingered to this day.
I believe an equally important issue that will have at least as great an impact and is the result of similar lack of real leadership in the government of the United States is playing out currently in Iraq. Today's issue is the lack of preparation for the inevitable post-oil economy.
Arguments that the present Iraq situation is not about oil can be convincing only if you take a short-sighted perspective. The need for planning a post-oil economy has been apparent since the 1960s, or certainly since the 1970s oil crisis.
Ideology, dogmatism, demogoguery, monied favoritism, greed, sloth, and celebrity have led us down a path of until now opaque crisis.
We should all pray for true leadership to emerge, be recognized, and be effective. Post haste.
Agreed that programmers have to deal with XML and require better support for that.
I'm not sure what should be made "native". We're still learning about XML and related standards like XSLT, XPATH, XML Scheme, Relax NG, etc.
This is another situation where an extensible language like Lisp or Scheme, or a dynamic language like Smalltalk, can be applied without overcommiting the core language designers into decisions that make sense today but perhaps not tomorrow.
One of the great ideas in Extreme Programming are the concepts of shared code to eliminate ownership, simple rules for making code transparent, refactoring to improve it, and pair programming to encourage learning and cooperation.
You can embed SQL in most languages now, but normally you don't implement any serious business logic in it. If this hasn't happened after decades in the relational world, why would we expect it to happen in the XML world?One problem with SQL is exactly that it has been embedded in most languages. The result is a continuing dichotomy between "in memory" data structures and objects and "on disk" relational tables. I'm surprised no popular language has better incorporated declarative query and update capabilities into the language definition itself.
This level of integration could cement XML formats into systems development. Tools like InfoPath and XML integration into front office tools will not be sufficient if programmers must continue to straddle an XML and procedural language gap.
XML syntax strikes me as a reasonable notation for information interchange. I am not convinced that XML per se should be built into the core business rules of our systems. The essence of a new systems architecture though should have these characteristics: