Jon Israelson: Programming

Thu, 11 Mar 2004 16:38:07 GMT

Java as Baby Step. James Robertson thinks that Java is an interruption in the forward progress of software development. It’s nice to see this meme spread a bit; I’ve thought the same thing since 1996 or so. During ‘95 and ‘96, watching Java start to gain traction, I was amazed by the ignorance and ire surrounding many of what I considered Java’s best features:

the virtual machine
garbage collection
methods "virtual" (in C++ parlance) by default
a singly-rooted class hierarchy

I came to view Java as a baby step that would serve primarily to soften up developers’ attitudes toward these things, thus shortening the leap required to adopt even better languages like Lisp, Smalltalk, and their ilk. I don’t think I was alone in believing that, but I didn’t hear anyone else saying it for a while.

It is nice to see people returning to serious language research again. Efforts like the Feyerabend Project and more practically focused offshoots like OOPSLA’s Onward! track and the Post-Java Workshops (as well as increasing grass-roots interest in languages like Ruby, Haskell, Squeak, Oz, and even an ongoing Lisp revival) give me hope that we’ll be ready to take a larger step soon.

[Glenn Vanderburg: Blog]

I'm with Glenn and James on this: I think that Java's success was in part due to it's packaging of the features that Glenn listed above in a form that was easy for C developers to swallow. All of those features had been around for years in various other languages, but those languages didn't resonate well with the general IT population for a variety of reasons. Java acted as the sugar coating that made accepting those features fairly easy, but in my opinion Java has not added any significant new concepts to the world of programming languages. It's time for something better.

Thu, 11 Mar 2004 15:58:37 GMT

Job Scheduling in Java. Scheduling recurring execution of a piece of code is a common task for Java developers. The Timer class has its place, but as Dejan Bosanac explains, developers with more sophisticated requirements might want to check out the Quartz API. [O'Reilly Network Articles]

Wed, 18 Feb 2004 22:03:50 GMT

Why's Poignant Guide. A few months back, why the lucky stiff offered up a great warranty. Now he’s at it again, tis time giving us the first glimpse of what looks like a pretty unique approach to learning a computer language, in this case Ruby. It’s one of those sites that’s hard to stop reading: I hope we can convince him to produce a print version for the Pragmatic Bookshelf. [PragDave]

Tue, 17 Feb 2004 21:41:47 GMT

IBM has released an Autonomic Computing Toolkit for Java (and that integrates with Eclipse).

Tue, 17 Feb 2004 14:41:44 GMT

Yahoo has an interesting story about how Sun's Project Looking Glass got its start as the personal project of one developer with a cool idea.

Fri, 13 Feb 2004 22:31:14 GMT

Martin Fowler on Domain Specific Languages. Martin Fowler on DSLs...

I've always used the analogy of creating a DSL to help think about building up a design - developing classes and methods with an eye to making them be a DSL. As much as possible I do this within the language I'm using, but if I can't I'm very ready to switch to code generation. At ThoughtWorks we've used code generation and similar techniques widely on our larger systems. The point at which I pull the separate language DSL lever is clearly different between languages. I never really felt the need in Smalltalk to use a separate language, while it's quite common in C++/Java/C#. [Lambda the Ultimate]

Fri, 13 Feb 2004 22:29:27 GMT

Udell: Programs that write programs. Worth a look.

Jon Bentley in Bumper-Sticker Computer Science quotes Dick Sites as saying I'd rather write programs to write programs than write programs.

For some reason I remembered this quote as saying I'd rather write programs to write programs to write programs than write programs to write programs.

But maybe that's just me...

[Lambda the Ultimate]

Wed, 21 Jan 2004 14:59:33 GMT

The Simplest Thing That Could Possibly Work. Ward Cunningham talks with Bill Venners about complexity that empowers versus complexity that creates difficulty, simplicity as the shortest path to a solution, and coding the simplest thing when you're stuck. [Artima Articles]

Fri, 09 Jan 2004 22:11:20 GMT

Mechanism and Policy. I’ve been reading Eric Raymond’s "The Art of Unix Programming" (a good book that could have been great had he managed to find a more balanced voice). In the section on user interfaces, he reminds his readers of the decision of the designers of the X windowing system not to impose look-and-feel constraints on X applications. The designers say that X supports "mechanism, not policy."

The X windowing system provides the underlying graphical user interface for most Unix systems (the Mac is a notable exception, as we’ll see). Perhaps surprisingly, X itself offers almost no user-level features. Instead, it concentrates on providing a set of low-level primitives for drawing windows and filling those windows with graphics and text.

In order to make X usable, you need to supply an application program called a "window manager." This hooks in to X and handles events: for example, X may create a window, but the window manager can decide where to place it on the screen. To fill windows with widgets (standard interface components) you need another layer of software, the various X toolkits.

The designers of X felt that building a lot of behavior and standard interaction models into X would limit the user of X. Instead, they provided a (fairly low-level) API, and allowed their users to build any style of interface they wanted. They provide the mechanism, but enforce no policies on how that mechanism is used.

By contrast, the windowing systems from Microsoft and Apple (as well as those from Be and NeXT) were rich in policy. The windowing systems imposed a number of look-and-feel constraints and behavioral similarities between applications. There were even documents for application designers dictating just how their applications should look and react.

So what are the tradeoffs? Raymond says:

: The difference in approach [between X and Mac/Windows] ensured that X would have a long-run evolutionary advantage by remaining adaptable as new discoveries were made about human factors in interface design—but it also ensured that the X world would be divided by multiple toolkits, a profusion of window managers, and many experiments in look and feel.

Ignoring the interesting spin on "evolutionary advantage" (I don’t often see X applications edging out Windows and Mac ones on my client’s desktops), the point is a good one. By keeping the underlying framework free of particular implementation decisions, you make it more flexible. This flexibility is a two-edged sword. One the one hand, it allows multiple competing ideas to duke it out: the winners will be selected by their users, and not just by developers (perhaps this is what he meant by evolution). But on the other hand, it also leads to the fragmentation he describes.

But he’s also being disingenuous here: the reality is that it isn’t the X windowing system itself that’s adapting at all. Instead, it’s the efforts of hundreds of people writing the stuff on top of X that has provided the ongoing evolving interfaces he describes. Underneath the covers, X is basically the same old X. In some way, you could say that all their efforts were expended making up for stuff that X didn’t provide itself.

So, by providing policy, the designers of Windows and Mac interfaces have provided their end-users with a consistent look and feel, and a base set of application behaviors. By instead focusing on mechanism and ignoring policy, the designers of X allowed developers to experiment, but gave the users of X applications a very inconsistent interface experience. Arguing one approach is better than the other is pretty pointless: they’re just different.

What can we learn here when it comes to applications and designs?

When I first started thinking about this, I was reminded of the audience discussions that sometimes erupt when I talk about Naked Objects. A Naked Objects application exposes the core business objects of an application directly to the end user. They can manipulate these in any way the objects allow: there is no overall application GUI imposing a certain way of doing things. A Naked Objects system provides mechanism, but little in the way of policy. When I describe this, some folks have a strong reaction against the idea. "Without high-level policy imposed by the GUI (scripting, or series of modal dialogs that have to be filled in in a proscribed order) how can we ensure our users do everything that needs to be done?" they ask. And its a good question. Experienced users, folks who understand the domain, love Naked Object systems because they get the control and flexibility they need to get the job done. But inexperienced users can be confounded by that same flexibility—"what should I do now?". (In a way, this also relates back to the Dreyfus model of skills acquisition: beginners need to be guided, while experts need to be left alone to get on with their jobs.)

In the Naked Objects world, it turns out that there’s a compromise. Because the Naked Objects are themselves just Java business objects, there’s nothing stopping you putting a more conventional view and controller on top of them, converting your Naked Objects application into a conventional GUI or Struts-style app. And, because the objects are the same beneath the covers, you could probably arrange to run both the Naked Objects and conventional application at the same time. The conventional application would have less flexibility and functionality, but would be easier for casual users. The Naked Objects system would have full flexibility for more experienced users.

In a way, this seems like the OSX way of doing things. Apple have taking a Unix operating system and wrapped it with a fantastic user interface. Not only does this interface work at the application level, but it also gives you the ability to do most of the administration of a box without dropping to the command line or editing files. I love this: I’ve spent all too many years administering Unix boxes the hard way. But what I love just as much is that when I need to, I can still get down and dirty. It’s the best of both worlds: regular users get a great, easy-to-use interface, but power users get to strip away the facade and work down at the lower levels.

Increasingly, I think the "one-size-fits-all" mentality is going to break down. We need to think about delivering our application functionality using multiple modalities, each targeted at specific user communities. Mechanism versus policy is one axis we need to consider, and one that’s relatively easily addressed in a well-designed application. We don’t need to decide up front whether to deliver one or the other; instead we need to work out how to provide both.

[PragDave]

Mon, 15 Dec 2003 19:01:18 GMT

SolarMetric has release version 3.0 of Kodo, their JDO implementation. I used Kodo on my last project and really liked it. Its ability to reverse engineer a database schema into a set of classes saved us a huge amount of time and effort.

This release adds a lot of very cool new features that address a lot of the shortcomings that I encountered with version 2.5. At the top of this list include:

More hooks for controlling the reverse mapping output (class/method/field names).
Aggregates and projections in queries (yahoo!) . count, sum, min, max, and avg are built in, and you can create your own custom functions.
Now supports direct SQL queries (you can give Kodo your own query and it will return the resulting JDO objects)
More control over handling of very large result sets (using cursors).
Many more object-relational mapping options
Better cache locking, which is supposed to increase concurrent access speed

All told, this is good stuff!

Mon, 01 Dec 2003 22:14:51 GMT

Why Functional Programming Matters. by John Hughes (1984)

As software becomes more and more complex, it is more and more important to structure it well. Well-structured software is easy to write, easy to debug, and provides a collection of modules that can be re-used to reduce future programming costs. Conventional languages place conceptual limits on the way problems can be modularised. Functional languages push those limits back. In this paper we show that two features of functional languages in particular, higher-order functions and lazy evaluation, can contribute greatly to modularity.

This is a great paper because it's easy to read and it shows you why functional programming matters. It does this in the best of ways: by presenting beautiful programs. It's by far the best demonstration of lazy evaluation that I've found.

(I was really surprised to find that this paper hasn't been featured here before, though it has been linked several times.)
[Lambda the Ultimate]

Mon, 24 Nov 2003 15:36:22 GMT

J2EE 1.4 spec certified - Infoworld Staff. J2EE 1.4 is now official, Sun announced this week. [InfoWorld: Top News]

Wed, 19 Nov 2003 20:18:12 GMT

artima.com has posted the second in a series of interviews with Matz, the creator of Ruby, titled Dynamic Productivity with Ruby.

Wed, 19 Nov 2003 19:15:39 GMT

I totally agree with Glenn Vanderburg's view in Wrong Turn that J2EE is a mess (and growing). If you step back and look at the J2EE spec and its implementations you've got to be amazed at the complexity and size of it all. There are way too many moving parts, many of which feel like they were built in isolation and later force-fit into the overall spec in order to quickly fill some missing feature.

Wed, 19 Nov 2003 17:37:38 GMT

Python and the Tipping Point. Bruce Eckel says, "The main sources of productivity [when programming in Python] are that I am able to look at more lines of code on the screen, put more meaning into fewer lines of code, read and understand code more easily, and deal with higher level concepts." [Artima.com News & Ideas]

Wed, 19 Nov 2003 17:37:11 GMT

Type Checking and Techie Control. Bruce Eckel says, "Once I get the program running, I feed it real data. Then I'm going to find some interesting errors. So the sooner I can do that, the sooner I can find those errors." [Artima.com News & Ideas]

Thu, 23 Oct 2003 02:33:48 GMT

Developing With Maven. By knowing what developers want in a build tool, Maven hopes to unseat Ant as the favorite build tool of Java developers. Rob Herbst looks at Maven's most compelling features. [O'Reilly Network Articles]

Tue, 21 Oct 2003 00:07:00 GMT

I just saw that Eric S. Raymond has release version 1.0 of The Art of Unix Programming (also available in print from Amazon). The last time I took a look at this document, it was fairly incomplete. I'm glad to see that it now exists in its entirety.

Sat, 18 Oct 2003 00:23:07 GMT

The Philosophy of Ruby. Yukihiro Matsumoto, the creator of the Ruby programming language, talks with Bill Venners about Ruby's design philosophy, including design imperfection, the danger of orthogonality, and the importance of the human in computer endeavors.

Rather than discussing Ruby features in particular, Yukihiro Matsumoto explains the principles that guided him in the design of Ruby. Interestingly OO is never mentioned (perhaps it's taken for granted).

An interesting quote:

Yukihiro Matsumoto: Language designers want to design the perfect language. They want to be able to say, "My language is perfect. It can do everything." But it's just plain impossible to design a perfect language, because there are two ways to look at a language. One way is by looking at what can be done with that language. The other is by looking at how we feel using that language-how we feel while programming.

Because of the Turing completeness theory, everything one Turing-complete language can do can theoretically be done by another Turing-complete language, but at a different cost. ...

Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby. I didn't work hard to make Ruby perfect for everyone, because you feel differently from me. No language can be perfect for everyone. I tried to make Ruby perfect for me, but maybe it's not perfect for you. The perfect language for Guido van Rossum is probably Python.

and also:

Yukihiro Matsumoto: Ruby inherited the Perl philosophy of having more than one way to do the same thing. I inherited that philosophy from Larry Wall, who is my hero actually. [Lambda the Ultimate]

I'm a big fan of Ruby and this provides a view of the language from the perspective of its designer.

Tue, 07 Oct 2003 15:22:39 GMT

Online book Structure and Interpretation of Computer Programs. Another interesting book that I will probably never have time to read.

Mon, 06 Oct 2003 21:43:54 GMT

Tuples + Objects + Infosets =Too Much Stuff!. Once upon a time it was possible for every new programmer to quickly learn how to write readable programs to Create, Read, Update and Delete business information. These so-called CRUD applications, along with reporting, were pervasive throughout business and essentially defined IT or MIS as it was called in those days... [Now] THINGS ARE SO COMPLEX YOU NEED AN M.SC. TO PROGRAM CRUD!

Eric says this is a great paper, so who am I to argue?

[Lambda the Ultimate]

There are a number of interesting articles to be found on the JOT (Journal of Object Technology) web site

Tue, 30 Sep 2003 18:36:11 GMT

Versant Includes JDO in Object Database. Versant Corp. is hooking up with SolarMetric Inc. to get JDO (Java Data Objects) technology into its Versant object database, officials announced on Tuesday. [eWEEK Technology News]

SolarMetric's Kodo already works against relational and flat files. Now they'll be able to connect to a true object database. Pretty cool.

Tue, 23 Sep 2003 15:34:00 GMT

I just stumbled across the grid computing section of IBM developerWorks. They have a good arcticle that introduces the basics of grid computing. Now if I just had access to that huge G5 cluster at Virginia Tech...

Tue, 23 Sep 2003 15:23:57 GMT

Baseball lessons for software teams.

Doing more with less is the theme of Michael Lewis' terrific new book, Moneyball. This David-versus-Goliath tale explains how the low-budget Oakland Athletics consistently win more games than much richer teams. Moneyball is not just a baseball book; it's a treatise on the science and economics of individual and team performance. The methods pioneered by Oakland General Manager Billy Beane, based on the theoretical foundations laid by maverick statistician Bill James, hold important lessons for enterprise IT. [Full story at InfoWorld.com]

... [Jon's Radio]

Wed, 27 Aug 2003 15:44:57 GMT

Exploration and discovery. This week's column on dynamic languages, and its associated blog entry, provoked some interesting reactions...[Jon Udell]