I have a slightly different perspective. The adotption of managed environments (the combination of JIT VM's and automatic memory management) is a long overdue development in the evolution of software development, but we haven't arrived. There is a lot of room for improvement in the languages that we are using to today. The JVM and the ecosystem around it are focused on Java. Yes, there are implementations of lots of other languages on the JVM. Yes, some of them talk to Java. But for non-technical reasons, the JVM is going to be focused on Java, and for reasons of compatibility Sun is going to continue to evolve the JVM very slowly.

I'm interested in a managed environment that can still evolve and grow. Microsoft is claiming that this is what they want. I'm not sure that I believe that they will continue to evolve it. But it doesn't matter. Mono provides a managed environment that can evolve. It has compatibility with the current ECMA CLR and will continue to. Compatibility to the MS CLR is nice, but Miguel says that they have Mono running on Windows as well. So here we have an open source, potentially evolvable managed environment. If the Mono guys can get just the ECMA specified portions of the CLR running well, I think that this is very interesting. I'm interested in seeing continued innovation at the runtime level, and that's not really happening with the JVM. What is happening is improvements in the quality of implementation. I'd like to see the Mono ECMA CLR, with a switch that can be flipped to go into Microsoft compatible mode, however compatible that turns out to be, for whoever cares to be compatible. But I'm just as happy to see an open source CLR based runtime evolve starting from what is Mono today, and if it forks from the Microsoft one (due either to Microsoft changing theirs or the open source one changing), I'm not bothered by that.

So, am I a heretic yet?

Then we go on to build managed libraries that provide Windowing API's, etc. Then Haskell.CLR can actually talk to the rest of the computer, and we get to a place where everytime we want to innovate in the language space, we don't have to throw away the ability to do useful stuff. That's been the single biggest problem with adoption of "advanced languages" is that they can't talk to the rest of the computer, and they can't leverage any existing library code. I think that a scheme such as the one I'm proposing might actually work.

People will suggest that open sourcing the JVM would solve the problem just as well. Possibly, but I've given up hope that Sun will decide to open-source Java and the JVM. Even if they do, they'll encumber it with something like the JCP. Unfortunately, in my opinion, the JCP is not in the innovation business. It is in the keep things under control business. If you look at the number of Jakarta projects that are used in all kinds of software projects, you realize that things don't have to be standardized by the JCP in order for them to be adopted broadly. I want to see something that can grow and evolve and where the best code can win.

Maybe I really am a heretic.

As I've started to play with Python, I find myself reliving some of my Lisp experience at MIT. I find the Python code to be very succint and easy to read -- I find that I don't mind the use of space / indentation as syntax. Since I indented my lisp code all over, so I find that I am not noticing this at all. The notation that python provides for lists and maps is one of the things that is making me very productive. The combination of list comprehensions and slice notation is very powerful and makes programs shorter. These two notions are things that Java could benefit from, but there's almost no chance that we'll see them, because Sun is so committed to not evolving Java the language. If Java had macros, we could implement some of this stuff nicely.

One thing I haven't yet gotten used to is the Python object system, which requires each method to have an explicit self parameter. Having used Lisp generic functions, this should be no big deal for me, but having worked mostly in in C++ and Java for the last 7 or 8 years has kind of braindamaged me. It'll probably take a little time to shake that out. Interestingly enough, David Mertz has implemented multimethod dispatch for Python. I haven't played with this, but it does provide another proof point for the saying that all languages are destined to reinvent Lisp badly.

Anyway, back to Eclipse and prototyping. I think that if the refactoring tools are taken far enough, and Java had a kind of macro language, I would be pretty happy. I'm back to using Emacs to edit python, which is fine. The only things I miss are integrated help / code completion and refactoring tools. Oh, and a reasonable interface to the debugger.

Crossroad rocks for an event like this. It has a food court, a big open space and public access 802.11. The only thing I could think of that was missing was a bunch of power strips.

I love how you can find an unexpected blessing at an event like this. A bunch of us were sitting around talking XML geek talk. Don Box and Miguel de Icaza were talking about RelaxNG / XML Schema. Miguel was doing the standard "RelaxNG is so much simpler" bit. Don pointed out that James Clark has a tool, trang, that will convert RelaxNG schemas into W3C XML Schema. He went on to point out that if all you wanted RelaxNG for was a simple syntax, then why not just write RelaxNG and then use those tools to convert them to Schema. At that point, the lights went on for me. At the last ApacheCon, Andy Clark and I talked about how much work it would be to adapt Jing to use the Xerces XNI instead of SAX, with the goal of being able to plug the adapted Jing into Xerces so that Xerces would have support for RelaxNG. We thought that this would be a way to help more people use RelaxNG. I actually had started to do this a few weeks ago, before working for food took priority. After Don's comments, I decide that using James Clark's trang solves the problem that I wanted to solve, without importing another large code base into Xerces. RelaxNG advocates will go on to tell about the schemas that RelaxNG can express that Schema can't, but I don't care about those cases. Saved me a few weeks work that can go towards other efforts. That alone made it worth the trip.

Miguel was giving demos of the latest Mono drops, including a Mono base photo browser. He also showed a compiler bootstrap -- something only a geek could love. I noticed that many of the Microsoft folks were paying very close attention to what Miguel was showing and seemed very impressed and complimentary towards it. Joshua Allen has already commented to this effect. I have a few more thoughts on Mono/.Net/CLR that I'll save for another post.

Sam and I talked about blosxom hacking, python and pybloxsom hacking. I think it would be awesome if Sam decided to switch to using pyblosxom. The other thing that we talked about was doing a version of the Weblog/Metaweblog APIs using SOAP instead of XML-RPC. There's a technical reason for doing this, which is that there's no way to multiply categorize an entry using an XML-RPC based API. As I've posted before, I think that this is an important feature for blogging software to have. This would also be a wonderful API to use to consolidate comments and the various kinds of *Backs s that have been proposed.

Two other notorious bloggers that I met were Dare Obasanjo and Josh Allen from the XML core technology team at Microsoft. I was especially pleased to hear Dare say, many of the people using XML would be just as happy with s-expressions, something that I've been saying for a while now. I know, we ex-lisp hacker whine alot.

The next steps will be to figure out what to do about retrieving jars from a "central" repository, and also to decide how to handle jar versions. Depending on how fancy we want to be about deciding whether one jar version is as good as another. My thinking on this is to do something simple that can be deployed, and then make it smarter about version numbers as we go. Not being smart about version numbers means that we'll have multiple copies of jars in the jar cache.

Feedback, ideas, and bugfixes welcome.

P.S. Articles like this one are why I was hesitant about the blosxom family of blog software. Which category does this article go in? Python, Java, Perl? It could be in all of them, but its going to end up in general programming instead.

Steve is one of the Axis developers, and his talk was about web services interoperability -- actually he later confessed that he was trying to scare us about all the corner cases that create interop problems, but that basic stuff works. Some problem areas were things like Java's lack of unsigned types, which make it hard to interop with web services or clients written in languages that have unsigned types (C/C++/C#), people's expectation that they can send Java collection classes, or java.io.File's.

One of the more interesting comments that he made was that the DOC/LIT style of using SOAP is the future. I've been hearing this statement made more and more. This has been my thinking for some time now, so it's good to heat that other people think that this is true.

As an aside, does anyone out there in blogland have a recommendation for a good web services stack written in Python?

I was pretty interested to hear what Rebecca Wirfs-Brock had to say. Designing Object-Oriented Software was one of the first O-0 books that I read as a grad student back in the late 80's, and I've always appreciated the CRC method as a lightweight yet effective mechanism for design. Rebecca has a new book out, which looks like it elaborates on these topics. It's hard to say, because she didn't talk about the book directly. Instead, she talked about "Skills for Agile Designers" . Part of her talk was about Agile methods -- she's not in the fundamentalist Agile camp. The next section her talk covered "Tools for Seeing" -- ways of looking at a system to bring the key design criteria into focus. She talked about stereotypes of object roles as a way to bring out the issues that will need to be dealt with. This is intended to be a generative sort of approach -- if an object is acting as a coordinator, then the design is likely to solve the following problems, etc. She also mentioned how this perspective helped to appreciate Peter Coad's use of color in UML diagrams. Someone in the group pointed out Streamlined Object Modeling as a good resource for this kind of philosphy. Another interesting topic was the use of JavaDocs as a way to yank stuff back up and map it back to CRC cards (if you were using them). The idea is to have a custom doclet that pulls just the descriptions for class and method comments and renders them all into a big page(s). This can then be used to try to trace stuff back to the CRC cards to make sure everything was covered and nothing was gold plated. The final section was called "Tools for Shaping Solutions", and included a discussion of Problem Frames by Michael Jackson.

I really enjoyed her talk but found it to be more focused on object design/modelling and less about finding balance in the application of Agile methods. Wilhelm pointed out that her audience is probably normally people for whom object modelling = RUP, and so in comparison a lot of the techniques that she covered were Agile in comparison. Since this was a 3 hour talk compressed into 1 hour, there were probably lots of things that got left out. All in all an evening of quality presentations, and of course, some good beer and conversation afterwards.

Turns out that Jive is releasing a commercial Jabber server, and as part of that effort, they've developed an open source Jabber client library in Java called Smack. The only other Java Jabber library that I know of is JabberBeans, which wasn't being maintained much when I looked at it last. If you're interested in Jabber, check it out -- I know I will.

I got to hook up with Bill again, and I got some nice Smack out of it.

jar-id: a string representing a unique id for this jar
jar-version: a string representing the version identifier for this jar
jar-dependencies: a comma separated list of jar-id#jar-version tuples which
                 specifies the jars that this jar directly depends on
                

If all jars embedded this information, then we just compute the set of dependencies needed by the application (root) jar, get those that we don't have, compute their dependencies, and repeat until we have all the jars.

Ted Neward wants a new JSR that will deal with the issues of versioning and Jar-to-Jar dependencies.

Markus Kohlher thinks (and I agree with him) that we should specify the dependencies (and versions) within the jar files. He points out that the jar file spec already defines a Class-Path attribute.

A number of solutions to this problem have been proposed, but none has really come to fruition. At the ASF, we've had jjar, cjan, and now Maven. There's also a cjan project at Sourceforge. There might be even more than this.

This is a problem that needs to get solved -- a number of people are taking cracks at it. I wonder -- is there a way to get this happening faster? I know Ted Neward is interested in a JSR and Markus is working on code. I've looked at the jjar code a while ago and talked with some Maven folk about this problem at ApacheCon.

As for the notion that open source's usefulness to opponents outweighs the advantages to users, that argument flies in the face of one of the most important principles in security: A secret that cannot be readily changed should be regarded as a vulnerability.

It isn't that secrets are never needed in security. It's that they are never desirable.

It's simply unrealistic to depend on secrecy for security in computer software.

The secret to strong security: less reliance on secrets.

Sam -- feel free to give me an e-mail smack whenever you like if anything else like this happens.

If anyone else is having problems with the domains, please e-mail me and I'll turn them off until your aggregator can deal.

Today Bill de hÓra wrote about fixing the classpath mechanism by allowing it to read from an XML file. The problem with this solution is that people keep their jars all over the place, so you've just moved the problem around. Even then, you have the problem of getting the various version dependencies right.

One of the comments references Uberjar. I can see the appeal of this approach, because you ought to be guaranteed that you get all the right versions. I'd prefer to see something that didn't copy jars all over creation, even if disks are cheap now.