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.