On the Thought

Moving to Artima

2005-05-31T16:21:00.000-07:00

I'm moving this weblog to Artima; here's the link. In the first post, I explain why.

The existing posts that you see here will remain.

MindView Home Page

Thinking in Patterns seminar registration now open

2005-04-30T09:17:00.000-07:00

I've been quiet here for various reasons, mostly because of a lot of traveling -- right now I'm on a 1-month marathon consulting tour for 3 different companies, all in understanding objects and object design. It's been very consuming, but also productive.

Because a number of people have (appropriately) nudged me about it, I finally took some time and set up the seminar registration for the upcoming Thinking in Patterns seminar, which will take place June 20-24 2005, in Crested Butte, Colorado. You can read more and register here.

I will be updating the online book and the seminar materials to reflect changes in J2SE5, and to add new information and patterns that I've acquired since the last time I've worked on the book (I'm still working on finishing Thinking in Java, 4e so I haven't been working on TIPatterns so much, but an upcoming seminar always spurs me on to new work on the book).

MindView Home Page

PyCon and SD

2005-03-25T15:28:00.000-07:00

I think it's been years since I've given a talk that was less than 45 minutes or an hour. Everyone except the keynote speakers at PyCon had 1/2 hour. Naturally I had too much material and had to blaze past the slides at the end. Many people were very kind and told me they had enjoyed the talk but it felt unresolved to me. All the talks were both recorded and videotaped, and so eventually you should be able to hear or see it and decide for yourself -- not just my talk, but the entire conference! (The actual distribution strategy has not yet been devised, so you should watch the www.Python.org website).

It was again interesting to experience and contrast the SD conference with PyCon.

SD is best described as a teaching conference. There are half-day and full-day pre-conference tutorials, and during the conference all the talks are 1.5 hours long (I created both the C++ and Java tracks for the SD conference and chaired them for many years, and so I helped evolve this structure). All the subjects are intended to be well-established on the acceptance curve; this is a commercial conference and they want each topic to have a strong draw. SD is a good place to go in order to develop expertise, almost as if it were a multi-subject professional development seminar.

PyCon is a community conference. It is actually developed and organized by volunteers from the Python community, and any profits go into the Python Software Foundation (PSF), which promotes the language and lately has even begun to give grants for the development of various aspects of Python (a recent grant was to update Jython, for example). PyCon is thus much more edgy and experimental and this adds a lot of excitement to the conference. For example, I had almost forgotten how great the lightning talks are. These are 5 minute talks about whatever you are doing or find interesting. The 5-minute limit is an example of a "liberating constraint," because people are willing to take far more risks if it's only 5 minutes. Also, you can easily get a last-minute inspiration and do a talk. Because it's 5 minutes, you don't dally or wander -- you get right to the meat of your subject. And for the audience, it's especially nice because if there's a talk that doesn't interest you or you don't understand, all you have to do is wait 5 minutes. And the things that you learn are far broader than you will find in the more formal talks. My favorite was a use of PyGame, a 3-D game-building framework that's been around for years and continues to amaze me, and is apparently used for commercial products. The presenter apparently holds a contest each year, and this year's theme was randomness. He had created a game called "Ducks" which had delightfully primitive drawings for the graphics. The ducks would chase you, drop things, etc. We didn't see much of it but it was hilarious; a game I'd like to play.

PyCon also has "sprints" before or after the conference proper, where you get together around a topic and work on it for 1-4 days; typically this involves writing code but I coached one where we were just exploring a topic; it was really more of an OpenSpace but I found it helpful.

Although I learned a great deal from the half-hour presentations, the lightning talks and OpenSpace events were what passed the nod test. When I travel to a different time zone I don't sleep that well, and the best way to help me catch up on my sleep is to put me in a room and do an eyes-forward presentation. Since I'm not interacting, the steady words from the presenter will often send me off. It's clear in those situations that I'm sleep deprived. But when the environment is more energetic and interactive (and even though the lightning talks were presentations, they felt more interactive), I feel very awake.

I have organized a number of meetings where we relied solely on OpenSpaces, which means that everyone in the meeting decided what was important to them and everyone at a particular OpenSpace was actively interested in the topic. These are the most nonstop energizing experiences I've had, and the only downside is that at conventional conferences like SD and even at PyCon, I am very aware of "energy gaps," which in the past I've simply accepted as inevitable and unavoidable. Once you've experienced an OpenSpace conference you wake up to the possibilities of what the word "conference" can really mean (both of the conferences I am holding this summer are OpenSpace conferences).

PyCon is more of an agile conference, and they are constantly re-evaluating things. One topic that came up was that a significant number of attendees who are newer to the language would like some sort of tutorial material to come up to speed so that the regular sessions would make more sense to them. So PyCon needs to become a little more like SD in that sense. SD could use more of the kinds of things that inject energy into the atmosphere that PyCon has. And, although PyCon already recognized this, both conferences need to do things that bring people together in the evenings. The PyCon folks tried to get a party sponsored this year, but I've never found a conference-wide party to be all that stimulating, and as they discovered it costs a lot and takes a lot of effort; the payoff isn't that great, in my opinion. A simple thing I've seen done at some conferences is just helping people get into groups to go out to dinner. These could organize around a speaker or a topic, and should probably have limits on size since dinner doesn't scale up so well. Another possibility is to have evenings that are exclusively OpenSpace oriented, since then there would be no competition with talks (perhaps at a conference, most or all of the OpenSpaces should be moved to the evening for this reason).

To me, the best things that happen at a conference are those that start conversations and interactions with people. After all, the reason that we travel from all over the place and come together in the same physical space is to connect. Especially with the internet, where we can do online everything that doesn't involve connection.

MindView Home Page

More Jobs

2005-03-24T09:23:00.000-07:00

Last week at the SD conference Bill Venners heard from the people at Dice.com that the job postings this month are twice what they were last year at this time.

This week at the Python conference in DC we were handed a bag at registration that contained many sheets of paper from different companies saying "we're hiring Python programmers." This says a lot about both the economy and Python.

The conference has roughly 25% more people this year than last. We've outgrown the conference center at GWU, and will have to go to a larger facility.

The conference continues to be very good, very high energy. There is talk of adding a more introductory tutorial track next year, since it has more of the flavor of a technical conference and some folks would like to get up to speed on more of the fundamentals.

Guido Van Rossum gave his "State of Python" keynote this morning, and the formerly-named "optional static typing" has evolved nicely into something that seems more palatable, and will be renamed since it really isn't about static typing. Everything is still in the early stages but I think that something very interesting could result, that would NOT get in the way (which is what most people have been afraid of when the phrase "static typing" was used).

MindView Home Page

Agile moves to the next phase

2005-03-17T10:05:00.000-07:00

I'm attending and speaking at the Software Development Conference in Santa Clara this week (this is the same conference where, for many years, I chaired the C++ and Java tracks). Last night a group of us (myself, Bill Venners, Chuck Allison, Allen Holub, and Eric Evans, who wrote "Domain-Driven Design"), went to dinner at the White Lotus in San Jose, a place I try to get back to every time I'm in town.

That day I had seen, among other things, an agile talk Robert Martin and one by Mary Poppendieck. Although I've been following the printed literature, the last time I had seen any agile talks was at least a couple of years ago. What most impressed me by these two talks is the focus and the level of polish, in particular the shift to more evidence-based presentations. These are far more convincing and compelling arguments than the presentations that appeared when XP and agile initially appeared; I would classify those presentations as being more "enthusiasm-based."

Eric has been attending XP and Agile conferences and following everything more closely than I, and he said that someone at one of the recent conferences had made a presentation that pointed out that the early adopter phase had ended, and the current phase of adopters are more conservative and require clearer evidence in order to be convinced. Because I had already had my own XP-like experiences by the time XP appeared, the enthusiasm-based approach worked on me, but I found that these two presentations had a much more solid and mature feel to them. Of course, the fact that the presenters were very good made a big difference, as well.

MindView Home Page

Adapters and Interfaces Sprint at PyCon

2005-03-09T15:06:00.000-07:00

I'm coaching the Adapters and Interfaces Sprint on Tuesday, March 22 at the Python Conference. If you are interested please add your name to the list so I'll know whether to actually do it.

MindView Home Page

.NET and Java on the desktop

2005-03-09T14:58:00.000-07:00

I'm out in the boonies for a few days where there is only a phone line (and a slow one at that). My new notebook computer came with a bunch of free AOL hours so I thought I'd try that (although I used AOL many many years ago, I haven't paid attention since then). All I want to do is get on the internet, so I don't care. The signup process works fairly well, but I've noticed that in the last few days my mailblocks anti-spam service has been receiving messages but I've had only intermittent luck sending them. I tried emailing their tech support about this and they suggested that I have too many cookies in my browser. Of course I'm using a non-browser email client and so this is completely inappropriate feedback, but this kind of "support" is consistent with what I've gotten from them since AOL bought them.

So my scheme is to use the AOL SMTP address for sending mail, instead of the mailblocks address. But what could that be? I decide to try the online help, and it comes back and says "You will need to activate Java technology in your browser to use NetAgent - Java Customer Client." The notebook is very new and I haven't, in fact, installed Java yet. But I find this interesting because I can't imagine that most people who need help and click on this is going to have any idea how to "activate Java technology" in their browser. (When I did install Java, the AOL instructions didn't work).

I tried installing the RSSReader on this notebook, and it warned me that I would need .NET installed on the machine in order to use it. I hadn't installed .NET and so I thought I'd see how the system responded if I tried to do it anyway. It installed without any questions, and I discovered that somehow I already had .NET 1.1 on the machine. Without explicitly installing it. Apparently it comes as part of the service pack. Very convenient if you want to distribute a .NET application, but it certainly puts Java at a disadvantage. On the other hand, there are apparently large numbers of unwashed masses still using Windows 95 and 98, so developing any kind of application that doesn't run on those will be problematic.

MindView Home Page

Destructors in GCed languages II

2005-03-01T05:59:00.000-07:00

In response to Destructors in GCed languages, Walter Bright added this point:

6) The destructors can automatically call the base destructors, and they do that. But they cannot automatically call destructors on the members. The reason is that class objects are by reference only, so the members are by reference, so the destructor cannot tell if someone else is holding that reference as well. So it can't call the destructor on them. (It could if it used reference counting memory management, but D uses mark/sweep.)

In C++, it's possible to embed member objects in their enclosing class, and so objects of that class clearly "own" the member objects and cleanup can occur deterministically. UML even has a way to graphically distinguish between embedded objects and shared objects.

As soon as you start sharing objects, however, you lose the determinism and so it would seem that there isn't a way to automatically call destructors for member objects.

But how useful is a destructor that does this? It only solves part of the problem, and leaves the rest to the programmer. I think this is why the Java designers decided to punt on the whole destructor issue, for the same reason as Walter gave, which is more generally "our garbage collector is not deterministic enough to know when to clean up objects."

Is this actually this issue, though? Suppose we separate the ideas of memory reclamation and object cleanup, and say that the nondeterministic garbage collector handles memory reclamation and some other mechanism handles object cleanup. This is what Java does, but you are provided with the finally clause in order to achieve non-memory object cleanup. D tries to go a step further and create a destructor mechanism, but stops before calling member object destructors and thus might do more harm (by implying complete destruction) than good.

Let's look at the implication that reference counting and garbage collection are the same thing. Reference counting can certainly be used as a garbage collection mechanism, as we see in Python. But reference counting is what its name implies: a way to keep track of the number of references there are to a particular object. The problem with calling destructors for shared objects is exactly this: you need to know whether there are any other references to an object before calling its destructor.

It's fairly easy to write a reference-counting implementation to keep track of the references to a shared object so that you can know when to call the destructor. And this runs within a system that has a separate garbage collector.

The downside is that the programmer is responsible for calling any "addRef" method, and it would be nice if it could all be automated.

If you distinguish between the garbage collector for memory reclamation, and reference counting for destruction of shared objects, I think it is possible to solve the automatic destructor problem for garbage-collected languages. Here's how it could work:

If a class has a destructor, the compiler adds reference counting to that class.
Any time a new reference is attached to an object of that class, the reference count is incremented automatically.
As a reference disappears, it decrements the reference to an object.
When an object's reference count goes to zero, the destructor is called.

Basically, the reference-counting mechanism is running in parallel with the regular nondeterministic garbage collector, and reference counting is only attached to objects that have destructors. By separating the two (reference counting for destructors vs. garbage collection for memory release), I believe this would not only allow a completely automatic destructor to be created -- one that would properly clean up member objects -- but I think it would also eliminate the need to explicitly call destructors in finally clauses. I don't know of any situation where you must explicitly call destructors in Python; as soon as the reference count goes to zero the destructor is called.

(Later) Walter commented:

D goes further than just offering finally blocks, it also offers scoped destruction when the 'auto' storage class is used. The scoped destruction can be used for resource management just as in C++, there are other nifty uses for it such as timing code, see
www.digitalmars.com/techtips/timing_code.html.

It doesn't automatically resolve the issue of running destructors on members deterministically, but if you write your class putting such members as 'private' members, and don't create other references to them, you can use the 'delete' operator on them to deterministically clean them up.

MindView Home Page

Speaking in Salt Lake City March 4

2005-02-25T14:19:00.000-07:00

I will be I will be talking about the new version of Java (J2SE5) and how very different it is in both features and attitude from previous versions of Java, next Friday (March 4), from 3-5 pm at NorthFace University. Free, open to all.

Details and Directions

MindView Home Page

PHP is not Perl

2005-02-22T09:02:00.000-07:00

Sometimes when I can't bring myself to work on Thinking in Java 4e anymore, I've learned a little about PHP. Sounds kind of sick, I know, but it's actually refreshing in a kind of "green fields, unlimited possibilities" way.

I skimmed through a couple of books before settling on John Coggeshall's "PHP 5 Unleashed." His voice is good, and the book has a feeling of being carefully crafted.

I had somehow gotten the impression that PHP was a kind of Perl derivative, probably from the '$' before the variables. As I learn about it, however, it seems more like C than anything else. C with '$'s in front of the variables.

It also seems very consistent and well thought-out. Language features seem to follow logically from each other and so far I haven't found anything particularly surprising -- no special cases. Of course, I am getting on board at PHP 5, which seems to have worked out all the kinks, and added objects, which seem to be an amalgam of C++ and Java (mostly Java) with '->' instead of '.' for member selection.

It feels slightly weird to say this, as if, for some reason, I shouldn't like PHP. But I do. It looks like they learned well from other languages, and doesn't seem hacky all (again, my perspective is PHP5).

Of course, I'm aware of the problems of mixing presentation with model, and that at some scale this will probably start causing problems. But I also see the value of it -- if you stay below a certain size and complexity, mixing the two makes it much easier to program. And for me, web stuff is just something I need to get done so that it works, in the most expedient fashion. So I think, when I start building dynamic pages, that I will give PHP a try. I don't know that this is where I'll end up, but it seems promising. Plus it has a boatload of people who are using it, and apparently lots of good libraries. The fact that it is supported on most web hosting providers has a lot of appeal, as well.

I'm not giving up Zope, though. For what I know how to make it do, it works fine. For now, however, I am giving up on making it past the first elbow of the Z-shaped learning curve. I've actually been around that particular bend several times, and slightly up the curve, but I've come to the conclusion that if you don't live and breathe Zope development, it's too complex to hold in your brain between one bout and the next. So I'll use Zope (and maybe graduate to Plone) for as much as I'm able, and switch to another technology like PHP or one of the Python web frameworks for building more dynamic content.

I'm not so sure this is a bad model. The argument for purity is that it's easier to use only one language. But if Zope works for me up to a point, and then it becomes much harder to build a page that, for example, stores its fields, than it is to use PHP, and if PHP is reasonably well-designed so that it stays in my brain between bouts of web programming, then I'll be more effective with a hybrid of technologies than I will by remaining pure for the sake of being pure.

The other factor is that I've realized that in my case, I don't build applications on my server that are going to run into scalability problems. But I do run into a big roadblock when trying to develop web applications using the more "pure" approach, and as a result I've been stymied more often than I've been successful.

MindView Home Page

Servant or Disciplinarian

2005-02-21T04:40:00.000-07:00

One of the missing dimensions in this discussion about static and dynamic typing is where a language fits on the continuous spectrum of servant at one end and disciplinarian at the other. People who complain about having to spend too much time arguing with the compiler are wanting more servant and less disciplinarian, and those who feel that more static type checking will be helpful are asking for more discipline.

Different situations need different positions on this spectrum. I think the arguments have been ignoring this, and the all-important missing statement in brackets that should precede every declaration is: "[in my situation] more (static|dynamic) properties are better."

The situations are usually more about people than they are about programming. And for some reason programmers don't like hearing this, but the second missing dimension in this discussion is that programmers are different. There's a huge difference between novice programmers and the mysterious "5% who are 20x more productive than the other 95%."

This is probably a threatening thing to say because it can be tied up with things like money and social acceptance and the perceived quality of our (as Woody Allen said) "second-favorite organ." But why should someone who can swing a hammer believe that they have the same experience or ability of a master finish carpenter?

I remember coming out of school with a Master's degree in Computer Engineering (my undergraduate degree was in applied physics). I actually did know some things, and I could figure other things out. But my cubicle-mate, Brian, could build software. He had spent enough time thinking about it and doing it that he had perspective on the problem. That certainly didn't make me useless -- I created valuable things while I worked at that company. But at the time, we were just beginning to use pre-ANSI C for hardware programming, and there was very little type checking, and I could have used more. Of course, pre-ANSI C was not much more than a glorified assembly language and there was hardly any type checking at compile time, and none at runtime. This might be part of the confusion about dynamic languages, that it seems like you might be thrown back into working without a net, as we were doing then.

On numerous occasions I've heard Smalltalk programmers say that if a programmer starts with Smalltalk, it fundamentally shapes how they approach all programming (they also talk about unlearning the damage done by other languages in order to learn Smalltalk). I think this is probably true; most of the people I know who started with Smalltalk have a much better grasp of the fundamental concepts, and an ability to see what is simply the cruft of a particular language, than people who start with languages that are closer to the metal.

I started with assembly, then Pascal & C, then C++, then Java, then Python (ignoring a number of flirtations with scattered other languages like Prolog, Lisp, Forth, and Perl, none of which really took). So my experience with languages started with the cruft and the important concepts mixed together. Not only could I not tell one from the other (so they all seemed equally important) but the higher-level concepts were not initially available.

In C++, I started by creating my own containers because there was no STL for many years (the STL was actually added rather late in the standards process, and its initial goal was as a set of generic algorithms for functional-style programming, and not as a set of containers which is where it gets most of its use). All I wanted, initially, was a holder that would expand itself -- to a C programmer, stuck with fixed-size arrays, this seems rather revolutionary. And so it didn't seem strange that Java would have a separate library for containers. But Python doesn't even bother with fixed-size arrays. You just use a list, which is always there without importing any library, as common as air, as are dictionaries (Maps to C++ and Java programmers). Now, even sets are first-class objects. In C++ and Java, collections are intermediate level concepts, and so some programmers don't use them. It's quite difficult to know that some libraries are more important than others; in my initial experience with C, my tendency was just to write all my own code and not rely on library functions, so it was quite awhile before I understood that malloc() and free() had special importance, and the whole possibility of dynamic memory allocation (I really did come up the ladder from hardware). I now know intimately how lists and hashtables work, but I also wonder how different I might have been had I started with a language where dynamically-sized lists and dictionaries were just part of the fundamental toolset. My experience now, and what I see with those who started with Smalltalk, is that you take those concepts with you into languages like C++ and Java, and you are able to manipulate those languages more effectively as a result.

My point is that programmers are all on different positions on their own learning curve, and there's some intersection of that curve and the level of discipline that they and their team need. This is an issue that is based heavily in the human dynamic of the team. That is, it depends on who you have on your team and how they work together. Some teams benefit from the extra structure provided by a static language, others need the rapid abilities of a dynamic language.

However, much of the argument around static vs. dynamic languages seems to be about finding bugs. I will make two observations about this. First, both static and dynamic languages still produce bugs. And no matter how many static type checks a language includes, bugs still happen. I think there is a belief in some camps that we simply don't have enough static type checks in Java, and if we had more then eventually the compiler could guarantee provably-correct programs. And this leads to the second point: Java has a lot of dynamic checks. And it benefits from a lot of dynamic abilities, such as reflection. In fact, I think it could be safely argued that Java straddles the static and dynamic language worlds. For that matter, Python does a little bit of type checking during its compilation phase (and there is talk of adding more).

In the end, languages need, I think, to be opportunistic about when they can discover errors. And the best time to discover these errors is not always clear. Sometimes it's quickly obvious: it seems unlikely that array-bounds-checking at compile time is feasible, for example, so Java does it dynamically, at runtime (and C++ doesn't do it at all). Many of the arguments seem to be about when type correctness is established. The static approach is to force explicit declarations, the dynamic approach is to perform checks at runtime. In between is type inference, where you don't have to explicitly declare types but they're checked at compile-time anyway. An even more interesting approach would be a combination of type inference and dynamic checking, which produces the best of both worlds.

Perhaps what I most value about the dynamic language experience is that I feel it has opened my mind a bit more, indeed, as learning any language has. Even if much of your day-to-day programming is with a language like C++ or Java, I believe that learning a dynamic language will not only add another very valuable tool to your set -- and one which may allow you to solve "side problems" much more quickly -- but it allows you to go back to your "main" language with a new perspective, and one that will help you solve problems in a more effective and elegant fashion.

MindView Home Page

Not as They Seem

2005-02-18T12:16:00.000-07:00

Alfie Kohn has an essay about how rewards are counterproductive. He's written numerous books on similar topics.

Malcolm Gladwell (author of The Tipping Point) has just published Blink, which also talks about things that we assume to be one way, and are actually completely different. I referred to a speech he gave which you can listen to online here.

For some reason I find this kind of thing fascinating. It's something about having our "natural" assumptions turned completely upside down. I guess it it regularly reminds me that the world is not so predictable/boring as we come to expect.

This is also the motivation for questioning many of our assumptions about programming. I've had personal experiences where my assumptions have been wrong -- where I've discovered that something that I thought was helping was holding me back.

My friend Daniel commented:

I read something a while back about giving a reward BEFORE you start. That someone gave small bags of M&M's to groups before they started, and they performed much better, because they were happier. They don't have to be big things, just something small and pleasant sets the brain in a different mode. I now cannot find that article, even with my desktop google!

MindView Home Page

Static/Dynamic Theory

2005-02-16T12:32:00.000-07:00

One of the difficult challenges when discussing the productivity of dynamic languages is to make any sort of proof about said productivity. I believe this is because it's one of those synergistic, emergent systems, where everything taken together produces a surprising or unexpected result. But this makes it hard to come up with any kind of proof, and as a result we have a bunch of people who are primarily just speaking about their personal experiences trying to convince people who haven't had such experiences that it's a Good Thing ("Hey man, you gotta try some of this stuff!"). In our business, we are constantly being shilled into trying new products, technologies, etc., most of which have been a waste of time, some of which have been a collosal waste of time AND money. So we've learned to ignore most of these claims.

Oliver Steele offers his theory about why dynamic languages are more productive, folding in issues about testing, in Test versus Type.
MindView Home Page

Destructors in GCed languages

2005-02-15T11:12:00.000-07:00

Based on a conversation with Walter Bright, the creator of the D Language, a summary of my thinking on destructors in GCed languages:

1) If you have scoped objects, they can automatically call destructors at the end of the scope, because it's deterministic. However, this could cause confusion with:

2) Heap based objects should not have destructors called automatically, because garbage collection is not deterministic. If cleanup other than memory release is necessary, the programmer should be forced to decide when this happens, presumably with finally clauses. If cleanup is necessary, it must be determined by the programmer because the GC is nondeterministic. This leads to:

3) The value of the destructor for GCed objects is that it automatically calls base-class destructors in the proper order (most-derived first). Java abdicates any responsibility for cleanup other than memory release, which forces the programmer to generate their own "cleanup" methods and to be dilligent about proper order.

4) The biggest remaining problem is member-object cleanup. Member objects need to be cleaned up in reverse order of initialization. A destructor should automatically call member-object destructors, and if you don't expect the GC to call the destructor (which doesn't work anyway), you can assume that all member objects are still alive when the destructor is called. Therefore it is safe for the member object destructors to be called. Without this the solution is incomplete.

5) The one thing I could see adding to D is functionality to verify that destructors have been called if they exist. This would close the loop and solve the problem of destructors with GCed objects. The key is that the GC can't do it (as the Java designers learned with the multi-year finalize() debacle). But the GC can verify that destructible objects have had their destructors called by the time the GC is releasing the object.

Note that Python is able to get away with automatic destructor calls because it uses reference counting and thus the moment the reference count goes to zero the destructor is called. I.e.: it's deterministic in Python.

MindView Home Page

Computational Theology

2005-02-14T15:51:00.000-07:00

I was looking at Sun's Core Java Technologies Tech Tips for January 4, 2005, and I saw that Gilad Bracha is described as a computational theologist. In the Wikipedia, Theology seems to be about religion. Does this means that Gilad is someone who tends to get into religious debates about programming? Or is this a pay grade at Sun? Perhaps someone can explain this term to me.

[Later]

I think I see what Gilad is trying to say. One of the things I respect about the Jewish tradition is that they are taught not to accept the holy books at face value, but instead to question and argue about them. I think he means that he brings this approach to the design of programming languages. The risk in using such a term is that it could be misunderstood all over the place.

MindView Home Page

Gosling on SWT

2005-02-11T08:24:00.000-07:00

In a presentation to an Australian user group, James Gosling said some things about SWT that I thought were a little far out, so I asked Chris Grindstaff (who helped me with the SWT section in TIJ4) about it, and he allowed me to publish his comments:

"From memory, there were some OTI Smalltalkers 7-8 ago who did try to convince Sun they were going down the wrong path with AWT/Swing. Swing is very analogous to VisualWorks Smalltalk's approach of emulating the widget toolkit. OTI had been native UI toolkits in Smalltalk for many years and thought it was a better approach. A lot of those folks are responsible for SWT today. They thought emulated was the wrong way to go and they still do.

"Gosling says AWT == SWT. That's sort of true but less true than more. The big difference between the two is AWT is very much least-common-denominator across all platforms. SWT isn't. The other significant difference is AWT chose to hide the emulation layer in C. In other words, java.awt.Button is the same on all platforms, while the native peer differs on each platform. One of the consequences of this is porting is harder, some things are in Java, some aren't. It also makes for a larger footprint because a java.awt.Button has fields for it's size, bounds, etc that the OS also has.

"In SWT the org.eclipse.swt.Button Java/class is different on each platform. The SWT lib does nothing but stuff methods straight to the OS. One toolset and less duplication.

"Gosling also claims SWT is way simple. That's not true either. It's not as full-featured as Swing but that's also by design.

"The API matching Windows is somewhat fair, but much preferable to least common denominator with AWT. Where something doesn't exist on a platform an emulated version is created. But again that's better than not implementing a tree, table, or notebook, example, just because they don't exist on one of the targeted platforms.

"Porting and consistency aren't nightmares on other platforms. One of the beauties of moving the widget toolkit code from C to Java is your platform gurus can program the widget toolkit in Java using Eclipse. So when you look at the SWT source for a org.eclipse.swt.Button on Windows it makes a lot of sense to a Windows guru, likewise for the widgets on the Mac, they make lots of sense to a Carbon guru.

"The proof is in the pudding. You rarely see an AWT application, even most Swing apps are ugly and OS strangers. You can get close but never close enough. For example when MS added theme support in Windows XP, SWT got those for free. There are more and more SWT built applications appearing. In general, why struggle to emulate pixel by pixel what Microsoft, Apple, and all the Linux developers are doing for you? Don't reinvent, use.

"You can also check out the article I wrote for Linux magazine, although I probably don't say anything I haven't said here: SWT: Eclipse's Secret Weapon"

MindView Home Page

Static Versus Dynamic Attitude

2005-02-09T11:17:00.000-07:00

A reply to Bill Venners about his Static Versus Dynamic Attitude posting:

I think your point about the language "leading you in a particular direction" is key. I've found that each language tends to make me think about doing things in a particular way, and they often seem like they actively prevent me from thinking about other possibilities. Witness the C++-ish influences on the designs in GoF.

But if I learn a new language that has a different way of thinking, then I can go back to a previous language and apply that way of thinking, just as you are now able to think about tuple-ish things in Java whereas it may not have occurred to you before. It's the beginning of a differentiation between saying "everything is an object" and "there are different kinds of objects."

On the other hand, your statement about the tuple reflects more of your static-mindedness: "From a safety perspective, a tuple seems even more error prone than a Map, because I have to get the order correct on both sides, not just the names." When you think about it as a Python tuple or a Java container of Object, your static-mind says "the compiler can't check it, so any object can go in any slot, and I could get it wrong." But if you realize that in both Java and Python (but not C++, which may be where the original roots of this "problem" lie -- however, with C++ templates you can create a type-checked tuple), type checking also happens at run time, you realize that the first time you try to use one of these objects that you've put into the wrong slot, you'll find out about it.

I think the biggest problem when thinking about this is that static-mind is very deterministic and unforgiving, and says "if I can't find out about it at compile time, all is lost." In reality, you can only find out about some problems at compile time, anyway. Dynamic languages shift the discovery of problems more towards runtime. If you can accept that there are plenty of problems that can only ever be detected at runtime anyway, it's possible to look at this issue with a little more perspective, and to calm down the stridency of the static-mind a bit.

MindView Home Page

The Economy of the Small

2005-02-06T07:42:00.000-07:00

The term "Economy of Scale" has always been used to mean "Economy of Large Scale," but things have been happening -- primarily due to the Internet -- that have changed this. Ebay is an excellent example: it has made money from the beginning, all the way through the dot-com crash and beyond, as if it works in an orthogoal playing field. Which it does: millions of successful businesses, some of them lasting only for a single transaction but successful nonetheless, most of the longer term ones operated as part-time ventures. All stable and thriving.

The big-economy media has only been able to report this through the window of Ebay as a big business; the smaller aspect is occasionally noted but not really seen as an important data point. Because of its skew, the big-economy media has gained its own small-economy bugaboo: bloggers. People are creating their own newpapers using feed readers, selecting their own columnists. "News" is no longer fed only through the controlled pipe of newspapers and television, and we can only hope it will get worse for the big-economy media, who have never had any competition except others playing the same game. This is only getting started; feed readers are still in their infancy and most people haven't started using them yet.

The first time the phenomena of "the Internet has fundamentally changed things" hit me was at the Software Development conference, where I had created and chaired both the C++ and Java tracks for a number of years. At some point I could see it coming: the trade show portion of the conference (where they made the bulk of their money) made no sense anymore in the face of the Internet -- especially because this was software, which people could find out about by going to a web site, and usually downloading a demo. The cost of renting a space and sending a team to man the booth was enormous (especially in terms of lost productivity), and if you could have a 24-hour booth presence on the Internet, why bother? Other conferences were failing, and I did not want to stand by and watch the SD conference, where I had put so much time, effort and emotion, auger in. So I left.

After several years, I checked it out again, and discovered last year that it had not only survived the bloodbath but that I had a really good time. It may be that, because most other conferences of this kind (general, not product-specific) have vanished, everyone is coming to SD.

A central organization can be a good thing in some cases, and whether or not Ebay has an impact on Walmart, I think the two serve different enough purposes that Ebay is not going to threaten Walmart (even if Walmart had any conceivable way to fight back). Another example is Linux, and although Microsoft is doing its best to fight back it seems like they are operating in different spaces, and so, short of a completely fascist government outlawing open source (not entirely impossible in the current climate), it would seem that Microsoft must eventually adapt or die. Adaptation is certainly possible; Microsoft has value worth paying for and that value just needs to shift. Not all software can be free, because some of us need to pay expenses.

In any case I'm speaking at SD again this year, and really looking forward to it. As a speaker, I'm able to attend the pre-conference tutorials as well as the sessions, and everything looks fascinating. You can find details on the calendar.

After having some experiences organizing private conferences based on Open Space technology, this year I'm holding two small public conferences. Like comparing Ebay to Walmart, these are quite different from what SD even could do, I think, because they are topic-focused, inexpensive ($300 for a three-day conference), and a completely participatory experience, and Open Spaces are so energizing and engaging that they don't fit in a more formal conference like SD. Obviously I think the formal conferences are still important (as I said, I'm really looking forward to SD), but my experience of Open Space conferences is that the energy that you come away with is completely different, and that's why I want to hold them -- I get at least as much energy and excitement out of the conferences as everyone who attends, because it really is a group learning and sharing experience instead of one person giving information to a group (which still has its place). You can't really believe it until you've experienced it, because it's kind of counterintuitive. But in every single Open Space event I've participated in or held, people come in saying "I don't believe it," and come out saying "this is one of the best things I've ever done!"

You can see the topics on the calendar: Building Better Software and LAMP Patterns & Practices, but you'll also see that I have no links or signup forms yet. That will happen sometime after TIJ4 is completed.

MindView Home Page

More powerful than C++, too

2005-02-03T09:18:00.000-07:00

There has been some notice of my comment that Java is now approaching the complexity of C++. I should note that there are things that I can do with Java that I wouldn't dream of doing in C++. For example, I'm now trying to finish the Annotations (new J2SE5 feature) chapter, and this topic has gotten me involved with bytecode engineering, which is rather astounding. Kind of a back-end macro facility (in the sense of Lisp macros, which I have only a vague sense of). I've been using Javassist, which, while not trivial, is way easier than the alternatives.

I would still want to use C++ for certain types of programming: things that have to be close to the hardware and/or fast, but not so big or complex that I would have to start worrying about memory management. For problems that involved C++ in this way I would probably start by writing the system in Python, then creating components in C++ that had to be close to the hardware or fast (although for fast, Pyrex seems to be the up-and-coming way to solve that problem).

But for all my carping about Java (most of it still well-founded, I think) I have to admit that J2SE5 has been a breath of fresh air over previous versions, mostly because it does feel like they've been trying to make it "friendlier to the programmer" with things like the foreach loop, autoboxing, and the new enumerated types. The possibilities of annotation and bytecode engineering are quite mind-bending (annotation support for Active Objects keeps bouncing around in my head). Now that I've finally gotten up most of the learning curve for generics and can at least push them through hoops (note that they don't jump by themselves), I've found them to be at least tolerable -- but I do have the same feeling with them that I did when I finally mastered operator overloading in C++ (and understood temporary objects): I get this kind of smug, aren't-I-clever-because-I-know-all-these-tricks feeling which we techies love but is usually a bad sign because it means you've mastered something that is just arcane, and that doesn't have anything fundamentally insightful involved (like, I think, design patterns do).

Java attempts to straddle the gap between statically-typed languages like C++ and dynamic languages like Python, Smalltalk, Ruby, etc. In fact, I think that Java's biggest contribution may be as a bridge to dynamic languages, just like C++'s contribution was a bridge from procedural to OO.

I've seen people get very uncomfortable about the dynamic aspects of the language; the possibility that an exception may be thrown seems to be the same as an error to these folks. But I think that the dynamic nature of Java is its greatest strength; some C++ projects break apart because they try to make the language do dynamic things when it wasn't designed for it, and in those cases Java can, fairly easily, make the transition.

MindView Home Page

jre/lib/ext no more?

2005-02-02T10:53:00.000-07:00

I vaguely remember hearing about a security issue that involved the jre/lib/ext directory. I do have the latest J2SE5 installed, and at least one program that used to work now runs into problems when trying to load something from a Jar file that is in the jre/lib/ext directory, but not in the classpath. It seems to work when I add the Jar to the classpath.

So I'm guessing that the days of saying "just put the jar in the jre/lib/ext directory" are no more. Can anyone confirm/deny this?

[Later] If I do a Java installation, I seem to get two jre/lib/ext directories. I have a directory called "ProgTools" where I put Java, and a jre/lib/ext appears there, and that's where I've been putting the extra Jars. There's a second one that appears under "Program Files" regardless of where I install Java. Oddly, Ant seems to find the ProgTools jars during compilation, but if I try to run a program by hand (without Ant), I have to explicitly put the Jar in my classpath to get it to work. What I haven't tried yet is taking all the extra entries out of my classpath and moving the Jars from the Progtools to the Program Files jre/lib/ext directory.

The thing is, I'm pretty sure it was working before I upgraded to J2SE5.01. There may be an configuration variable somewhere that says which jre/lib/ext directory to use.

MindView Home Page

Technical arguments

2005-01-31T20:50:00.000-07:00

I thought this was pretty funny. And it helps keep things in perspective.

MindView Home Page

People use the tools that work for them

2005-01-31T14:16:00.000-07:00

This is a brilliant essay. He talks sensibly about many things, and explains why my intuition has been telling me all this time that things like SOAP and their ilk are just wrong, somehow.

For some reason, partway through reading it, I had a sense of remorse for wasted college years. I had an Asian roommate once who had a study group. At the time I thought it was "an Asian thing," and perhaps it was, something brought from a culture that can live so closely together (although Confucious, I think, had a lot to do with that). But when I saw "The Paper Chase," I gained another data point about study groups, and attending a meeting of the Silicon Valley Patterns Group I saw a lot of value in working together. Jeremy Meyer came out to Crested Butte and helped me put together the Annotations chapter for Thinking in Java 4e, and I'm sure we got much more done together than we could have separately. Synergy exists, and I want more of it.

Perhaps it's because I'm trying now to schedule a couple of Open Space conferences (this Summer in Crested Butte) to produce this kind of synergy that I think back on what I might have accomplished in college if I had taken the step of forming study groups. Instead of working in isolation, we could have at least discussed and struggled with the ideas presented in class. Learning could have been collaborative. But are we guided away from collaboration by the idea that we must "do our own work?" And for that matter, do most college study groups devolve into test-preparation sessions?

I still think it would have been beneficial. Hey, why isn't this something that professors try to help the students do? At least ask if people want to form study groups, and give them time and chalkboard space to do so? That would be free for the university, but I think it could greatly benefit the experience (yes, I know there are the TA-led sessions, but that's not the same. The study group puts the responsibility on the individuals, and is thus a much better learning experience).

If you're still a student, try forming a study group, and tell me how it works out.

MindView Home Page

newlines

2005-01-31T03:18:00.000-07:00

One of the messages produced by Lint4J is this:


Don't hardcode newline characters, use System.getProperty("line.separator") instead.

I started to change these, then began wondering if it was really necessary. I thought "what do they do in the JDK?" I found System.getProperty("line.separator") called six times in the entire JDK, whereas \n was used over 1400 times.

I'm going to go out on a limb here and guess that, if System.getProperty("line.separator") was important at one time, something has changed so that \n is now safe to use, at least for building strings. Cross-platform input scanning might still need line.separator.

Neither PMD nor FindBugs suggested this fix, either. In fact, it was quite interesting to see the differences in the kinds of things suggested by the three different tools; they were all pretty different. It seems like we could benefit from a common database of guidelines that any tool could use. Then the tools could compete on quality of implementation (if you've used these tools you know that there's generally a bit of wierd messing around just to get them to run) and features like auto-fixing, rather than their rule sets.

MindView Home Page

Does OOP help?

2005-01-27T08:05:00.000-07:00

From a reader:

...I myself have been in the process of questioning my beliefs with regards to programming. I discovered object-oriented programming in 1997 using first Turbo Pascal For Windows and then Java. When I look back now, I cannot help but wonder if the reason I was attracted to OOP was not so much because it was a better way to program, but simply because it was new. I had never seen it before and relished the challenge of mastering a new skill. Seven years later, however, I have seriously begun to question the entire OOP paradigm.

Does OOP really help us to write better programs? The problem with starting with that question is that it concentrates on the technology. I believe we should start with ourselves. What do we need to know to program well? What does a competent programmer look like? What is the best way(s) to think about programs? It is difficult to recall any discussions which have tackled these questions. Yet it seems that we need to answer them satisfactorily before we can then take the next step and actually decide what programming paradigms help us to program well.

Others have had doubts about OOP every now and then. Here's an opinion that was just published, for example. But all of that author's books are on machine code, so it seems doubtful that he knows OOP well enough to be able to give serious comment on it. People who are in the machine code world tend also to scoff at C.

OOP is an organizational tool, and yes, I've found that it -- especially when combined with design patterns, and a knowledge of OO design (disclaimer: things that I write and teach about, but I wouldn't if I wasn't fascinated with them and didn't believe in them) -- does help tremendously when organizing code and projects. But depending on where you're coming from -- like the machine-code guy -- it may not make sense right away, or be initially harder to use if you come to it with a particular mindset. I also started in electronic engineering, mostly focusing on chips and then adding more and more (assembly) code until the code started getting unruly, and that's what pushed me towards higher-level languages. But with that background, my brain tended to think about what the machine was doing rather than about what problem I was solving (that is, I was dwelling in the Solution Space rather than the Problem Space), and it definitely took time and struggle to get my head around ideas that others (especially those darn Smalltalkers) seemed to bandy about effortlessly. Indeed, it feels to me like only in the last few years, with the aid of languages like Python (and yes, even Java when compared to C++), that push me away from thinking about the low level stuff (rather than simply allowing me to think at a higher level if I put in the effort, as C++ does), have I really begun to be able to think naturally in Objects. And usually, when I start to believe that this is what I'm doing, something fundamental will pop up and slap me, such as this, which will make me realize that there's yet another element that I was either unaware of, or took so much for granted that I wasn't teaching it.

I suppose the best way to put it is that "you can learn the features of a language, but the way you use those features is an endless series of life lessons." Without State, or Strategy, or Factories, etc., polymorphism is indeed a bore. But with knowledge about interesting ways to assemble these features, the world becomes exciting and powerful.

Is OOP the end of the line for programming? Certainly not. It's just a building block on the path, just as procedural programming was. The procedural style of programming was clearly a good thing, and it gave programmers who were formerly chained by the limits of complexity of assembly language great leverage and the ability to accomplish far more with much less effort. But eventually it ran out of "reach," and OOP appeared. The reason these questions come up is not, I think, that OOP has "failed," but rather that we are beginning to see the edges of what OOP is capable of, even as the majority of folks are still coming up the learning curve of what has become thought of as the dominant, accepted paradigm.

Where does OOP fall short? Concurrency, certainly, which promises to become a major issues as multiprocessors become commonplace. Objects just don't seem to conform too well to concurrent programming; the only thing I've seen with any promise is the Active Objects design pattern, which basically serializes method calls to an object which is being driven by a single thread and queue (quite similar to most GUI programming systems such as Swing, but more formalized so that the programmer doesn't have to work as hard, which I think is key). Many have suggested functional languages, which tackle the problem from the other extreme by doing nothing that requires serialization. Personally I don't see the benefits of OOP being discarded in order to solve the concurrency problem; instead, I suspect that a hybrid of ideas will be incorporated into OOP.

I also think that improvements could be made with object packaging systems. One of the great benefits of Objects is the ability to create and reuse libraries, which I do believe may be the greatest leverage we can get out of them. And yet the library packaging and reuse mechanisms are still, to my mind, in a kind of infancy. C and C++ librarians have always been a platform-specific arcana, and Java, while consistent across platforms, involves figuring out Jar files and the never-ending miasma of Classpaths. And as much as I know about Python, the library creation and installation process is still a mystery to me (every time I go to figure it out, it just seems like too much effort, which is a bad sign). This seems to be the place where all the language designers lose interest (perhaps Ruby will have something valuable to offer in this area). But it isn't something that requires a great new paradigm, but rather just some focus on making the packaging issue effortless for both the programmer and the end user (unlike Java, which imposes the nightmare of Classpaths on both the programmer and the customer).

Your questions are appropriate in that they place the puzzle in the realm of ourselves and our psychology rather than assuming that OOP is broken and/or we need some different technology. Indeed, I believe that the benefits of OOP come from the fact that they are closer to the way that we think about problem solving that procedural programming. It's also valuable to notice that parts of every problem involve procedural thinking, and to realize that the initial pitfall was in thinking that (therefore) everything was procedural. What we've discovered, instead, was that procedural thinking is a subset of the bigger picture, just as we are perhaps discovering that OOP is also a subset of a bigger picture, which involves other issues like concurrency. What we may discover is that we collect over our lifetimes a bag of approaches (kind of a Chain of Responsibility pattern), along with ways to know when to apply them. Perhaps our languages may come to resemble this structure, adding things like backward chaining and neural networks to the mix.

Your questions have also sparked another thought for me. I've been reading Harrison Owen's "Open Space Technology" book. I've already had several very successful experiences using Open Spaces, and have been thinking about holding a conference or two this summer based on that technique. But Owen emphasizes that for an Open Space conference to work, you must have an overarching question that establishes the theme of the conference. I realized that the previous Open Spaces I've been involved with have had that question, although it was usually implied and not explicit. Your questions, however, could in fact establish a theme for a conference (in fact, I was involved in something like this in the past, the Writing Better Code summit, but we did not use Open Spaces and I think it would have made all the difference if we had). It's also the kind of conference where everyone has valuable experiences, and sharing those experiences are all that is necessary to impart that value to other participants. And the product of such a conference (a Wiki of notes from the sessions) would be valuable to everyone.

So I propose a 3-day conference called "Building Better Software," which will use Open-Space technology and be held sometime this summer here in Crested Butte. Size will be limited to 70 participants, and cost will be $300.

MindView Home Page

Thinking in Java Seminars this Summer

2005-01-26T08:49:00.000-07:00

I'm beginning to plan the summer seminars and events. I've had two recent experiences which have made me rethink the approach I've been taking for seminars. One was last Fall's seminar for Sandia Labs, where I was forced to throttle back from my usual attempt to fit too much into a given amount of time. The result was that everyone seemed to have a much better experience. We didn't cover as much, but everyone learned it much better, and therefore they learned more.

The second experience is the process of writing the Fourth edition of Thinking in Java. This language, which was once hailed (admittedly, by the PR flaks at Sun itself) as being "much easier than C++" really isn't anymore. Sure, sure, lots of improvements and your efforts are usually much better spent, but still both complicated and complex in many cases. It's become clear that an introductory course will only be able to use some basic generics. It would just torture people to try to give any depth to Annotations or Concurrency or any of the more sophisticated ideas that are developed in the book. Indeed, the book itself has been separating into an introductory portion followed by more advanced (albeit necessary) topics.

So we're really talking about two seminars here. The introductory one, for people who are new to Java, Objects and the like, which will also work for non-C programmers (previously I would assume you knew basic C syntax, and the Thinking in C multimedia seminar is being reworked in Flash for internet distribution, so that should help even if C is no longer required). And the intermediate one will cover things like Type Information, Generics, Collections in Depth, Concurrency, Annotations, Enumerations in Depth, GUIs, Discovering Problems, Introduction to Analysis and Design, and will introduce design patterns along the way (I've been adding more of these to TIJ4). This one will be useful even for experienced Java programmers who want to catch up to the new features of J2SE 5 or to get more depth on some of these issues.

My question concerns scheduling. I can imagine that there might be some people who would like to take both seminars back-to-back, but I could be completely wrong about that. Work schedules etc. might make 2 weeks off completely unreasonable, and even if someone wanted to take both seminars, they would want them separate so that it didn't keep them out of the loop at work for more than a week. On the other hand, Europeans, Australians and other overseas-travelers might really like a 2-week stint.

Please add comments as to your preferences. Thanks.

Java Brain Drain

2005-01-24T09:57:00.000-07:00

I can't be the only one noticing this. Calvin Austin has just left Sun, following on the heels of Josh Bloch and Neal Gafter. These are not easily replaceable persons; these are leaders. The fact that they are all splitting within a few months of each other doesn't seem like coincidence. Something's going on. I've never had particularly good contacts within Sun -- anyone know the scoop?

Flash Animation on Generics

2005-01-24T09:44:00.000-07:00

You have to see this, it's combined nerdism (the next Star Wars + Java Generics). See it before he gets sued by someone.

I would like to see an example of "Autoboxing leading to NullPointerException," as Yoda asserts at the end of the piece. Can anyone post a code fragment in the comments?

OpenOffice: not yet

2005-01-22T17:02:00.000-07:00

I occasionaly fantasize about giving up Word and moving to OpenOffice, and someday even being able to live on a Linux box. But I push Word pretty hard and am able to do many interesting things with it, so unless OO gave me more and better it won't happen. One of the appealing things about OO is that it stores files in a true XML format, so I could imagine writing Python programs to do transformations on my books. The last time I looked at the XML format that Word used, it seemed like it was some strange proprietary thing, or that it could only be stored and not recovered, or something else that was too much of a limitation.

I told my friend Gary about OpenOffice, and he promptly went and tried it, and reported this:

Unfortunately, OpenOffice is quite inferior to Word, et al. I just uninstalled it and returned to Word. OpenOffice is woefully slow; it makes Word look like a high flyin' text editor, and it's not smart about memory. So if you load more than a couple of big files (the biggest I tested was 100+ pages, 8mb), it gets confused on the memory swapping. Finally, it did some repagination on a document, which I suspect doesn't mean much, but it does make me suspicious enough, and I have to stay compatible. So thanks, but I must stick with those bad guys in Seattle. Fun checking it out though.

While OO is wonderful as a free system for most folks to look at small documents that aren't too complex, it sounds like I'll have to wait awhile before I can hope to use it for my book development system. I'll keep watching and hoping -- I think there are lots of things about Linux that will eventually coalesce and make it a very compelling system for the average user.

I've even thought of a Mac laptop -- that instant-on, instant-off thing is so compelling, especially on a laptop. But the fact that J2SE5 is not yet available on the Mac and there's no word on when it will be, that kind of kills it for me (especially after Jobs claimed he was going to make the Mac the premier platform for Java. Oops, please Apple don't sue me for saying something about you in a blog).

PHP !?!

2005-01-18T10:29:00.000-07:00

Over the past few months I've had this impulse to look at PHP. Perhaps it came from seeing the ".php" extension in a lot of places. But usually I could just lie down for awhile and this impulse would pass. After all, PHP is the web language for the unwashed masses, right?

I just skimmed through the PHP tutorial, mostly looking at Objects, exceptions, that kind of thing. Classes in PHP5 have a syntax that's sort of a weird amalgam of Java, C++ (at least, the scope resolution operator), Python and Perl.

I discovered that I didn't run screaming in disgust from PHP. I didn't find it offputting; the fact that they lifted syntax from these other languages was not only reassuring (they didn't feel the need to invent everything from scratch, but instead stole proven syntax from elsewhere), but made me think that the time-to-productivity with this tool could be quite short because I know the syntax from elsewhere. The fact that PHP is designed to solve the web problem, and just the web problem (although I've heard that people have used it to create desktop applications), is also appealing. I'm sure I'll continue to run Zope for its basic functionality, and for things I can do with simple Python Scripts, but I just don't seem to be able to keep all the arcana necessary for Zope programming in my head, and I'm convinced only full-time Zope programmers have actually waded through the slings and arrows of the ill-kept Zope documentation and really know what's going on, because they use it on a day-to-day basis. I'm also interested in looking at Quixote, but as many have pointed out, no really standard Web system for Python has arisen; on the contrary, more seem to appear on a regular basis. And for my needs, I just want something that's a straightforward solution to creating interactive web pages, and I don't want to have to remember a completely different world view every time I have to go back and build new web stuff (this is why Quixote is intruiging -- it's basically Python with help).

The only thing that gave me a slight lurch in the PHP syntax is the Perlish $ in front of variables. But my concern was that it was going to be all Perl from then on, and that didn't happen. It seems to be a fairly isolated case, and the absence of the rest of the Perl syntax it really isn't an issue.

So I'm intruigued, and will probably want to experiment with it. Once the Java book is done. Enough distractions, back to it.

No more getContentPane()!

2005-01-17T09:57:00.000-07:00

I just discovered (and tested, on my codebase) that in J2SE5 Swing, you no longer have to get the content pane in order to add something to another component. This was always wierd, because you could call add() and -- even though it was acceptable to the compiler -- nothing would happen; instead you had to call getContentPane().add(). (There's probably something in here about the failure of static type checking to solve the problem of calling the wrong method.)

At the same time (and this may have been the case for awhile; I might easily have missed a meeting about Swing), all the examples in the Swing Tutorial now have main()s that look like this:


public static void main(String[] args) {

  // Schedule a job for the event-dispatching thread:

  javax.swing.SwingUtilities.invokeLater(new Runnable() {

    public void run() { createAndShowGUI(); }

  });

}

That is, now you are not supposed to start up a Swing UI directly from main(), but instead you must add a task to the event queue.

After all these years, apparently someone discovered a race condition from starting it directly in main(). I wonder how many people were bitten by this? (And how many new fundamental issues like this will show up over time?) Well, Swing is a large, complex library that has bitten off a huge challenge, so there are bound to be issues like this. But after spending the last few days with SWT, that library seems more straightforward in a lot of ways, probably because it's trying to leverage the underlying OS rather than replace it. In general, SWT feels like it's trying to "just build GUIs" rather than "create a whole new world for GUIs." I suspect that each has its place depending on what you're trying to do, but I'd be tempted to use SWT unless there was some compelling need for Swing, if only to provide a more familiar experience for the end user. I've seen a number of designers say "we think the standard UI (usually Windows) is bad, so we've reinvented it," without discovering whether the end user wants their UI to be reinvented. The point of a standard UI is that you don't have to go up a learning curve every time you run a new application. People want every application to look roughly the same, because "figuring out your cool new UI" is not the problem they want to solve.

So much for Eclipse 3.1 Compliance

2005-01-16T15:54:00.000-07:00

As an experiment, I imported the current code base for Thinking in Java 4e into the latest Eclipse 3.1 beta, since everyone has been saying how very compliant it is to J2SE5. After fooling around a bit to get rid of classpath and package import issues, my code base, which builds without problem, reported 1021 errors in Eclipse. A lot of these errors came from other errors, and one of the show-stopper starting errors is this one:


The type List is not generic; 

it cannot be parameterized with arguments <Character>

For the perfectly legitimate line:


List<Character> chars = new ArrayList<Character>();

It accepts the code if I change the line to:


ArrayList<Character> chars = new ArrayList<Character>();

I think it's safe to say that, with a bug that fundamental, it's going to be awhile before Eclipse 3.1 is J2SE5 compliant.

Too bad; the other parts of it looked promising.

Thinking in Ruby ... not

2005-01-09T13:41:00.000-07:00

People have been bugging me about Ruby again, suggesting I write "Thinking in Ruby." Here are some fragments and replies from one conversation. The writer is talking about available books:

The first is the "Pragmatic Programmers Guide to Ruby" ... This book isknown as the "PickAxe Book" and is the standard reference most Rubyists keep at the ready... The online version covers Ruby version 1.6.7. A newer version of the book has been released recently and is updated for the current version of the language (1.8.2 ) . http://www.rubycentral.com/book

I know Dave and Andy, and we had a conversation about this -- like this reader, Andy said that he had tried Python and it never made sense to him. I think there are a set of people for which that is true, and I'm starting to see that Ruby is a good alternative for them, since otherwise they'd probably just be stuck in Perl.

The next reference material would be "Why's Poignant Guide to Ruby". This, by far, is the most unconventional piece of reading I've ever found, but it has enough humor interjected to keep people reading. It's a bizarre piece of work, but you may find it to your liking. http://poignantguide.net/ruby

Yes, I saw this when it was just coming out. This guy is brilliant, and I hope that someday he might translate his work to Python. In fact, his work is one reason that I wouldn't try to compete on an introductory level. The only thing that could happen would be (maybe a couple of years down the road) a "Thinking in Patterns with Ruby" but that would only be after the Java, Python, and probably C# versions.

The last of the "standard" tutorials that I would refer you to (of the ones I've read myself) would be the Ruby tutorial that comes in the standard install. A copy is available through the Ruby Online Documentation website: http://www.ruby-doc.org/docs/ruby-doc-bundle/Tutorial

Having another world class author that got fired up and started releasing books would be wonderful ( The thought of a 'Thinking in Ruby' book is just too much ... )

I just don't see it happening, other than (only possibly) the patterns book, which would not be introductory (and patterns would be the level at which I would be interested in exploring the language, anyway). I'm very happily ensconced in the Python community, and every encounter I have had with Ruby -- so far -- has not made me see the power in it.

I find that it has a less-than-elegant syntax because of its Perl influence (but if you like Perl, perhaps Ruby is the right fit for you). Again, to a Perl programmer this might be a great improvement. Look at one of the first examples from "Why's Poigniant Guide," where he's asserting that Ruby is "the language of our thoughts":

5.times { print "Odelay!" }

Or this:

exit unless "restaurant".include? "aura"

This makes sense if you used to be a Smalltalk (or perhaps Forth) programmer, and I know one who started with Python and has moved to Ruby. It also makes sense if you grew up Pennsylvania Dutch, where they say things like "Throw Papa down the stairs his hat," and "Throw the horse over the fence some hay." (This theory has been confirmed by a Pennsylvania Dutch Ruby Programmer.)

Of course I only get bits and pieces, usually from people who don't know Python trying to convince me that Ruby is better, but so far as I've seen it doesn't have the more interesting features or libraries that Python has. There's only one programmer I know -- the aforementioned former Smalltalker, which I think was the major influence -- that might have had a really good understanding of Python (I don't really know if he did) that has moved to Ruby.

Nonetheless, someday when a seminar is being taught when I am available, (ideally one of Dave and Andy's) I will take it. I think that would be the best and easiest way to get a grasp on it. I find that learning new languages is always good for new insights into programming.

And it's certainly possible that I might like it. Hey, the first time I picked up a Python book (after two intense months with Perl had come crashing down upon discovering how lame references and objects were, which I suspect was a major impetus in the creation of Ruby), I threw it down, saying "Indentation to determine blocks? That's the most ridiculous thing I've ever seen!" I eventually picked up the book again. A couple of years later, I was responsible for that year's Python Conference T-shirt "Life's better without braces!" (cartoon of a smiling kid who had just gotten his braces off).

So who knows? But don't hold your breath; my plate is very full right now and Python is the most functional language I use, so at the moment it's sort of "when they pry my cold, dead, fingers off my Python documentation."

But hey, if Ruby pushes the right buttons for you, great. It's probably the tool that will make you most productive right now, and that's what you should use. It doesn't really matter whether I am a fan (yet).

Finding out what the customer really wants

2005-01-06T10:54:00.000-07:00

IT Conversations has a great speech by Macolm Gladwell (author of "The Tipping Point") about marketing and customer feedback, and how people don't tell you what they really want. This destroyed some of my preconceptions and really made me think. He starts by telling the story of the Aeron chair (apparently the most successful office chair in history) and how all the focus groups universally hated it.

I've long struggled with a variant of this problem: how to know that a public seminar will have a certain number of attendees before deciding to hold it. If I could do that I'll bet I could give a lot more seminars. I think it requires some kind of upside-down inversion-of-control thinking to solve the puzzle. Such as: "groups form around various ideas, and when they reach a certain number of committed members they can commission a seminar." A big problem is that it's not a casual commitment since it's a traveling-and-full-immersion experience, and people have date conflicts etc. But the upshot is that if there's a way that a group of people can form and say to me "we have this many people willing to pay this much for a seminar on one of these dates," we'd work something out. I would imagine that the early committers would get the benefit of lower prices, as incentive to commit, and those that came after the seminar was officially announced would have to pay more.

Productivity

2005-01-02T11:23:00.000-07:00

I think my fascination in the past few years has been in productivity and how (sometimes very subtle) things can increase and decrease productivity. Also the psychology behind this -- how we can often cling to things we are convinced are productivity enhancers which are actually reducing productivity.

And is there any way to awaken ourselves when we get stuck? Or is it like premature optimization -- regardless of how often we say "first make it work, then make it fast" to ourselves, we will always be inexorably drawn into the trap of thinking "well, I could do it that way but I know it would be slower."

Need SWT Fans/Volunteers

2004-12-31T10:29:00.000-07:00

I'm planning on putting an SWT section into the GUI chapter of Thinking in Java 4th edition. I've begun learning about SWT (I like it), but I realized that I might be able to get help from the SWT fan base on this. The goal would be to translate the Swing examples to SWT, so that people would be able to compare and contrast the two approaches (I won't have space for all the examples, but I'd like to see what they look like first so I can choose the most interesting/compelling ones). If you're interested in volunteering for this, email me at Bruce@EckelObjects.com. I suspect there will be several folks interested in this so we'll try to coordinate and prevent duplicate efforts, and post the results via a wiki and/or a weblog.

NetBeans 4.0 & IDEs

2004-12-31T07:32:00.000-07:00

Since NetBeans 4.0 is (cleverly) an optional rider on the JDK5 update that just came out, I thought I'd give it a try. Initially it looked quite promising, as it said it would use my existing sources and ant file (which works just fine as a standalone ant build). It brought them in and at first seemed to recognize all the files with no fuss, but alas, the classpath once again reared its ugly head. The documentation that desribed how to set the classpath was out of sync with the windows that I was looking at while following their directions, and no amount of adding classpaths let it recognize that my imports actually existed. It didn't seem to pay attention to the classpaths set in my ant build files.

It also didn't bring up a lot of the files in the "Files" view of the project. At first I thought that this was because many of the book files don't have package statements, but then I discovered some unpackaged source files that did show up. Quite confusing.

So I think Netbeans has potential, but like many IDEs too much time has been spent on advanced features and not enough on the "initial experience." It doesn't matter that I'm not an idiot and I might be able to figure these things out eventually, I still want an IDE that's idiot proof, because

I don't want to struggle with it; I have other problems that I want to solve and the IDE should be a helper and not something I have to work against.

When I teach, I don't want seminar attendees to get lost in the IDE, either. That's not the problem we're trying to solve in a seminar.

Before you say "well, Eclipse does..." or "Idea is ...", yes, Eclipse is probably the closest thing to ideal, but until now it hasn't supported J2SE5 (or at least, people claim that it now almost completely does -- but I'm using all the J2SE5 features). Also, it's heavyweight, very project-oriented with lots of interesting distracting stuff so I hesitate to get too deep into it because it's too much of a hurdle in introductory classes. But it's free, so in more advanced classes it could make sense. However, by then people are hooked into an editor and are not interested in using a different one because they're not productive, so I say "use whatever you're comfortable with."

For introductory classes, the best luck I've had so far is with JEdit, because it helps without getting in the way of creating one-file exercises.

And JetBrains Idea costs significant money, so I can't just say that's what we're using. On top of that I've had no luck getting a real review copy. Many months after Java One when they said they'd get me a copy right away, they gave me a license that would timeout. Yes, I could afford to buy it, and I do buy products when it makes sense. But I'm sorry, there's a line; I'm not going to invest a lot of effort into something that, if I like it I would end up promoting, just to have the license timeout. So I haven't gotten re-hooked into Idea (although I liked it very much when it initially came out).

(1-6-05: Milani Marketing contacted me as a result of this blog entry, and has promised a non-expiring license. So I may get sucked back in after all. And I've also heard from a reader that the Eclipse 3.1 beta is very J2SE compliant, although I try everything so I would probably encounter the non-compliant parts. It's not clear how much help these will be for Thinking in Java, 4th edition, which is due at the end of February, but one or both will certainly be helpful when working on Thinking in Patterns, slated as the next project).

Findbugs

2004-12-30T08:12:00.000-07:00

This morning I got FindBugs working; for some reason when I tried it some months ago I had problems.

So far it's been helpful, finding a number of things that I either wasn't looking for or had overlooked.

One mistake, which I've reported, was when it said that you should use StringBuilder instead of String when building complex Strings. It turns out that the Java compiler is fairly clever when compiling Strings; it converts them to StringBuilder objects.

Try it. Compile this (based on the code that FindBugs presented as 'bad'):

public class Test {

  Integer[] field = new Integer[10];

  public String toString() {

    String s = "";

    for (int i = 0; i < field.length; ++i) {

      s = s + field[i];

    }

    return s;

  }

}

Then run

javap -verbose Test

See all the StringBuilder operations?

(Later: see the first comment. Apparently the compiler only does a credible job on very simple cases).

This describes my world

2004-12-29T09:56:00.000-07:00

A delicate balance is necessary between sticking with the things you know and can rely upon, and exploring things which have the potential to be better. Assuming that either of these strategies is the one true way is silly. Graydon Hoare

Another, even trickier, dimension is deciding when to explore.

Here is an insightful speech on managing change.

Finding Unused Imports

2004-12-28T14:23:00.000-07:00

I've posted a new article with a Python program that finds and eliminates unused imports in a collection of Java programs. It's brute-force and slow, but you can go away and leave it running and it will do the job.

Good Essay on Design

2004-12-23T20:18:00.000-07:00

Elliotte Rusty Harold's XOM Design Principles describing the principles he used for designing his Java library for creating and manipulating XML is also a great read about design in general and design decisions in particular. One thing I like is his penchant for questioning existing knowledge and practices. For example: "Prefer classes to Interfaces" is a nice one.

Blog Spam

2004-12-21T09:38:00.000-07:00

I started getting blog spam (what a lovely thing :-() so I've turned the commenting back to "registered users only." But I think it's simple to create an account for commenting.

Javadoc broken for enums?

2004-12-19T16:53:00.000-07:00

Here's another puzzle, stripped down as much as I could so you can see the problem:


import com.sun.javadoc.*;



public class TestEnum {

  static void test(Doc d) {

    System.out.println(d);

    if(d.isEnum())

      System.out.println(d + " is enum");

    if(d.isEnumConstant())

      System.out.println(d + " is EnumConstant");

  }

  public static boolean start(RootDoc root) {

    for(ClassDoc cDoc : root.classes()) {

      System.out.println("-----Class------");

      test(cDoc);

      System.out.println("------EnumConstants------");

      for(FieldDoc fd : cDoc.enumConstants())

        test(fd);

      System.out.println("------Fields------");

      for(FieldDoc fd : cDoc.fields())

        test(fd);

      System.out.println("------Methods------");

      for(MethodDoc md : cDoc.methods())

        test(md);

    }

    return true;

  }

}



enum Foo { bar, baz }

If you use the following command line:


javadoc -doclet TestEnum  -package TestEnum.java

Here's the output:


Loading source file TestEnum.java...

Constructing Javadoc information...

-----Class------

TestEnum

------EnumConstants------

------Fields------

------Methods------

TestEnum.test(com.sun.javadoc.Doc)

TestEnum.start(com.sun.javadoc.RootDoc)

-----Class------

Foo

------EnumConstants------

------Fields------

Foo.bar

Foo.baz

------Methods------

Foo.values()

Foo.valueOf(java.lang.String)

So it sees the enum Foo, but it doesn't seem to recognize it as an enum. Similarly, it sees the fields but not as enum constants.

I'm thinking this is broken, but maybe I missed something. Anyone know?

New Ant Timout Issue

2004-12-18T11:52:00.000-07:00

I just installed the latest version of Ant and discovered that my timeout arguments:


  <target name="Applet1c">

    <java

     classname="Applet1c"

     classpath="${basedir};${basedir}/.."

     dir="../gui/"

     error="tmp.txt"

     failonerror="false"

     fork="true"

     timeout="4000"/>

  </target>

Which used to nicely terminate the application (after 4 seconds, in this case), now terminate the application and hork out an exception stack trace. Does anyone know if this is the intended behavior, or a bug? Thanks.

Because Unanswered Problems Are Always Hard

2004-12-16T15:40:00.000-07:00

Ian Bicking does a good job of trying to answer the question I posed in Static vs. Dynamic: "This last point is a major puzzle -- we believe that static type checking prevents bugs, and yet a dynamically-typed language produces very good results anyway."

I like the way he thinks. Perhaps we'll be able to sit down and talk about these kinds of things, or even do an openspace, at Pycon.

Powerpoint is not evil

2004-12-16T14:22:00.000-07:00

This is wonderful. It takes Edward Tufte's The Cognitive Style of Powerpoint (which does a thorough job of bashing Powerpoint presentations) and presents it as Powerpoint bullets in a very compelling and succinct way -- I'd rather read the powerpoint bullets than Tufte's version, because I get it in a clear and dense fashion.

Powerpoint and its clones are a tool that makes it easy for anyone to create bullet-point presentations, add graphics, etc. Why are people surprised that if anyone can do it, anyone will? Naturally there will be lots of mediocre presentations and of course poor presenters will use it as a crutch. But people were creating bad bullet points and reading their slides to the audience before Powerpoint came along. People who need a crutch will grab for the nearest one. To suggest that it's Powerpoint's fault for making it easy to create a presentation is silly, and Aaron Swartz demonstrates this in a lovely roundabout way.

Where Are We Stuck?

2004-12-16T10:55:00.000-07:00

I have just realized that I have been thinking about (for at least the past several years) issues around "what are we doing just because we've always done it (and are used to it), and what are we doing because it actually gives us true leverage?" Many of these questions have come up from working with Python, which has a very different perspective on many issues, and so I often find myself surprised about the way something actually works vs. my perspective on it.

For example, how valuable is "private," really? It sounds good on paper, but in practice how often do things really get violated? At some level (such as the whole Windows API being exposed and the repercussions of that) access control becomes important, but perhaps the class level isn't the place for that, because often we end up working around access control when trying to use another class. I don't have the final answer on this -- I'm just asking the question.

I've also questioned the efficacy of checked exceptions in the past (not exceptions themselves, which are a clear win as the single form of error reporting, but the enforcement of checked exceptions). I ask questions like this because my real interest is in how we as programmers, development teams and companies can become more productive.

Java Slipping?

2004-12-12T11:56:00.000-07:00

I received a question from Paul Jansen at Tiobe Software, which maintains a site that tracks the popularity of programming languages via search engine statistics. Paul noted that the popularity of Java seems to have fallen in the last 12 months, and wondered if I had any thoughts about why.

Although it is interesting to note that search engines are reporting less queries, I don't know if I would take that one data source as definitive. I note that this month, C is the most popular language on the Tiobe index. Although there are certainly plenty of C programmers out there I have a little bit of a hard time believing that is the case, especially since C++ is broken out from C in that analysis -- in my experience it has been very hard to tell if someone is a C++ programmer still programming in C.

It's certainly possible that Java is falling in popularity. However, I'm not going to draw a conclusion based on search engine feedback.

There are a number of possibilities that might explain lowered search engine stats:

There is an awful lot of noise on the web about Java, and so if you do a search your results may also be very noisy. I know that I do a web search as a last resort, anymore, because it's so much work and so often it's fruitless. So perhaps people are just giving up on web searches and going to other sources.
The aforementioned other sources have been getting better. Sun's own Javadocs are far better than what we traditionally had in C or C++, so those programmers may be compelled to hunt the web while Java programmers can hunt through Javadocs on their local machines. There are a fair number of other electronic resources, such as my own Thinking in Java.
Java programmers may be going to specific web sites such as JavaRanch, JavaLobby, Artima, TheServerSide, etc. to do their searching, in order to produce better results because of point #1. Thus, you will not see this searching on www.tiobe.com/tpci.htm.

I'm not saying that it isn't possible that Java has "slipped in the ratings." Just that I won't draw that conclusion based on Google/Yahoo searches alone.

Commenting

2004-12-12T04:51:00.000-07:00

Someone pointed out that this blog had only allowed members to post comments. I've changed this so that anyone can comment. This should make discussions easier, although I'm hoping it doesn't impact the noise ratio, which has been good so far (there's also an option to restrict commenting to "members of this blog" only, although I haven't explored what that means).

Language influence

2004-12-11T07:40:00.000-07:00

From a reply to an email query:

It's always difficult to know when code clarity/maintenance problems arise from the language vs. the people programming in it. The success of Java is partly due to getting rid of many of the difficult language aspects of C++, but I think it also "encourages" a stricter form of programming which helps less experienced programmers to write somewhat better code. At least in theory; I've seen horrible Java code written by master's and Ph.D. students. However, I'm not yet convinced that a more constraining language really helps when being used by less experienced programmers. In the end I think it's the team culture and the desire of the individual programmer towards self-improvement and clarity of expression that will make the difference.

XML Odyssey

2004-12-09T21:18:00.000-07:00

I've posted a new article about some experiences creating XML with Python.

Multiple Return Statements

2004-12-06T09:30:00.000-07:00

Ted Hill writes:

Hi Bruce,

I attended your design seminar in Crested Butte this summer. Thanks for hosting a great seminar, I thoroughly enjoyed the entire experience.

On my current job we work in Java and are putting together a list of "best practices" for our company.

The idea is that we will run the PMD inspection tool on our Java code.

One inspection that some of our developers favor is:
"There must only be a single return statement within each method"

PMD classifies this as a "controversial" inspection. They do not comment on why it is considered controversial.

I notice that in your book "Thinking in Java" you have several examples of multiple returns within a method.

I personally favor using it for 'breaking' out of loops as you do on the top of pg 490 (Thinking in Java 2nd Edition) in the code for demonstration hashed Map.

Here is the method:
public Object get(Object key) {

  int index = key.hashCode() % SZ;

  if(index < 0) index = -index;

  if(bucket[index] == null) return null;

  LinkedList pairs = bucket[index];

  MPair match = new MPair(key, null);

  ListIterator it = pairs.listIterator();

  while(it.hasNext()) {

    Object iPair = it.next();

    if(iPair.equals(match))

      return ((MPair)iPair).getValue();

  }

  return null;

}
So I am wondering:

1. What is your personal feeling about the "single return rule"?

2. Do you know anything about the history/background of this rule/inspection?

I happened to be thinking about this recently when refactoring some code, noticing that taking some kinds of inline code and turning it into a method with multiple return statements can really clean things up. It is definitely an idiom that I find valuable for that very thing.

I believe the history of this may come from Dijkstra's famous "goto considered harmful" statement, which has been massively misunderstood, in my opinion. I think the problem that Dijkstra was talking about was wild jumps from any part of the code to any other part, without constraint. The closest thing we have in Java is the labeled break and labeled continue, which you'll notice are jumps, but are very constrained.

I think that multiple return statements only seem to be jumps. But they all have to go through the "return chute" and they must return the specified type, the stack gets cleaned up, finally clauses are executed, etc. So not only do I find them completely safe, but their benefits in terms of clearer code are significant.

The counter-argument to this may be that it could be hard to see all the places where you exit a method if they are distributed throughout the method. My feeling is that if this is the case then your method is probably too large and complex and that you should probably refactor it to make it cleaner. Or you should choose not to use multiple returns for that method. Enforcing "no multiple returns" because you might end up creating a confusing method is a bad policy, I think. If someone is going to create a confusing method, preventing them from using multiple returns probably won't do any good, and it will certainly harm the clarity of other methods.

Guidelines and tools to point them out are helpful, but at some point programmers need to develop a sense of good code. I don't think there's any way around that. The only way to enforce it, I believe, is code reviews, ideally in a group so that everyone can learn from them (as noted in a previous entry, this can be tricky because you want to focus on improvement rather than making people feel bad).

Java 5 Class File Format Puzzle

2004-12-03T09:39:00.000-07:00

I've posted a New article about the changes in the Java 5 class file format (which I can't seem to figure out). Please add a comment on that article's wiki page if you know the answer -- thanks. (Later: got the answer from a reader. The web works.)

Testing private methods

2004-11-23T13:40:00.000-07:00

While researching ways to "sneak around" interfaces and package access (I seem to remember hearing there's some way to do this), I came across this:

http://www.artima.com/suiterunner/private2.html

I'm with Bill on private method testing. Unit testing allows you to test at the granularity of the method, and the reason you break code up into private methods is to manage complexity. But if you can't test at that level, it's defeating.

My guess is that they were backfilling when they said that. Because JUnit can't test private methods, let's say it's a bad thing to do.

How do you tell someone their code/design is bad?

2004-11-19T09:16:00.000-07:00

In the comments following Weblogs Forum - OOP Case Study: The Bank Account Class (Part 3), Michael Feathers states "...where I think we fail in the industry is that we have not accepted the reality that there is a lot of really crappy code out there. A lot. ... We need to realize that many people have screwed up and that there are things we need to do to fix that beyond helping people acquire better design skills."

Although this is certainly true, what I'd really like to know is what are these things that we need to do? I think this is more in the realm of psychology. A big question that I have for Michael is: How do you tell someone that their code or design is bad in such a way that you don't encourage them to slam the door in your face? Do you confront them or do you try to present ideas that may lead them into making their own conclusion? Or are there other ideas for this (which sounds like it may be more like something in Esther Derby's domain, and folks like her).

Java and operator overloading

2004-11-18T08:38:00.000-07:00

A consistent form of amusement since the beginning of Java is how the designers bashed operator overloading in C++, without really examining the problem, which is basically that operator overloading in C++ is complex and hard for the programmer to get right.

However, with a garbage collector and other improvements afforded by Java and C#, operator overloading becomes fairly straightforward, as the Java designers would have noticed had they looked at Python, a language which predates Java and which supports operator overloading without any fuss. C# has since demonstrated that operator overloading could have been added to Java without making it painful (at this point in Java's lifetime, however, there are probably more important problems to be solved).

In the meantime, Java's String class with its + and += shows how difficult it was for the Java designers to excluded operator overloading from the language. Sometimes operators are helpful. Or, put another way, the thing about syntactic sugar is that it's sweet.

I thought of all this when I came across the following in the Javadocs for BigDecimal:

For the sake of brevity and clarity, pseudo-code is used throughout the descriptions of BigDecimal methods. The pseudo-code expression (i + j) is shorthand for "a BigDecimal whose value is that of the BigDecimal i added to that of the BigDecimal j."

Whoever wrote this class was clearly missing operator overloading.

Static vs. Dynamic

2004-11-16T19:07:00.000-07:00

I've added a new article here. (As I have changed the RSS feed to this web log, I will announce all articles here).

IT Conversations and Podcasting

2004-11-15T14:45:00.000-07:00

On the drive down and back to Albuquerque, I listened to nothing but interviews and presentations from the IT Conversations web site. I was amazed that I had managed to put so many onto a single MP3 CD that it would last me all those hours.

There were a small number of these that I skipped past, but in general I found value in almost every one, including technical insights that were quite useful. A fair number of the presentations were from conferences, so I had the benefit of hearing some of the conference talks without having to go. It seems that more conferences would do this, at least capturing things like keynote presentations and panel discussions that are already open to the public (I'm thinking in particular of the Software Development conference, but I could easily imagine something like the Python conference capturing a number of their presentations for IT Conversations). It seems like the downside is negligible and that it could only help promote the conferences.

They had a number of discussions about podcasting itself, and most of the comments were ones that made sense to me -- in particular that it's a different medium because you can't skim it like you can a web log, and thus the content and editing become much more important. I would like to further explore the possibility of podcasting but issues of hosting become important. Not just the volume of data transfer that becomes necessary, but If people require the enclosure model then that's something that I won't want to have to create and manage (I've got too many other things to do). I'll need some other system to host podcasts for me, ideally in the same way that blogger does it (i.e. free and easy). That's a bigger commitment because of the bandwidth requirements.

If you know of such services please note them in a comment.

Composition vs. "wiring"

2004-11-15T13:18:00.000-07:00

At last week's seminar I created a new exercise during the threading portion. The goal of the exercise was to get people comfortable with the idea that threading can cause collisions over shared resources, and that the synchronized keyword prevents these collisions.

While people were solving this exercise I discovered that although the concept of composition was clear to everyone, the idea of setting up a number of object instantiations and wiring them together (by handing a reference of one object to the constructor for another object), was very unclear. As this is, to me anyway, one of the fundamental idioms for solving problems, I've found it interesting that either (1) I wasn't conveying the concept (probably thinking it to be obvious) or (2) somehow the way we approach objects distracts us from such a fundamental idea. It's almost as if an electrical engineer who spends too much time with equations and models doesn't know how to actually wire together a set of chips.

Another observation that comes from this is the overuse of Singleton. I have noticed that there seems to be a movement in parts of the design patterns community to deprecate or even ban Singleton. I wonder if this isn't because of all the emphasis on the design of classes and how you use inheritance and polymorphism in interesting ways, and the underlying assumption that people will naturally know how to design programs using these classes. Without more explanation about how you create objects and wire them together into a program, singleton may be what people tend to think about.

Just enough Java

2004-11-15T10:10:00.000-07:00

Last week I gave an in-house seminar in Albuquerque. For the last few years I've been focusing on more advanced seminars like Thinking in Patterns and Designing Objects & Systems. So this is the first time that I have given anything like "Thinking in Java" for quite awhile. On top of that, this group had very mixed programming experience and they asked that I give just enough Java to get the to JDBC, Servlets and JSPs, since what they wanted to do was basic web programming.

As a result, I was forced to strip out everything from the seminar that was non-essential. This was a particularly interesting exercise. When I go to all the trouble of digging in and figuring everything out, I tend to get fascinated/attached to particular subjects and examples and have a hard time letting them go. It all seems important. But in this case I had the challenge of not overwhelming significant parts of the audience, and also leaving enough time for introductory JDBC, Servlet and JDBC exercises on the last day. I had to let go of a lot.

I also wanted to introduce more exercises to break up the lectures. From my experience with the Thinking in Patterns seminar, I find that people work best if you give them one concept and then immediately have them do something with that concept.

At the end of the week, everyone seemed quite happy, including me. I discovered that giving people less, but making sure they had a strong understanding of what they get, is far more satisfying that giving them lots of stuff but with only a passing grasp of what they see.

This seminar has made me re-think what I'm doing. Not Thinking in Java per se, but the seminars that come from the book. Originally I created the seminar and developed the book from the seminar, so I always thought in terms of a one-to-one mapping between the book and the seminar. But Java continues to expand, increasing its surface area like an expanding sphere. It has long past the point where you can cover a significant part of it in a week unless the group is already reasonably proficient in the language.

So it appears that there need to be several seminars, serving different needs. For example, there are a lot of people who are motivated to use Java just so they can do basic web programming with JDBC, Servlets and JSPs. Subjects like reflection, serialization, RMI, native methods, in-depth collections, etc. are not essential to such a pursuit. On the other hand, there are folks who know the basics of Java and would like to have more depth in some of the other interesting areas of the language. There are at least two seminars here, rather than the former single seminar.

Delays in Email Blog Posting

2004-10-31T13:30:00.000-07:00

I note that the "EJB 3.0" entry that I posted on Thursday didn't actually appear until Saturday. I sent this in via email, and got no indication that there was any kind of bounce or delay on it. If anyone knows anything about how this is supposed to work I'd appreciate comments.

The value of email blogging is great, because it lowers the bar and allows me to pay more attention to the expression of ideas and less to the posting mechanism, which has held me back in the past from posting the more arduous "articles" on MindView.net. So I'm hoping that the hiccups on blogger.com for email posting are just that, and not an indication of bigger problems.

The problems with podcasting

2004-10-31T13:28:00.000-07:00

This article summarizes the issues I was talking about with Mike Levin.

The general problem is not really any different than blogs: they may not have content or form that interests you. The brilliance of blogs is that they are how the "custom newspaper" is formed. I could never quite believe the prediction that you'd go to some big news service who would create your custom paper for you, but I didn't realize that personally choosing blogs based on their writers was the answer.

But the addition problem with "audio weblogs" is that they are linear -- there's no way to skim them. And I don't think that metadata is the answer. I think the answer is the same as with blogging: the creator of the presentation needs to work hard to keep your interest and keep up the forward momentum, so that you not only keep listening, but you keep coming back.

I also think that there will be a variety of formats and different people will be drawn to different formats. Some will like more of the background chatter, and others (like me) want something to listen to during long drives, and for us the "chatty" aspect isn't interesting.

Amazing: EJB 3.0

2004-10-29T23:52:00.000-07:00

Today I saw a presentation by Michael Keith that blew my socks off. It
was about the history of EJBs and the new (upcoming) EJB 3.0.

My experience with EJBs has been dismal. Every time I've tried to wade
in and understand them, I've gotten mired down with cruft, and have
lost interest. Some people that I trust had even started saying that in
a few years, EJBs would be legacy technology. On top of that, the way
people have actually been building things seems to have been diverging
further and further from EJBs (e.g.: Spring and Hibernate).

So my expectation was that EJB 3.0 would just be more incomprehensible
cruft added on the already existing incomprehensible cruft. I went to
this talk primarily so that I would hear the history and be armed to
damn EJBs once and for all.

All I can say is: wow. I never could have imagined that something as
big-corporation-driven as EJBs could do such an incredible reversal.
EJB 3.0 is so amazingly different than previous versions of EJBs that I
could look at example code and understand it immediately. I could even
imagine putting an example of this in Thinking in Java (alas, it won't
be out for some time yet, far past the book deadline, and even then
it's not clear when there will be implementations).

The original EJB spec was developed in a vacuum, based on the fantasies
of a group of people about how these things would be developed. The
reversal has come because someone (who Michael mentioned was actually
on the original team) said: let's base the new spec on what people are
actually doing, for example in Spring and Hibernate. And so it goes
from being incredibly obtuse to incredibly simple, from demanding that
you jump through hoops to jumping through the necessary hoops so that
you don't have to. It makes use of annotations and POJOs and relational
databases and all kinds of things that you want to do anyway. And the
best part is that it looks like something I want to play with, rather
than run screaming from as I have with previous versions of the EJB
spec. I actually want to use these things now.

I'm amazed. Kudos to everyone who's working on this.

Colorado Software Summit, Wednesday

2004-10-27T21:36:00.000-07:00

Noel Bergman explained JNDI and LDAP. He's clearly one of the techies
who is fascinated by the technology in itself, because he showed things
that you could do with the technology. I began pestering him for a
motivation. Not that I think it's useless -- it seems to be a very
clever and well-thought-out solution. But when you look at a design
pattern, which this smacks of, the first thing you find out is the
intent and motivation, so you know where you want to apply this pattern
and what kind of problem it solves.

JNDI appears to be a central repository of information structured in a
hierarchy. As far as I can tell, it can be any kind of information
including serialized objects, but there are formalisms for more common
types of information. Apparently LDAP servers are typically designed
for reading more than writing, so they aren't intended to be the
equivalent of databases.

JNDI/LDAP seems to cut across languages and platforms. In addition,
LDAP servers apparently scale and distribute transparently. All
attractive features. Noel said he was changing a configuration system
that used XML so that it used JNDI/LDAP instead. This sounded like it
could be a good idea, but I couldn't get a clear answer of what his
motivation was to make the change.

So it sounds like a very interesting and useful technology, but I'd
like to know more about the design motivations for using it.

Gary Ashley talked about various open source issues and ways to use it.
To help make his point, he had put Linux on his laptop, and had not
been able to get the mouse working. I love the whole idea of Linux and
open source, but there always seems to be a cost, for example herculean
efforts to get some aspect of the software working. Or difficult and
confusing configuration in general, which seems to be a legacy of Unix,
where you are encouraged to create little languages for everything. Not
everyone knows how to create easy-to-use little languages.

I have to say, Linux has the best screensavers, and it seems to have
continuing evolution in screensaver technology. Windows screensaver
development stalled long ago as far as I can tell.

Jasper Report Builder is apparently an open source way of building
reports. These can for example be output in PDF. There is a plugin for
Eclipse so that you can do drag and drop form building. Might come in
handy.

NetBeans: VB for Java?

2004-10-26T10:34:00.000-07:00

I was talking to someone at the Colorado Software Summit
during the welcome reception Sunday night and I mentioned
how Java didn't seem to be generating too many desktop applications
considering how long Java has been around. It seems like the
server is the place for Java.

He said he had been using Sun's NetBeans and really liked it a lot,
and that creating GUI desktop apps was very simple. He made it
sound like it was on par with VB, or at least that it simplified
creating the UI enough that it was very worthwhile. Sounds like it's
worth a try.

I wonder if it works with SWT components, as well?

Commenting is a problem

2004-10-21T13:49:00.000-07:00

It appears that HTML pre tags don't work, so posting code is not
possible. That's a problem. Could be pretty serious for me, since a
lot of blog communication is going to be about code. This is
definitely a wall -- It won't even pay attention to indentation.

I don't know if I can use PRE tags in the blog entry itself. Here's a
try:


def spewFile(fileName):
    for line in file(fileName):
        print line

new ArrayList<String>

RSS

2004-10-21T13:31:00.000-07:00

Well, FireFox detects an RSS feed when it's pointing to this page, so
it appears they have this automatically available (although I've never
actually had any tool that does the RSS subscription thing so I don't
really know what to expect). Ding. Another feature taken care of. There
must be a downside to this thing. Although Daniel said Google owns it
so I suppose there might not be, or perhaps it's just very tolerable.

Hmm. They must be thinking about podcasting or audioblogging or
whatever it's supposed to be called. That would be nice but I don't
see them providing the bandwidth.

I wonder what happens with URLs. Here's a raw URL:
http://mindview.net/WebLog
Here's one inside HTML tags:
weblog

Because it does the RSS thing, I could probably remove the RSS from my
site (since it took a lot of bandwidth) and instead put it here.
People could subscribe to this RSS, and then when I publish an article
I could simply announce it here. Also, I could just use the feedback
mechanism they have here.

Who would have thought it could be this easy?

2004-10-21T13:17:00.000-07:00

Ok, it's clear that email blogs work, based on the posting below, which I successfully sent through email.

I guess as a programmer I always tend to think of the complexity of
things. And of course I've been bugging Bill about this for what seems
like at least a year, and it's just more than he was ready to do, so
it did seem hard. But now I've spent about 20 whole minutes and I have
something working (not like I actually programmed anything, of course,
just did some searching through the help system).

So the temptation, of course, is to just make this my "casual thought
blogging" area (does anyone really want to read my non-programming
thoughts?). Or make it about stuff my audience wants to read, but less
formal, and with allowances for slightly off-programming remarks. I
guess I'll have to give it some thought now that I'm face-to-face with
the real possibility rather than just imagining "wouldn't it be nice
to have email blogging."

It is awfully nice, though, just to be able to write an email and not
go through the big operation required to publish an article. I find
these "lowering-the-bar" factors can often be extremely important. If
you only have to do "a few extra things" then those barriers can often
prevent you from doing something.

And now for something Completely Different

2004-10-21T13:09:00.000-07:00

Email Blogs! Hooray!

One thing that bugs me is imagining these ideas for months or years
instead of trying something out. Of course, I didn't actually *know*
that someone else had implemented this feature, and that I could have
had it up and running in no time.

Of course, I've invested time in my "article blogs" now, and I suspect
I'll still keep those, possibly renaming them as articles.

I'm not sure what the limitations of blogger are. What if I get a lot
of hits? Do they have RSS implemented (I think so). It's certainly
tempting to do my "though blogging" here.

Well, let's just see if this works.