|
|
|
 |
<< Monday, August 09, 2004 >> |
|
A strategic vision for dynamic languages
As operating systems consolidate around managed interfaces, they'll choose the Java and .Net VMs, not the Perl, Python, or PHP VMs. But the agility of the dynamic languages and the collaborative energy of their open source communities are two of the pistons that crank the engine of progress. These worlds need to converge -- and at the O'Reilly Open Source Conference there was new evidence that they will. Jim Hugunin, father of Jython (Python for JVM), made a pair of dramatic announcements. He has released the first version of IronPython (Python for CLR/Mono). And by the time you read this, he'll have started his new job at Microsoft. Good hire! [Full story at InfoWorld.com]
In my keynote talk at the Vancouver Python Workshop, I stressed the strategic importance of integrating dynamic languages with the Java and .NET runtimes. I've written a lot about dynamic languages and yet, when asked to define what they are and why they matter, I struggle. So from now on, I'm going to point people to this whitepaper by David Ascher, who is the managing director of ActiveState and led the development of Komodo, a Mozilla-based IDE (integrated development environment) for dynamic languages.
Ascher's whitepaper lists a series of challenges for dynamic languages. Topping the list is Lack of strategic vision:
To date, dynamic languages have not been driven by strategic plans. In fact, most successful open source projects (Mono and Gnome being notable exceptions) have enjoyed success in spite of a lack of a long-term plan, let alone a clearly defined vision. The pragmatic, tactical approach to fix what's broken today as opposed to anticipate the problems of tomorrow, has, when combined with the selection processes inherent in the open source ecosystem, led to a survival of the fittest for today's problems, rather than rewarding those with the most compelling vision for future success. It's worth asking if the lack of a plan is guaranteed to be a winning approach in the long term. A good example to highlight here is the different approaches toward newer standards such as SOAP, evident in dynamic languages vs. Java and C#, for example. The dynamic language communities are generally content with letting "someone else" worry about the standards-definition process, and are confident that they'll be able to support them when they are defined and stable. In contrast, Microsoft and Sun have committed significant resources to defining the standard, for clearly competitive, non-altruistic reasons. It is reasonable to expect that the resulting standards have been more influenced by how well they fit with those languages than with languages that got involved late in the standard-definition process. In this case, the combination of strategic planning and the resources of large corporations clearly resulted in shifts in the standard toward more strongly-typed languages. An interesting counter-spin is that dynamic language enthusiasts tend to prefer a different approach to web services over SOAP (namely REpresentational State Transfer, known as REST), which (they claim) is simpler, more pragmatic, portable, robust, and less resource-intensive. [David Ascher]
This statement resonates with a number of things I've read lately, including Sean McGrath's remark that "anyone coding middleware in a statically compiled language, working in a commercial environment where time is money, has rocks in their head," and Adam Bosworth's comments about the relevance of REST and lightweight XML-over-HTTP to a services organization such as Google.
Shortly before Bosworth left BEA for Google, we met to discuss the Alchemy project. He remarked, in passing, that he thinks there's a 40% chance that SOAP may still fail. I hope he's wrong. We're going to need a fabric of pervasive intermediation, and the TCP/IP of Web services -- that is, SOAP -- will enable that. But we're also going to need a whole lot of agility woven into that fabric. I want middleware that works like Indigo, but I want to program it in a language that works like Python.
|
|
Tragedy of the network commons
A recent survey found that 75 percent of Dartmouth students have shared their network passwords. They like having people who know their password, explained Denise Anthony, a sociologist who spoke at the PKI summit conference I attended earlier this month. "They like having someone who can check their e-mail for them or log them in to places where they're supposed to be."
...
As security technologists, we're easily dazzled by our shiny cryptographic swords. But while we're brandishing our swords, our users -- like Indiana Jones in that famous scene from Raiders of the Lost Ark -- might simply pull out their guns and shoot us. Better security protocols alone can't thwart such game-changing behavior. We need to understand what motivates the behavior and figure out which carrots and sticks will influence it. [Full story at InfoWorld.com]
The responses to this column expressed a mixture of hope and resignation. The hope: that in a token-based authentication regime, tokens will feel more like personal property than passwords do, and that as a result, there will be less promiscuous behavior. The resignation: that, as one reader put it, "there is no access control system that is so convenient that some significant percentage of users will not intentionally circumvent it in one way or another at least some of the time."
The takeaway point, for me, is that Dartmouth's team of security researchers includes a non-geek whose role is to try to understand the motivations and behaviors of users. This kind of cross-disciplinary approach is the exception. It should be the norm.
|
|
|
Recent Entries
|
|
NEWS 
