Telling All Subclasses to Do What Only Some Can Do

[Stevens Miller]

This might call for more specifics, but I'll start by keeping it as general as I can, to avoid confusion over irrelevant details.

I have three classes, an abstract superclass and its two concrete subclasses. One of the subclasses must do something when its doSomething method is called, but the other never does that same something. I have a collection of these objects and, from time to time, I want to iterate over that collection and get each of the instances that can do something to do it. I have this code:

import java.util.ArrayList;

abstract class Employee
{
    void doSomething()
    {
        // Subclasses that actually do something will override this method.
    }
}

class LazySlob extends Employee
{
    // LazySlob does nothing.
}

class EagerBeaver extends Employee
{
    @Override
    void doSomething()
    {
        System.out.println("It's great when you're part of a team!");
    }
}

public class Main
{
    public static void main(String... args)
    {
        ArrayList<Employee> staff = new ArrayList<>();

        staff.add(new LazySlob());
        staff.add(new EagerBeaver());

        for (Employee employee : staff)
            employee.doSomething();
    }
}

This gets every Employee who is an EagerBeaver to do something, while every Employee who is a LazySlob does nothing, without the iterating code having to determine which is which. In effect, this is tell-don't-ask, by telling an Employee to do something that you know it may not do, but you don't care if it does or not. The important thing is that you can tell it to do something and, if it doesn't do it, you don't mind, nor do you need to know.

Now, something one of my heartless critics Stephan van Hulst once told me, about avoiding needless functionality, has me wondering if this is a good example of tell-don't-ask, or am I missing a superior alternative?

[Fred Kleinschmidt]

Yes, this is the way you should do it. Consider that at some later time, someone may modify LazySlob so that it actually does have some code in its doSomething method. You don't have to make any changes in your main program, so everything works as it should.
The incorrect way is for your main code to have something like

  for (Employee employee : staff) {
      if ( employee instanceof SomeSublassOfEmployee ) {
            employee.doSomething();
      }
  }

If you had done something like the above, you would have to alter the main code every time someone made a change to any subclass that added or removed the body of doSomething.

As a side note, it is usually a good idea to ALWAYS use curly braces around the body of if-blocks and do loops.

[Stevens Miller]

Fred Kleinschmidt wrote:Yes, this is the way you should do it.

Thanks!

As a side note, it is usually a good idea to ALWAYS use curly braces around the body of if-blocks and do loops.

Yeah, I usually do and, as a Ranch bartender, I should follow best practices. I just like to have as few lines as possible in a SSCCE.

[Winston Gutkowski]

Stevens Miller wrote:Yeah, I usually do and, as a Ranch bartender, I should follow best practices. I just like to have as few lines as possible in a SSCCE.

Fair enough, but line 29 should still be:
  List<Employee> staff = new ArrayList<>();


However, in answer to your question: I don't think this really has much to do with "Tell, don't ask", which is much more to do with hiding irrelevant aspects of your API from clients, and coding in an imperative style, rather than whether methods should be "optional" or not.

As a simple example: Tell, don't ask advocates would say that, before version 8, java.util.Map was missing an add() method because it is a distinct operation from a put().
I further say that the new method should have been called add() or insert(), not putIfAbsent() because the first two names are behavioural, while the last one is procedural.

But I digress again. To me the business of optional methods isn't black and white. Personally, I try to avoid them, but some - like List.add() - simply cry out to be defined. For the remainder, I'd say apply the 80/20 rule: If the method is implemented 80% of the time, then it's probably reasonable to say that it's part of the "behaviour" of a superclass; if not, you should consider whether either your hierarchy needs changing, or you need an orthogonal interface.

My 2¢.

Winston

[Junilu Lacar]

There is another way to look at this, and it's one that takes Stephan's side. If you find that there are often more LazySlobs (and possibly others of the same ilk) than EagerBeavers, perhaps it's time to rethink your design and ask if it's appropriate to have that thing that only EagerBeavers do be a separate interface and segregate the EagerBeavers from the riffraff for this particular processing.

OTOH, a no-op default implementation could be a perfectly fine approach as others have already noted.

[Stevens Miller]

Winston Gutkowski wrote:...line 29 should still be:
  List<Employee> staff = new ArrayList<>();

Agreed .

Tell, don't ask advocates would say that, before version 8, java.util.Map was missing an add() method because it is a distinct operation from a put().
I further say that the new method should have been called add() or insert(), not putIfAbsent() because the first two names are behavioural, while the last one is procedural.

I might quibble with you, there. Without wanting to seem like a believer in the self-documenting code fantasy, I do believe in the sense of descriptive names. At first impression, "put" and "add" appear to be synonymous. To the extent they can be said to be non-synonymous, that would have to be because the difference between them somehow suggested the "if absent" behavior of the add method, making that name just as "procedural" as "putIfAbsent" is. To me, a name is descriptive or it is not, but a name can't be procedural. If the name describes what the method does, that's a good thing, no?

[Junilu Lacar]

Stevens Miller wrote:[Without wanting to seem like a believer in the self-documenting code fantasy, I do believe in the sense of descriptive names.

Then I've been living a fantasy these past few years. Self-documenting doesn't mean you don't write comments when and where they are truly useful. I don't see where the cynicism comes from.

[Stevens Miller]

Junilu Lacar wrote:If you find that there are often more LazySlobs (and possibly others of the same ilk) than EagerBeavers, perhaps it's time to rethink your design and ask if it's appropriate to have that thing that only EagerBeavers do be a separate interface and segregate the EagerBeavers from the riffraff for this particular processing.

Sure, there is always the possibility what I initially think is a some-do/some-don't distribution of implementations turns out to be more of an almost-all-do/some-are-really-something-else-entirely distinction. I think that's akin to Winston's 80/20 metric. In my actual case, the objects that behave differently are all created at run time, with no reliable way to predict how many will be "doers" and how many will be "not-doers." Further, in my actual case, there are more than two subclasses (with the deliberate intent also being that the number of subclasses can grow over time). Every subclass might be a doer, or it might not (to get into the hairy details I initially avoided, all of the subclasses work together in a big, linked data structure, but some start threads, while others only execute their code on those threads without starting threads themselves; the idea is to be able to start and stop them all without having to be concerned with which ones start threads and which don't).

[Stevens Miller]

Junilu Lacar wrote:

Stevens Miller wrote:Without wanting to seem like a believer in the self-documenting code fantasy, I do believe in the sense of descriptive names.

Then I've been living a fantasy these past few years. Self-documenting doesn't mean you don't write comments when and where they are truly useful. I don't see where the cynicism comes from.

I wouldn't call it cynicism, but what you are referring to comes from years having to decipher programs written by people who defended their paucity of comments on the claim that, "the program documents itself," when, in fact, the program did no such thing.

Descriptive names are great and, as soon as I got access to languages that allowed them (as opposed to those that limit you to only a few characters, don't preserve case, or can't handle an underscore), I became a practitioner of their use. But, both before and after that, I have been forced to work with code written by people who simply refuse, as though it would be some kind of sin, to write a single comment into their source (and a lot of that was Macro-11 assembly code). In 40 years of writing programs, I've noticed that most of the people who argue against ever using comments also impress me as lazy. When I don't have to cope with their code, that's fine. When I do, well... I've had my life's fill of people who believe they don't ever need comments, and the rise of the "self-documenting code" movement isn't helping me with that.

[Junilu Lacar]

Stevens Miller wrote:When I don't have to cope with their code, that's fine. When I do, well... I've had my life's fill of people who believe they don't ever need comments, and the rise of the "self-documenting code" movement isn't helping me with that.

Well, you musn't let your bad experience with people who aren't doing what they say they're doing taint your impression of the idea of writing self-documenting code. I for one am a big proponent of clear, intention-revealing code that doesn't require comments. The example I always use to explain the concept of self-documenting code is this: https://www.industriallogic.com/xp/refactoring/composeMethod.html. In my experience, less than 10% of developers I have met in the workplace have the awareness and sensitivity to recognize that a few simple applications of rename, extract, and compose method refactorings can go a long way to increase code clarity. It's not unusual for me to spend 5 minutes with my programming partner(s) trying to find an appropriate name to assign to something. Sometimes it takes a lot of discussion and experimentation with the design to figure out what the appropriate name is but really what we're doing with all that time is discovering the real intent of the software and how these things fit into achieving that goal.

Again, this is not to say that I don't write comments either. I tend to write JavaDocs more often than not for public methods and I'll always leave a DEVELOPER NOTE or IMPLEMENTATION NOTE comment where I think an explanation of WHY something was done in a certain way is warranted and helpful. I let the code explain the WHAT and HOW it gets things done.

[Winston Gutkowski]

Stevens Miller wrote:I might quibble with you, there.

OK, but hopefully you understand why the first part of what you're quibbling about is specifically applicable to "Tell, don't ask" (TDA), and why you're question isn't - at least not without quite a bit of qualification.

In TDA terms, it's perfectly reasonable for a method to "do nothing" if, and ONLY if, it is a pre-defined outcome of a business (or application) process. This, however, is entirely different from the absence of code - as might happen with an "optional" (or default) method - even if the effect is basically the same.

I'm struggling to come up with a good example at the moment, but if I think of one, I'll let you know.

Winston

[Stevens Miller]

Junilu Lacar wrote:Well, you musn't let your bad experience with people who aren't doing what they say they're doing taint your impression of the idea of writing self-documenting code.

Agreed and, to be frank, I think my hackles would not be raised if we all simply agreed to use some other phrase instead of "self-documenting code." Since I have, indeed, had a lot of bad experiences with people who stood on the claim that comments were never necessary, even the notion of taking "self-documenting code" seriously seems, to me, to risk validating what I know to have been some truly bad practices.

I for one am a big proponent of clear, intention-revealing code that doesn't require comments.

"Clear, intention-revealing code" works a lot better for me than, "self-documenting code" does. But, I do feel a slight shudder upon reading "code that doesn't require comments." Could we compromise on, "code that doesn't require a lot of comments?"

The example I always use to explain the concept of self-documenting code is this: https://www.industriallogic.com/xp/refactoring/composeMethod.html.

That's actually a great example! Good code can and should be written in ways that convey what it is doing, even if that means adding a few levels to the call stack by moving easily understood bits of code into well-named routines. That is definitely an example of clear, intention-revealing code.

In my experience, less than 10% of developers I have met in the workplace have the awareness and sensitivity to recognize that a few simple applications of rename, extract, and compose method refactorings can go a long way to increase code clarity.

Heh. Same here. (Good thing none of us is in that other 90%, eh? ) And you raise an interesting point: Comments can help one understand inscrutable code, but we'd all be better off if, instead of getting them to add comments, we could get the writers of inscrutable code to adopt methods that would make it, uh... more scrutable.

It's not unusual for me to spend 5 minutes with my programming partner(s) trying to find an appropriate name to assign to something. Sometimes it takes a lot of discussion and experimentation with the design to figure out what the appropriate name is but really what we're doing with all that time is discovering the real intent of the software and how these things fit into achieving that goal.

We do that too (me and the wife; she knows how to program). Yes, it often does produce more than just a really good name for a class or a method, by the discussion enlarging at times to be about what's really going on. And a truly good name can easily be worth the time it takes to find it.

Again, this is not to say that I don't write comments either. I tend to write JavaDocs more often than not for public methods and I'll always leave a DEVELOPER NOTE or IMPLEMENTATION NOTE comment where I think an explanation of WHY something was done in a certain way is warranted and helpful. I let the code explain the WHAT and HOW it gets things done.

I guess we're largely on the same page. If your code makes itself clear (a more demanding standard than many of our colleagues seem to think it is), then explanatory notes regarding use and purpose may be all that's needed. There are times when I still think something is opaque enough, even when I believe I've done the best job of keeping it clear that I can, that I put in some how-and-what comments too. My great concern arises from the (silly, I think) idea that one should never use comments at all. In those "bad experiences" I've had, the no-comment guys turned it all into a kind of manhood battle, saying that if I couldn't understand their comment-free spaghetti, that really just meant that I was the inferior being, not them. This often rose to the level of management getting involved, to set policy about comments. Now, in those particular days, my managers did not know how to write code, so their policy-making tended to be driven by a simple rubric: we do whatever gets it done fastest. My opponents chanted that adding comments took time. I said that adding comments saved time. Alas, the time it took was "now," while the time it saved was "later." Management found it easy to set policy after that. (And, amazingly, no one offered me a promotion when the particular project I am thinking of was canceled later, after being unfinished past deadline, over budget, and ultimately outsourced to some professionals who didn't mind working hard.)

So, yeah, I'm all for code that helps you understand itself. I merely fear for the noobs who, upon hearing the words, "self-documenting code" think that means comments are never needed.

[Stevens Miller]

Winston Gutkowski wrote:I'm struggling to come up with a good example at the moment, but if I think of one, I'll let you know.

Please do. I don't ask these questions so I can ignore the answers.

[Junilu Lacar]

One phrase I find myself saying a lot is "Make your code tell a story." I picked this up from Kent Beck, I think. I find that if you read code out loud or ask another person to read it out loud, it's a lot easier to tell if it's actually telling a clear and coherent story. Yesterday, after a particularly frustrating 30 minutes of trying to get to the bottom of some non-trivial requirements, I just said, "Ok, let's outline this story..." and proceeded to guide folks though this format:

Goal: See what parts of our service the customer is entitle to use

Path to goal: (what's the ideal code that you want to write to get this done)
   
      EntitlementService entitlementService = ...;
      Entitlements entitlements = entitlementService.lookup(userId);

Goal: ...

Path to goal: ...
      blah 
      blah

This quickly focused the discussion on the high level abstractions and I realized that we had been bogged down for 30 minutes because the developers kept wanting to go down into the detailed implementation. But after getting them to pull out of this mode of thinking and try to see the forest for the trees, we sailed through the rest of the discussion and were able to lay out an API that was acceptable and reasonable to all involved. Most of the names we ended using were things that got mentioned as we discussed the high level requirements. Sometimes all it takes for is someone to pull everyone out of the rut.

[Tim Holloway]

This is a lot like Donald Knuth's Literate Programming concept, which, amusingly, I was doing before he published the concept.

1. Write the "Why" out in (your National Language) as comments.

2. Write the code in between the comments to implement the function.

Comments are forest, code lines are trees. Win/Win. A good Javadoc header at the top synopsising usage and domain/range of the problem that the method addressed ices the cake.

I used to have a tool similar to Knuth's Web that would pull the comments and make technical documentation/helpfiles out of them, but OOP languages don't need that as much as the older procedural languages do. Haven't done flow charts to speak of in years for the same reason.

[Stevens Miller]

Junilu Lucar wrote:the developers kept wanting to go down into the detailed implementation.

As Winston sagely advises many of the Greenhorns, often the best move is to StopCoding until you know what your code has to do. It certainly is the case that if you think and reason long enough, a simple solution that wasn't originally apparent might emerge. (But, see below.)

Tim Holloway wrote:This is a lot like Donald Knuth's Literate Programming concept, which, amusingly, I was doing before he published the concept.

Heh, so true. I find that a number of practices I either evolved to on my own or picked up by working with skilled colleagues turn out to have names I didn't know until long after I knew the practices themselves. I wasn't familiar with this one, but did a bit of Googling when I read Tim's comment. First impression is that it is a good approach, but appears also to be an amalgamation of a number of other practices that I've seen over the years: "Structured Programming," "Top-Down Design," "Pseudo-Coding," and others. All of those have their place(s), sometimes varying according to the skills and experiences of the programmer(s) involved, I think.

Not to beat this horse unduly to death, but sometimes this sort of thing reminds me of the "critical thinking" craze that, for a while (currently?), took hold in public education. It sounds great, but turns out to be an umbrella term for a lot of best-practices pedagogical mechanisms that, collectively, may or may not really be more than the sum of their parts. That is, the entire collection of methods gathered under the term "critical thinking" doesn't work any better than it did before, just because the collection has a name. Likewise, when I see code with reasonable names given to classes, variables, and methods (or to structures, variables, and functions) I don't tend think, "Ah, a student of the X school of software creation." I tend to think, "Hey, that's some pretty good stuff." Giving names to our various sets of professional methodologies seems, to me, to risk becoming needlessly religious about how we write code. I may never regard myself as an adherent to the Church of Literate Programming, but that doesn't mean I can't (or must, for that matter) apply its teachings. That's why I like Tim's observation: he was using an effective technique without even knowing it had a name. Just doing good work is hard to fight about. But, give a thing a name, and then you can fight about the thing:

P1: Why don't you use comments?
P2: Because I write self-documenting code.
P1: That doesn't mean you should never use comments.
P2: Self-documenting code is better than comments.
P1: Comments are good too.
P2: Self-documenting code!
P1: Comments!
P2: Never!

And so on.

Further, Tim Holloway wrote:Haven't done flow charts to speak of in years for the same reason.

<BELOW/>
Me either, come to think of it, except in some rare cases where a problem has truly been (well, to me, at least) complicated. Our libraries have grown so big and so mature that a lot of use cases (once we have done the work of specifying them) don't need much in the way of original software design. Junilu's example seems like a good one. The real work was done before anyone put their hand on a mouse to write any code. If you can break your use cases down to sufficiently well defined steps, the code almost just falls out of your natural language descriptions (what I think Tim and Knuth are doing, perhaps).

Except (and, again, this could be more about me than about the world I live in), there still are problems that are not typically going to be subject to translation into simple language. Back before our libraries became mature, this was almost everything. Someone said, "I need a program to organize data into named containers," and we programmers had to roll up our sleeves and build a file system. Just figuring out how to do something was, in those days (I'm thinking of the '60 and '70s here) frequently a ground-breaking experience. Today, a lot of the "how" is done for us. It's much more the "what," with APIs available to do almost anything. (I think this is why we have heard the lamentable evolution in the business world away from the phrase "computer programs" towards the much less intimidating word, "scripts." Programs are complicated, scary things that require expensive experts to create, while any old fool can cobble up a script.) But not always. Some problems are still out there that call for complex algorithmic solutions, and not all of those are, I believe, best approached under the assumption that a natural-language analysis will solve them. When I am confronting one of those (happens from time to time, in image processing), I still find a good old flowchart can be helpful.

Then again, that may be nothing more than a side-effect of being a good old programmer.

[Winston Gutkowski]

Stevens Miller wrote:Giving names to our various sets of professional methodologies seems, to me, to risk becoming needlessly religious about how we write code.

I definitely agree with you; and I fear that a prime example is Java version 8.

Several things about it make me suspect that we are being "channelled" towards programming functionally, regardless of how familiar it is, or whether it's even applicable. Don't get me wrong, I love all this new stuff - especially Streams, which remind me of Unix scripting - but I don't think that functional programming is:
(a) For everybody.
(b) Necessarily the best solution.
(c) (and this is what we seem to be talking about) Readable - or indeed, documentable (at least not with tools like Javadoc).
It also has many other flaws such as rigidity and coupling, which are very familiar to scripting experts, but not well publicized by the bods who want us all to become "functional".

To me, Java's greatest asset is its flexibility. It allows us to program procedurally when we need to; use objects when they make sense; forget about memory management; and has a syntax that is familiar to many. To me, "functionality" is just another string to the bow; but I certainly don't want to be forced to use it exclusively.

Just as a simple example, I say to the version 8 designers: BaseStream should implement Iterable. It already IS an Iterable in everything but name, so the only possible reason for not actually implementing the interface is that, for some reason, they don't want us to use it that way.

Give us the tools. Let US decide how we use them.

Winston

[Stevens Miller]

Winston Gutkowski wrote:Several things about [Java 8] make me suspect that we are being "channelled" towards programming functionally, regardless of how familiar it is, or whether it's even applicable.

I've felt a bit of that myself. FP is interesting, and I'm happy to know more about it, but I don't like having my strategic choices made for me.

To me, Java's greatest asset is its flexibility. It allows us to program procedurally when we need to; use objects when they make sense; forget about memory management; and has a syntax that is familiar to many.

That's a nice summation of Java's virtues and they do, collectively, make flexibility one of its virtues as well. Interestingly, when you look at the TIOBE Community Index, you see that Java rides high, but so does C. Not C++, but good old K&R C. When C++ emerged in the latter 20th century, most of my colleagues predicted that it would supersede C, since you could pretty much write C programs in C++ (by just ignoring all those confusing "::" operators and anything they were a part of), but you could also do (genuflect when you say this) Object Oriented Programming(!). Obviously, C's days were numbered.

Except that's not what happened. C++ has not taken C's market away, partly because it does turn out to be somewhat more difficult to use it to write C programs than we might have thought, partly because C compilers are easy to cobble up for a lot of platforms, and partly because C is still a good choice for certain things (like speedy image processing and device control, albeit at the expense of empowering those arrogant SOBs who wave their use of unsigned bytes around like some kind of national banner). In the end, C did not evolve into something better than C, and I doubt that Java can be mutated against its will any more successfully. If FP is the right choice for more projects in the future, a good FP language is the right tool. Retrofitting existing languages to use it seems risky, and precedent suggests it won't work.

BTW, there is a delightful song about this topic. Take five minutes and listen, if you haven't heard it before.

[Tim Holloway]

Functional Programming is nothing new. It dates back to the early 1960s, if not before. Lambda expressions are an integral part of LISP, which comes from that era.

What's new is that it has become a fad, a Silver Bullet, and that's a topic under discussion here: https://coderanch.com/t/661968/Agile/opinion-year-scrum-experience#3074689

[Winston Gutkowski]

Tim Holloway wrote:Functional Programming is nothing new. It dates back to the early 1960s, if not before. Lambda expressions are an integral part of LISP, which comes from that era.

And it's one of my great regrets that I never learned it (along with Fortran). And like I say, I have no problem with Java adding FP stuff; just let me use it as I see fit.

Winston

[Stevens Miller]

Winston Gutkowski wrote:And it's one of my great regrets that I never learned it (along with Fortran).

Trust me, you lack for nothing that you never learned FORTRAN (yes, I go back so far that it is "FORTRAN" for me, not "Fortran"). Perfectly good language, but it was quickly superseded by others that were easier to learn, offered a wider spectrum of abstractions, allowed for self-documenting code long camelCase identifiers, and recursion. (On that last one, VAX-11 FORTRAN refused to compile a subroutine that called itself, but it wasn't smart enough to refuse to compile a subroutine that called a subroutine that called the first subroutine, and the VAX itself was so stack-oriented that the compiler writers went ahead and made recursion work, but also abided by the part of the language spec that disallowed it. So, if A called A, you got a compile-time error, but if A called B and B called A, you got what you wanted. Yep, boys, them were the days of the wild, wild west.)

[Tim Holloway]

FORTRAN (IV) was my original language as well and I liked its simplicity. However, lack of character data types and string operations meant that a lot of general-purpose apps were no fun to code and very platform-specific.

Fun fact: Prime Computer Corporation, a fairly well-known minicomputer company of the 1970s was founded by a bunch of dissident ex-Honeywell employees. They took an OS design written for NASA and designed TTL-logic boards specifically optimized to act as a CPU for the FORTRAN language, including machine-language instructions that directly implemented FORTRAN's 3-way branches. This was back when software code paid for by taxpayers actually belonged to the taxpayers - in other words, was public domain, unlike today's privatize-everything mindset. Only a very small core of the Primos operating systems was written in assembly language and this was back in the day when OS's were routinely almost all assembly language. I still have printouts of most of the source code. In addition to the core OS, most system utilities, advanced filesystem/not-quite-databases and other stuff was in Fortran as well.

However, this was a minicomputer, so external resource names were limited to 6 characters max, packed 2 characters per 16-bit word.

Fortran is still supplied as one of the stock languages readily available in virtually all Linux distros.

LISP goes even deeper. Lisp and Scheme are part of some core Linux tools. It's the "macro language" for the infamous Emacs text editor, and until the rise of Python, was used as a configuration language for quite a few other products as well.

Of course, the absolute darling of Functional Programming is the Haskell language, which actually isn't that new itself.

[Stevens Miller]

Tim Holloway wrote:...the infamous Emacs text editor...

For that second word alone, you get a cow.

[Winston Gutkowski]

Stevens Miller wrote:When C++ emerged in the latter 20th century, most of my colleagues predicted that it would supersede C...

And for a while it did. If you look at the historical graph on TIOBE, C usage has remained pretty much constant since 2002, probably because for some things it's still the best tool available. C++ OTOH, has dropped from about 16% (and I'd care to bet that when I was introduced to it back around '91, it was higher than that) down to 6, because IT has been superceded by better, safer, more modern languages that cover the same ground.

C is still a good choice for certain things ... albeit at the expense of empowering those arrogant SOBs who wave their use of unsigned bytes around like some kind of national banner.

Hmmm, do I detect a change in opinion? I seem to remember a thread a few weeks back...

BTW, there is a delightful song about this topic. Take five minutes and listen, if you haven't heard it before.

Nice. Do you know who sang it? She has a really nice voice.

Winston

[Stevens Miller]

Winston Gutkowski wrote:

Stevens Miller wrote:C is still a good choice for certain things ... albeit at the expense of empowering those arrogant SOBs who wave their use of unsigned bytes around like some kind of national banner.

Hmmm, do I detect a change in opinion? I seem to remember a thread a few weeks back...

No, what you are failing to detect is my oh-so-endearing humility through the use of self-deprecating humor. Charming, isn't it?

BTW, there is a delightful song about this topic. Take five minutes and listen, if you haven't heard it before.

Nice. Do you know who sang it? She has a really nice voice.

Julia Ecklar. Yes, she's got the pipes.