The Great Static vs. Dynamic Debate

Jon Udell writes...

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.

To Fly or Disappear?

Jon Udell likens the trade-off of Internet anonymity or capability to the hypothetical choice of being able to disappear or to fly.

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.

Rewriting Software Industry History?

Jason Matusow, the Shared Source Manager from Microsoft, via Phil Windley, would like you to know:

• Access to source code is not the primary concern for most people
• Having an option to work with the source code is important to few
• Few people who have access to the source code actually use it
• There is no "right" software development model.
• Much open source software has commercial interests.

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.

True Leadership is Too Rare

On Leadership: Dave Winer writes...

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.

XML: What should be native?

A discussion is taking place on this at Lambda the Ultimate. I wrote...

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.

Transparent Code

Phil Windley relays thoughts on transparent code. Truly transparent code is not easy to come by and is rarely taught.

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.

XML and regexp

Jon Udell writes about text, code, data, and XML. Like Tim Bray, another software master, Ward Cunningham, uses simple regexps to parse HTML tables in his fabulous FIT test framework.

While we're at it, Wiki syntax itself is Ward's answer to the complexity of HTML (XML). With FIT he invented a simple table notation for Wiki.

Attention: This RSS Feed Changing Due To Blogger Bugfix

If you are a subscriber to this Making It Stick RSS feed, please update your RSS feed according to the URLs on the blog page. They recently changed with a bug fix from blogger.

Thanks -Patrick

XML Programming?

Tim Bray writes XML is too hard for programmers, including:

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:

Semi-structured

Capable of handling formal definitions when present, along with reasonable behavior for fuzzy data by supporting human interpretation and increasingly higher-level artificial intelligence capabilities.

Dynamic

Definitions and behaviors must be modified on-the-fly without breaking existing capabilities, forcing complete re-releases of products, or requiring extensive regression testing.

Domain-specific

Significant definition and behavior modifications must be within the grasp of professionals in the system domain, i.e. non-computer science majors.

Programming in XML from Java or C# using mechanisms like threads, monitors, and two-phase commit transaction protocols are not going to cut it. And neither is a mere syntactical embedding of XML and DOM into these languages with the same old complexities.