" /> Bill de hÓra: August 2004 Archives

« July 2004 | Main | September 2004 »

August 31, 2004

Phew

Python ships with stringprep (as defined in RFC3453). I hadn't noticed that before. For a short while this evening, I thought I might have to implement it.

Books

On programming, the cookbooks and notebooks and actionbooks and handbooks and essentialbooks and practicalbooks and appliedbooks can grind you down. Sometimes it's good to absorb material other than learning how to do something expedient really really quickly.

I'm on my second reading of Tom Passin's book. I wish it was people's first exposure to the Semantic Web and not stuff like the American Scientist or Metacrap articles. Tom's book balances Semantic Web hype and potential. If you have strong preconceptions or objections to the AI aspects of the Semantic Web (or you simply think it's a crock), this book might offer a pragmatic enough explanation of the stack to be convincing. The key questions that remain for me as a practitioner and were not answered by this book are, how do I map RDF 'assembler' onto the kinds of domain models developers use every day, and not unrelated, what's the upgrade path for something like the Petstore Demo?

Robert Sedgewicks Algorithm's in C++ part 5 (!) is all about graphs and their algorithms. I've been getting around to reading this for years, and finally picked it up last week. I have a mild fascination for graphs, but this was one of those texts I had filed away as something you're 'obligated' to read because it's good for you. It turns out to be beautifully written and presented, so much so, I didn't really mind the fact that the examples are C++ pseudo-code. It's also made me realize how rusty my computer science has gotten; I'm definitely struggling in places. As every tutor I ever had in art college told me; keep your hand in.


The third is Paul Graham's Hackers and Painters, a compedium of his online essays. While not popular in the Java community right now, Paul Graham is one person who's writing I end up going back to (along with Richard Gabriel, and Philip Greenspun back when he was a technologist). Graham is something of a techno-contrarian, and I find some of his arguments inconsistent, but I suspect some of these essays will stand the test of time after reading them in book form. This is probably a good book to give family members and friends if you've been unsuccessful in explaining why programming is absorbing and fun (tell me the guy on p86 wasn't having fun), or perhaps if you're entertaining thoughts about doing something insanely great.

I love the tone and consistency of writing in the Economist. I don't love the tone and consistency of writing in this blog. I'm finding this a hugely useful and informative book. And very readable for a reference, but that's what you'd expect.

August 30, 2004

302 Borked Framework

[Update: Phil Jones sent a link to something he wrote about Struts and MVC many moons ago.]

Expedient advice if you're writing web apps in Java frameworks such as Struts.

Some outtakes:

"The convenience of caching affects standard behavior... Result page must not be returned in response to POST request, because attempt to reload it would cause double submit problem. Instead, browser must load result page separately, using GET method... Caching must be prohibited for web applications... The answer to double submit problem is redirection... It is interesting that PRG pattern exploits non-standard behavior of browsers and web servers."

Unfortunately client-side redirection is not without its problems. This article assumes the network is reliable, latency is zero and Java frameworks are architecturally significant :) But, HTTP is an unreliable stateless protocol. Redirects and magic tokens can't help if the webapp crashes or the network goes to hell between a submit and a response, or the upstream payment server times out, or someone uses a spec-conformant browser (don't even get me started on promoting a software pattern that relies on browser bugs :).

An alternative answer to double submit is to provide the client with a one-shot URI that can be submitted to at most once. The second time that request reaches the server it can tell the user the action has already been performed. Caching you don't have to worry about because the URI was sent for use in a POST method not some combination of GET/pragma/transaction-token. GET can be used for telling whoever is interested the status of the request (the URI can also act as a ticket for long running orders).

The problem here as much as anything are the frameworks we're stuck with in Java. MVC is web poison.

August 29, 2004

Mailing list decorum

When we are operating on an online forum that exists in order to get something done, then we should not think by being rude, obnoxious, a mindreader, perverting another's position, denigrating someone's else's argument to boost our own, is a basis for convincing anyone as to the merits of our position. We would be spectaculary wrong. We would not seem intellectually formidable. We would not seem overtly intelligent. We would not seem understandably frustrated and impatient with the evident stupidity that we see in others. We would not seem like someone good to work with.

Such forums do not work like modern election campaigns.

"Rudeness objection"- Ron Jeffries

Ron Jeffries, on the extremeprogramming list, has over the years demonstrated a successful "broken-windows" style technique for curbing obnoxious and ad-hominem posts that lack any technical or social merit. It's very simple; if someone's is being obnoxious, call them out on it. Voice an objection. Don't let it stand.

"The ideal attitude to project during any argument is one of calm disinterest."- Charles Miller

Charles Miller offers two useful rules from an excellent short essay on online argumentation:

  1. State your case
  2. Clarify any misunderstandings

It's easy to forget where we are and what we are doing when discussing things online. It's especially easy to forget that on the Internet those are real people posting, not dogs.

August 28, 2004

Isolates!

Weiqi Gao: ClassLoaders Are Not Processes.

August 26, 2004

Jena SimpleSelector: hmm, oops, ah, ugh

From the Jena Tutorial on sourceforge:

This selector will select all statements with a subject that matches subject, a predicate that matches predicate and an object that matches object. If a nullis supplied in any of the positions, it matches anything; otherwise they match corresponding equal resources or literals. (Two resources are equal if they have equal URIs or are the same blank node; two literals are the same if all their components are equal.) Thus:
            Selector selector 
               = new SimpleSelector(null, null, null);
will select all the statements in a Model.

Hmm.

    JenaReaderTest.java:124: reference to SimpleSelector is ambiguous, both method 
    SimpleSelector(com.hp.hpl.jena.rdf.model.Resource,com.hp.hpl.jena.rdf.model.Property,
    com.hp.hpl.jena.rdf.model.RDFNode) in com.hp.hpl.jena.rdf.model.SimpleSelector and method 
    SimpleSelector(com.hp.hpl.jena.rdf.model.Resource,com.hp.hpl.jena.rdf.model.Property,
    java.lang.String) in com.hp.hpl.jena.rdf.model.SimpleSelector match
          Selector selector = new SimpleSelector(null, null, null);
                              ^
    1 error
    BUILD FAILED
    E:\home\propylon\200.200.200.11\svn\iams\trunk\events\build.xml:114: 
    Compile failed; see the compiler error output for details.

Oops.

Ah.

   Selector selector = new SimpleSelector(null, null, (RDFNode)null);

Ugh.

Javaspaces, bitte...

August 25, 2004

Jython in Eclipse: Red Robin

Nice Jython plugin for Eclipse: Red Robin. Class browser. Class outliner. Auto complete (sort of). Definition clickthrough. Stacktrace clickthrough. And the docko's good too.

I'll be keeping Eclipse then ;)

August 23, 2004

Hip Priest And Kamerads

".NET needs a stronger, more vibrant open-source community to counteract the innovation that's been coming from its competitors' communities." -Ted Neward [emphasis added]

I don't know. I think open source as mostly a fun thing that happens to be useful in paid work too. A competitive weapon between platforms is not my first thought as to what it's good for, but sometimes it seems inevitable...

August 22, 2004

Java unhinged

Tim Bray talks about Sun needing to build "Back-door Tech". Ok, so here are some suggestions for the Java back door:

  • Get behind Jython.
  • Tighten the J2EE/JCP feedback loop.
  • Provide leadership for web frameworks.
  • Get the SCSL out of the way.
  • Support the Eclipse consortium.

Get behind Jython. Here's a major theme of open source innovation in Java over the last 3 years - use anything but Java for app coding. That suggests a significant fraction of Java geeks are chomping to get off Java for someting more flexible and 'ready to hand'. The natural choice is to run fully featured scripting languages on the JVM (not Bizarro-XML roadkill like Jelly, or JSP+EL). But here's a very important thing - we don't need new language development*. Jython is sitting there, ready for prime time. In the meantime, Microsoft, with one smart guy for pay, have the potential to make scripting mindshare on the JVM dead on arrival. IronPython is why. The enterprise computing upgrade path for millions and millions of VB.NET and ASP.NET developers is probably going to be IronPython. Visual Studio support will surely follow. Game over?

Tighten the J2EE/JCP feedback loop. In Tim's terms, the J2EE has no back door. It took a ong time for the JCP to acknowledge that those in trenches knew EJB and other J2EE doodads had issues in a way that couldn't be papered over with visual tools and enterprise patterns. Huge pressure bubbled up from the developer community in the form of OpenSymphony, Spring, Pico, Hibernate and bestselling books like Bitter Java and Bitter EJB. This lack of feedback seems to result in disdain for J2EE as a development platform and produces one reactionary OS project after another addressing the same issues (the web frameworks situation is so bad it's getting its own section next). Some of these projects are valuable, but some result in buyer's regret and legacy issues if the project dies as the leads go off to do something else cool without leaving a community behind them (Hani Suleiman deserves immense credit for highlighting this problem). Today, a significant issue is how the J2EE learns to fits with integration styles where the Web, documents, messaging, interop-uber-alles and most importantly, tight budgets, dominate.

Provide leadership for web frameworks. The Java web framework situation is so stupid, it's not even wrong. Sun, taking a leadership role and focusing the community on the goal of adopting a single web framework would be wonderful; Struts wasn't quite it, and JSF looks like a web framework that's in denial about the web. I think for Java to be competitive with the LAMP stack, Isolates and full support for scripting are prerequisites, so we might have to wait for a while.

Get the SCSL out of the way. Sun's SCSL and the general approach to open code is confusing. Very confusing. And absurd - witness the Geronimo committers typing in the J2EE APIs by hand because of distribution issues around licences. SCSL is very much front door thinking; no developer wants to be distracted or stifled by something like that. For Jini and JavaSpaces, the licence seems to be actively harmful in terms of code sharing; the outcome is that one of the most exciting platforms for the service oriented style is a hacker unfriendly one.

Support the Eclipse consortium. I understand this is a contentious view, but the Eclipse community and user base is thriving. Arguably, if Sun vanished tommorrow, this is where Java would end up - that's how strong this community is.


* Regarding Groovy then. I've very happy that Groovy exists as it attracts the right kind of focus, but sad that it had to be invented. I also think that it will take a lot longer than expected to finish Groovy - good language design is too hard to just dash off in a couple of months. In one sense it's the wrong answer to the right question.

August 21, 2004

MetaGraph: Domain knowledge v RDF

Here's a powerpoint on MetaGraph, a means of explicitly working with the investigation of relationships and hypotheses for biological experiments.

These folks went through the standard Object Relational two-step and found it wanting, because what they wanted to do was reason and hypothesise about relationships between data items, and not so much the data items themselves. They ended up with what AI folks might think of as semantic networks or conceptual graphs, and what Web folks might think of as RDF/OWL. After that, they threw in a query language, and an ORM persistence framework. I'm seriously impressed.

What's very interesting to me at the moment about this is the way they seem to have managed the dissonance between a general labelled graph model and the domain specificity of biology. I've hit just this problem with RDF, in an entirely different domain. The domain is events: namely arbitrary system and application events from multiple sources supporting a Service Oriented system. The events can be almost anything that happens below or in support of business level document exchanges - things like seeing a document pass by, touching a document, intrusion alerts, downed servers, log file analysis, any number of different warnings or failures, even something as mundane as as the result of an automated disk space reclamation or a db backup. While the exchanges are cleanly defined the ancillary data that results is usually not. Much of the data is low grade, has poor signal/noise ratios, or is incomplete. RDF so far, is appearing to be a good choice for packing up this kind of 'telemmetric' data into events. But it seems that, aside from the usual hurt that comes up around RDF v XML, there is a tricky balancing act that needs to be done between the 'ilities' provide by RDF statements and the immense value that comes from articulating your domain. I hope to have something more to say about this tension and what we're doing around it soon.

The other thing that is always fascinating about bioinformatics whenever I take a peek is the sheer volume of data these folks are contending with, in a decentralised, semi-standardised and by the looks of it, competitive, environment. The data sets are jaw-dropping - this is the world where Jim Gray ships the computers containing the data instead of using the Internet. The ability of the bioinformatics community to find a mix of hardware and software solutions as they go, without a whole lot of prior art, is formidable (bioinformatics also seems to be a driver for innovation in Grid technology). And yet, it's not so hard to imagine a future where we have to manage terabytes of data for a medium enterprise, and one day perhaps for ourselves. We, that is, Web, WS, SOA, REST types, spend a lot of time looking at what the likes of Google, Ebay and Amazon are doing to help us peer into the future; innovation in bioinformatics may also be useful in thinking about architectures to meet future demands.

August 19, 2004

Lightweight Java

  duke.gif

  __

August 18, 2004

Assron

Why specs matter.

August 17, 2004

RFCs make me want to smoke crack

Paginating RFCs is fun, fun, fun. This is me using ctrl-enter in Word to pagebreak draft-ietf-xmpp-core-24:

rfcs-suck.PNG

"On the other hand, they require two spaces after a period, which is vile, but is is actually just a symptom of the IETFs misguided insistence on publishing key documents in a format (66-line 80-column ASCII) that is outdated, unusable, and offensive. Outdated because it sneers at the ability of computers, for some decades now, to use proportional fonts, which have been shown repeatedly to improve the efficiency of information transfer from page to brain. Unusable because a substantial proportion of people, including me, can never get the bloody things to print properly with the right page breaks (well, they say, use the PDF of the ASCII... argh, words fail me). And offensive because it restricts its character set to that of English speakers. " -Tim Bray

If you can't type them, join them

Here's Martin Fowler on frigging with base classes:

"Many people get very disturbed by this kind of thing, but it does a great deal to simplify the logic of code that sweeps through the composite structure. I think of it as getting the leaf class (elephant) to provide a simple implementation as a courtesy to its role as a node in the hierarchy."
          class Elephant < Node
            def num_elephants
              return 1
            end
          end

I would go a bit further, and make this useful for non-Elephants. In 'Scruby' (Statically Compiled Ruby):

  class Node
    def num(type)
      if type is Node 
         return 1 
        else 
          return 0
    end
  end

Now subclass it where the Elephant Node returns 1 when supplied its type. Why? Two reasons. First, putting Elephants in boxes is just the beginning. More frigs are bound to occur, resulting in you AddingMoreStuffToTheBaseClass. That way lies honest to goodness Lovecraftian madness (or the DOM). Second, if you're going to make a hack, you might as well make a judicious hack so that you or someone else can dig your way out later. Above you've got the option to send a message to all types of Node and they can decide for themselves what type they are.

There are other ways to deal with this, the ultimate choice depending of course on the language at hand. For folks programming with composite structures in Java or C#, these guys have it nailed.

While the term CourtesyImplementation is tad Newspeak, it's good to see an industry leader outlining a trade-off instead of a fantasy world where trade-offs Just Don't Happen.


[franz ferdinand: michael]

August 16, 2004

Why do people check Javadocs into version control?

Every now and again you run into an open source project that has its Javadoc checked into source control. Why fill your source tree with html when it can be generated on demand from source?

Add Nothing But Value

From Mary Poppendieck's Lean Thinking:

"It is sometimes thought that a benefit of good software engineering is to allow low skilled programmers to produce code while a few high skilled architects and designers do the critical thinking. With this in mind, a project is often divided into requirements gathering, analysis, design, coding, testing, and so on, with decreasing skill presumably required at each step. A 'standard process' is developed for each step, so that low-skilled programmers, for example, can translate design into code simply by following the process.
This kind of thinking comes from mass-production, where skilled industrial engineers are expected to design production work for unskilled laborers. It is the antithesis of lean thinking and devalues the skills of the developers who actually write the code as surely as industrial engineers telling laborers how to do their jobs devalues the skills of production workers. Centering on the people who add value means upgrading the skills of developers through training and apprenticeships. It means forming teams that design their own processes and address complete problems. It means that staff groups and managers exist to support developers, not to tell them what to do."

The paper has a good outline of the changes to production made in Toyota. It's interesting to compare and constrast this essay and the reality of modern production with the kinds of essays favoured by the MS EMEA Journal of late, or who knows how many CACM/IEEE journals over the last twenty years, and wonder if our notions about software processes are working off stale data. If your impression of production lines derives from the 1960s or earlier, well times have moved on. Mass production today seems to have more to do with eliminating inventory and logistics planning than time and motion studies.

August 14, 2004

Monster Oriented

Radovan Janecek on a Don Box quip:

Everyone programs in something different, so let's just do protocol-based integration, where we will just agree on the format of the messages we are going to exchange over the wire."
I think this is the thing some 'REST fundamentalists' are still missing...

HTTP fundamentalists maybe. Realistically, when you build actual systems in this REST style, HTTP tends to become the glue. You can use SMTP, or XMPP, MQs or even inproc calls to get things done. But the big idea remains 'protocol oriention'.

Which is where I drift off and start thinking about SOAP. The old saw is that SOAP isn't Simple and isn't Object Oriented - but it isn't altogether Protocol Oriented either, no more perhaps than Lego is House Oriented. Mark Nottingham reckons SOAP is a protocol construction toolkit and it may be. But then, being protocol neutral was something web services folks seemed to be very proud of - boastful even. A case of mixed messages, or perhaps where the term "protocol" has lost some of its meaning through overuse.

Let's look at the way of modern way of services construction and integration. Your job should you choose to accept it, is to build reliable, available, maintainable, scalable systems in a schedule of twelve to sixteen weeks or less, on a very tight budget (where very means 10-100 times less than what people paid in the past), where some of the sponsers think what you're building is just some kind of fancy-dan web site anyway. To do this you need smaller, tighter teams, not only because of cost factors, but because even medium size teams just aren't going to get a whole lot done in 3 months due to coordination overhead. You also need guerilla development approaches, not only because of the time factors, but because services and cross business integrations quickly dispatch any quaint notions of 'staging' and 'rollout' you might have carried over from database backed websites or middleware. In those circumstances you need be fastidious in driving out all forms of waste and inefficiency from systems building. So you could be forgiven for thinking that protocol constuction is not the best use of anyone's time. Relax. Take one of the shelf. More often than not, it'll be HTTP.

mission_impossible_script.jpg

Why do this? That's easy - designing protocols is hard work. It takes smart people a long time to come with good ones, and the skill and mind sets to do it are rare, much rarer than folks who can design great APIs. Indeed protocol and API design are dealing with sufficiently different sets of problems that Sun's Geoff Arnold reckons they could be exclusive to some degree and Mark Baker thinks to switch from one to the other requires zen-like mental gear shifting. GUI toolkits built on top of protocol construction toolkits won't altogether save you from banging your head off the monitor in frustration as you design the thing. Consider that being able to reinvent something really really fast might not be as smart as re-using what already exists. And no matter what you might come up with for your business problem, it simply will not be battle-hardened the way globally deployed application protocols are.

Why not do this? That's easy too - HTTP isn't good for everything and who knows you might just have such a problem. Marshall Rose in his book on BEEP (another protocol construction toolkit) described the issue as follows:

"The problem is that the widespread availiblity of HTTP has become an excuse for not bothering to understand what the requirements really are. It's easier to use HTTP, even if it's not a good fit, than to understand your requirements and design a protocol that does what you really need."

which we might stereotype/satirize as the cookbook approach:


  • consider HTTP

  • consider something else (Email, Jabber, FTP,...)

  • consider rolling your own

frankenstein.jpg

Radovan also noticed Don's comment on ML and functional programming. I wonder Microsoft are doing something interesting on the languages front here. The burden of developers dealing with the Markup, Object, Relational and Protocol paradigms is significant*. I work with all four of these true ways and they don't always mesh. Sometimes you feel like Dr. Frankenstein - there's no doubt you're working on something big and important, but there remains a niggling doubt about the outcome as you busily hand-stitch digital body parts together. If those guys are inventing the equivalents of superglue, steri-strips and surgical staples for those of us in the trenches, that's good news.

* MORP?

[faithless: i want more]

Son of the Morning

Mark Baker is not impressed with the GUT of webservices addressing:

    <wsa:EndpointReference xmlns:wsa="..." xmlns:fabrikam="...">
    <wsa:Address>http://www.fabrikam123.example/acct</wsa:Address>
       <wsa:ReferenceProperties>
           <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
       </wsa:ReferenceProperties>
       <wsa:ReferenceParameters>
           <fabrikam:ShoppingCart>ABCDEFG</fabrikam:ShoppingCart>
       </wsa:ReferenceParameters>
    </wsa:EndpointReference>

Somebody please tell me why on earth that isn't a URI? You know, something like;
http://www.fabrikam123.example/acct/123456789?ShoppingCart=ABCDEFG

I'm in agreement with Mark about this spec, but... oh, go on then. Let's have a dialog.

Let's see - the XML structure is by design decomposable into constituent parts, ie it's a tuple with angle brackets. URIs are not like this - they're pure identifiers. According to a W3C TAG dictat, URIs are supposed to be treated opaquely, but there's no getting around the fact that a huge body of deployed web software is totally reliant on composing and deconstructing URIs. In the real world they are used as tuples/dicts and they are laden with semantics.

When made that URI, we in design terms lost information by moving from a tuple to a literal. However in implementation terms we're going to frig that identifier for information embedded in it. And that's cool - the URI is lexically designed to be friggable.

But if that's so, and tuples are useful means to pass information between client and server, then why is the GUT called WS-Addressing and not WS-IdentificationByDescription? ;)

August 13, 2004

Michael Kay on data constraints

Seen on xml-dev:

"I tend to be a little wary of constraints myself. Many of those you see in student textbooks are misguided. If I see a schema (XML or RDB) with the constraint that employees must be over 16, I ask myself what the IT department would do if the business decided to hire someone under 16. If there's a rule that an employee's manager must themselves be an employee, I ask what would happen when someone is told that they now report to a contractor. It's not the job of computers to limit what people are allowed to do (or the job of the IT department to regulate the business). A guideline I use is that constraints should be there only to protect the IT system itself from data that it cannot handle."

DOAP Slap

I have to say, Edd's done a nice job on the DOAP markup. He's kept the RDF/XML flat and avoided attributes except for rdf:resource. Deeply striped RDF/XML seems to be an antipattern.

Who knows, with a stylesheet and sufficient motivation, there might be an upgrade path for maven project descriptions after all ;)


[bubba sparxxx: deliverance]

August 12, 2004

Attack, el Object, attack!

[update: Mike Kozlowski says it best]

"I think you're right that functional programming at least allows for the possibility of avoiding null reference problems (if the called functions are smart about it), but I'm not sure that's worth giving up the very real benefits of OO. And at any rate, I think the advice those people were giving was "Don't use .toString() for debugging purposes," which seems like a nice tip to avoid a mild irritant."

Chicken Little - that'll teach me!

Simon Brunning:

"To sum up, the rules with toString() are: always override it, and never call it (directly). Instead, use String.valueOf() at all times."

I take two things away from that, and a question:

  • Prefer as first class functions as you get your hands on
  • Prefer a null-object over non-object
  • What about all the other java.lang.Object calls - should we never call them directly either?

If the answer to the question is yes (and I think it might be - what's special about toString() other than being popular?) then its logical conclusion sounds like an argument for preferring functional programming over object programming (and I think it might be - what's special about your object's methods other than not being on Object?).

(Now would be a really good time for a Smalltalker or OO type to pull me out of my mental quicksand by telling me there's a huge difference between object-oriented and heap-oriented programming... or something.)

[the hives: abra cadaver]

You turn left. You're still in a maze of twisty encoding thingies, all alike

Useful, especially for those in Ireland. Darragh has tabled a mapping of some accented characters between Oo, Firefox and ASCII downcodes.

See also: a cp1252toUnicode mapping from the effbot.


[bubba sparxxx: nowhere]

On the impossibility of improving software over time

Version 1.0: The Software Bike (tm) - features square wheels.

Version 2.0: The Software Bike (tm) - now with shock absorbers.

August 11, 2004

Get your zen on

Mark Baker:

"For everybody I know who came from a CORBA/DCOM-like distributed systems background, but now understands the Web, serious mental model rewiring occurred. "

Lucky for us fules then, who never started with CORBA or DCOM to begin with.

With our thoughts, we make the world.

Eeeuuwww

Enzyme
You are an enzyme. You are powerful, dark,
variable, and can change many things at your
whim...even when they're not supposed to be
changed. Bad you. You can be dangerous or
wonderful; it's your choice.


Which Biological Molecule Are You?
brought to you by Quizilla

August 10, 2004

I wanted generic method dispatch, but all I got was this lousy IoC tee-shirt

Charles' IOC Conundrum. I wonder if it would help if the Content object in question could tell you its media type.

The comments are also interesting, especially Rickards cast-to-type idiom, which feels vaguely like what some people call duck typing. Aside from delaying wiring to the last possible moment, there's also a lot of desire for type flexibility, it seems. But as at least one person points out, there's also the Visitor pattern (hence the mention of media type ).

August 08, 2004

Python will assimilate you

[From the wind-up school of technology strategizing]

Is it game over for language choice? Python will now run on:

  • .NET
  • Mono
  • Windows
  • Linux
  • Solaris
  • JVM
  • Apple
  • Symbian (Series 60)
  • EPOC
  • Apache

In other words, not only will Python run on most of the operating systems you might care about, it will also run on most of the managed runtimes you might care about and will do so in a less politically heated manner than other languages (for the runtimes at least). Which raises the bar, both for actually portability and for protecting a software investment for anyone tasked with choosing a middleware container or an operating system in these turbulent times.

Some notable past objections against the language appear to have died away:

  • PythonWhatsThat (1999)
  • JavaJavaJava (2000)
  • DotNetDotNetDotNet (2001)
  • DynamicTypingIsADangerousAndMorallyQuestionableActivity (2002)
  • ItsNotFastEnoughForRealWork (2003)

In 2004, the objections against Python seem to be reduceable to two:

  • MyIDERocksAllPythonIDEsSuck
  • WhoWillMaintainMyPythonLegacy

Now, personally I don't care too much about the first (after all, you only have to wear a O'Reilly tee-shirt to not need an ide), and I can certainly help answer the second question, for Ireland anyway - it has in the region of 20 Python developers, enough surely for any small nation; all told, there may be as many as 200 Pythonistas within the European Union alone (wow!). Nonetheless, these are two reasonable objections, worth addressing.

The solution? Some corporate entity should immediately sponser a port of Emacs to Python along with a cool GUI, as that kills two birds with one stone - shiny IDEs will appeal to developers and the people that hire them, thus creating a meat-market for Python skills. Plus since it's really SonOfEmacs, it'll be downright impossible for the half-dozen or so 'great hackers' on the planet to object.

Please don't take this too seriously ;-)

August 07, 2004

Concurrent Testing and Patterns for Java

Tim Bray:

"I haven't figured out how to do Test-Driven Development of concurrent systems. I know how to write tests that catch an iterator that doesn't iterate and numeric code that loses precision and a million other stupid things that every programmer does. But I don't really know how to write tests that catch simple, bone-headed, obvious errors in concurrent systems."

I'd have to say that in general you can't unit test for this (in Java anyway). However there are means of alleviating matters:

  • Understand the known patterns and idioms. Doug Lea's Java book is a fantastic source of patterns for concurrent OO. It might be the only great programming book that uses Java (great as in Dragon Book great or K&R great).
  • Write less threaded code. Use Doug Lea's stuff, either concurrent.jar or upgrade to 1.5. There's no need to roll your own unless you're doing it for fun.
  • Read everything Brian Goetz has to say about Java threading. Smart guy, writes well.
  • Matt Albrecht has a nice utility in grobo utils: MultiThreadedTestRunner. Good for heightening concurrency in tests and thus flushing out bugs.
  • Doug Schmidt's POSA2 book is a good source of patterns. It's a bit turgid in spots, but worth it for the Reactor and Half-Sync/Half-Async patterns alone.
  • Use less threads. Events, events, events - especially for io.
  • For valour:

You could of course go the route of using alternative languages.

August 05, 2004

Dude, where's my document?

Microsoft Word is one buggy piece of software. I've been using it heavily for the last week or so. Seemingly non-determinisstic style inheritance? Documents that jump from half a meg to 30 megs when you insert some Visio diagrams? Table of contents refresh that inlines images? And just what is going on with the bullet points?

It's the only application I use that when it crashes, can force me into a hard reboot of Windows, a la the Nineties. I should see if someone has our ported our company templates to Open Office.

Another WS spec

Sean McGrath

"The reason I ask is that if this is the future of web services it looks awfully complicated and complicated specs in this industry often turn into either (a) hypernovas of non-interoperable (read "proprietary" implementations) or (b) withered leaves on a vine."

Time for a fable.

The WS RSS feed has been updated

August 04, 2004

Clarity

Bugs Are Not Issues and Vice Versa

August 03, 2004

This Is What's Wrong With Globals

Speaks for itself

August 01, 2004

Jabber and dynamic languages: inherently survivable

From DARPA, the folks who among other things, helped bring you the complicated theoretical bits of the Semantic Web, Ultralog:

"UltraLog's goals are: operate with up to 45% information infrastructure loss in an environment that is 90% as chaotic as the most chaotic real world environment with not more than 20% capabilities degradation and not more than 30% performance degradation for a period representing 180 days of sustained military operations in a major theater contingency."

Those goals are the kind of severe outage and extreme network disconectedness that drove the original Internet architecture. Looks like DARPA want to do it all over again at the higher layers. This particular effort is building on COUGAAR, a well-known* Intelligent Agents framework. Autonomic Computing and Semantic Web hype comes to mind, but some things do look interesting for the here and now (if only because they're consistent with some conversations that have gone on in work):

  • Phil Windley points out that this lot are using Jabber as their messaging backplane.
  • Jon Udell also interviewed (.mov) to of the folks involved on the value of using dynamic programming languages (in this case, Ruby).

* Ok, so this is only 'well known' perhaps if you know a bit about IA and DAI in the first place.

I miss Lisp

Spotted in the Subversion 1.0.6 source: merge.c
          /* I miss Lisp. */

          SVN_ERR (svn_io_open_unique_file (&lcopy_f,
                                            &left_copy,
                                            merge_target,
                                            left_label,
                                            FALSE,
                                            pool));
          SVN_ERR (svn_io_file_close (lcopy_f, pool));

          /* Have I mentioned how much I miss Lisp? */

          SVN_ERR (svn_io_open_unique_file (&rcopy_f,
                                            &right_copy,
                                            merge_target,
                                            right_label,
                                            FALSE,
                                            pool));
          SVN_ERR (svn_io_file_close (rcopy_f, pool));