I think that a crucial point that either of you has failed to notice or point out is that the autogenerated comment in question is a Javadoc comment. If we take only the perspective of somebody reading the source code of the class, then lahi is right that the comment is absolutely worthless. If we take the perspective of somebody reading the Javadocs, on the other hand, having the comment does convey some information.
You are right, I viewed the comment as a code comment, not as API documentation, which javadoc is supposed to be. As I stated in my other comment, it is my understanding that accessors are conceptually corresponding to public attributes, and should be documented as such. If there is a public side-effect, it should not be done as an accessor. The API docs of a public attribute should document the meaning of the attribute, without regard for whether it is a synthetic attribute (for instance through proxying) or a real attribute. After all the status as a real or synthetic attribute could change in a subclass.
The only contrived trivial example I can think of at the moment is geometric points, where you could choose to have an interface with both polar and cartesian attributes. The cartesian implementation would have the polar coordinates as synthetic attributes and vice versa. Of course in practice you wouldn't make such a type mutable.
In any case, the comment is as useless as documentation as it is as a code comment.
Still, I think that the stated reason you provide for having such comments ("to explain that this really is only a simple variable accessor") is no good. If I'm reading the Javadocs, why should I care at all whether the code for the getter is just a trivial return statement, or something more complicated? What I care about is the conceptual model that the class provides, not its implementation. The class models some kind of object within a problem domain; those objects have such-and-such properties, and these are the operations that one can perform on them.
Those well-intended IDE-autogenerated javadoc comments pave the road from here to Hell. I look at them almost every day, and they are useless, to the point that I don't bother with javadoc. You could argue that it is the fault of the programmers whose code I am reading, but I really think javadoc has to share the blame. Documentation is difficult, and good documentation is a lot harder than good code, and trying to fix this by adding a special type of comment to your code solves very little. Autogenerating such comments OTOH is plain offensive, because real documentation cannot be generated. If the IDE could tell you why you wrote the code, it could just as easily write the code itself. By putting parrot-talk in those comments by default, you give the lazy programmer (= any intelligent programmer) a good enough bad excuse not to fill in something meaningful.
Having an IDE that could tie the documentation, and indeed the whole process from requirements, use cases and unit tests, together with the coding process would be a marvellous thing. Writing some documentation in a word processor, some in a UML tool, possibly interacting through some simple generation with the IDE and the code is not optimal, though.
I am suffering from lots of code which may or may not be out of sync with documentation, so I'd love to see a solution.
Meanwhile, I am very cautious about anything in a source file except actual live code. Even so, I sometimes look at what appears to be live code only to find out that it is dead, superseded by something else, but not thoroughly documented. Comments may be used as hints, but they can't be trusted. Period.
Executable comments, in the form of invariants, pre- and postconditions, like in Eiffel, are different. They are part of the code, and necessarily up to date.
Sorry, but that _was_ what you wrote, wasn't it?;-)
Actually, we probably agree to a large extent. Whether you use a preprocessor that generates Java or an IDE doesn't matter much. Effectively, you are programming in a language that is not quite Java, but hides some of its less fortunate properties. I just personally would prefer the language to be different, rather than having its rough edges smoothed over by an IDE. But viewed through the spectacles of semiotics, an IDE is not that different from any other language.
I am certainly not complaining about Java portability. My homebanking works fine, and in the past I have had BEA WebLogic 6 running on NetBSD. But perhaps I will start with giving NetBeans a try.
Oh. It occurs to me that you may have missed that we are talking about automatically generated accessor functions: For example... you add your object attributes and then rightmouse -> refactor -> 'generate accessor methods'. And blink... you have properly formatted, commented, and scoped getters and setters.
I agree that a nontrivial accessor might benefit from a comment, just as a nontrivial statement, but it doesn't follow that therefore all accessors or all statements (including my increment example) deserve comments.
Please explain to me how an automatically generated (thus presumably trivial) accessor function can have automatically generated comments that are not absolutely trivial. I agree that an accessor function could be bestowed with additional functionality, but then: - It might cross the border where it ceases to be just an accessor function, and should be named according to its behaviour, rather than getFoo/setFoo. - You provide the behaviour and the comment yourself.
Perhaps in Java 6 we'll see something like:
class Foobar { public Foo foo;... }
being taken as shorthand for:
class Foobar { private Foo foo; public Foo getFoo() { return foo; }; public void setFoo(Foo newfoo) { foo = newfoo; }... }
and of course permitting you to make foo private in a subclass if you provide public accessor functions. (Presumably with additional behaviour.)
Also, naturally, accessing foobar.foo would be understood as foobar.getFoo(), and foobar.foo = bar as foobar.setFoo(bar).
If I remember correctly, Dylan does accessor functions more or less like this. Probably other languages do too. Ruby is arguably one of them. +1 for Ruby.
BTW, I have read too much buggy, badly commented code, to trust any comment. Semantically significant annotations - such as Eiffel invariants, pre- and postconditions - would be a different matter.
Verbosity is a bad thing. The code that is not written does not need to be maintained, debugged, or even considered at all. I am not talking of saving keystrokes, but about noise, I am talking about code where the important points get lost in all the boilerplate, and I've seen my share of that. The classic trivial contrived example is:
class Hello { public static void Main(String[] arg) { System.out.println("Hello World"); }
versus: print "Hello World\n"
Of course it's a trivial, useless example - except it only gets worse from here. It doesn't matter if the IDE generates everything for me and can manipulate the AST correctly and transparently when refactoring - I don't want to see that mess.
Interestingly enough, many people seem to prefer C syntax if(){}else{} for blocks, because it saves a few keystrokes, although many studies have shown that Ada-like "if then else endif" syntax (or the variant used in Ruby) is less error-prone, and IMO more readable. (And don't give me any crap about how noone makes mistakes with that anyway, so it doesn't matter, and the IDE prettyprints your statements and does everything for you etc. I have seen mistakes happen from this too.)
As for using IDEs: I'd like to, but for some reason despite being written in Java and therefore allegedly portable, at least Eclipse seems to come with a platform-native startup-program that I haven't had much success with on NetBSD so far, despite having compiled working native NetBSD versions of Sun JDK 1.4 and 1.5 myself. I will get around to it eventually.
Oh, and could you please show me an example of one of those "properly formatted, commented, and scoped getters [or] setters." I somehow strongly doubt that an IDE can automatically generate any meaningful comment for a getter or setter. The best I can come up with is this piece of garbage (carefully adapted from this):
/**
* Returns the foo of the object.
* @return the foo
*/
public Foo getFoo() {
return foo;
}
Please be an honest, intelligent person and admit that that's just silly!
Good example; and in this case I would use code generation. I almost never write getters or setters in Java - my IDE does it (and then manages them) for me. If I look at the class properties in NetBeans, I only see the variables ('bean properties') - the code is all hidden and managed for me.
I suppose that is becoming common. However, I would argue that you are then not actually programming in Java. You are programming in a variant language, which happens to be close to Java, and which generates Java. I'm not saying that is a bad thing, on the contrary. It also has a strong precedent, for instance using yacc generated parsers with C. I can think of two negative things to say about it, though:
1. The language you use is probably not portable beyond the IDE, by definition. If I were to edit your code in vi or emacs, I would not be able to use your language. At the end of the day, it's just a hack to circumvent Java's (and Java beans') design flaws.
2. The language you use can be viewed as a kind of domain-specific language. However it does not go all the way, and you are confined to whatever the IDE-makers decide to give you, unless you modify the IDE yourself. Of course that is the original SmallTalk toolbox idea, illustrated in the Taj Mahal cartoon in the August 1981 issue of Byte Magazine, and with open-source IDEs like NetBeans and Eclipse it becomes a possibility. (Of course some lisp weenies will tell us that they have been doing exactly that since forever, or at least since lisp was invented. But I don't lisp, although I am known to st-st-stutter sometimes.)
Ah. The joys of previewing and still missing silly mistakes. And although English isn't my native language, I don't think that counts for much of an excuse.
"where often teased with": read "were often teased about". Or something like that anyway.
What it means is if that you restrict the memory allowed to Java to 64MB, Netbeans will run fine.
Thank you for reminding me of one thing I just don't understand about Java.
Back in the nineties, I converted from CP/M to become a Mac-fanboi. There, I admit it. (I have since recovered. Now I'm a NetBSD-weenie.) At that time, we Mac-folk where often teased with a particular working mode which seemed ridiculous to Windows and Unix people alike. (And in retrospect, they were right. Of course, at the time I would never have admitted that.)
Every Mac-application had two "static" configuration parameters: The minimum memory size it could work with, and the maximum it was allowed to use. If for some reason the max was too low, say, if you suddenly wanted to create a large image in PhotoShop, then you would be told, "sorry not enough memory", and then you could quit, fix the Max-size, and start again. If you had a suite of programs running at all times, you might also have to adjust the sizes of those to fit in your available memory.
Today, Java VMs come with the same usage pattern. Recently we had to set -Xmx=1536M for our J2EE web portal at work. Naturally that causes downtime. Before that it would thrash under heavy load, and die with heapdumps due to the garbage collector giving up. (Now, I know that this is typically an indication of a problem in the application, but that is not the point here: the machine had enough memory, but the JVM just wouldn't use it beyond the 1024M it was previously allotted, and it works fine today with 1.5G.)
I wonder why we have to live with that in this century. It was already a bad idea in the last.
Oh, to be on-topic: I suppose Ruby, like Perl, will happily consume all the memory you have, no questions asked. +1 for Ruby on this assumption.
And if HTTP could use MIME multipart-mixed to deliver the page, the HTML together with all the media components could easily be delivered in one response. (I almost said APDU.)
Sorry, but there is just about everytrhing wrong with the protocol. If I remember correctly, most of what is wrong with it was obvious from the start, all the way back to HTTP/0.8. It is suited only for a subset of what it is today abused for. The useful subset is restricted to static pages and elements, and only barely. Anything that needs sessions has to use the stupid hack which is cookies or the even stupider hack which is URL rewriting, because HTTP was foolishly designed as a stateless protocol, despite using TCP. Basic authentication is a joke which at the time of its invention had long ceased to be funny. (Other protocols had at that time realized the problems with sending passwords unencrypted.) And don't get me started on the insanity of URL-encoding, query-strings, the "difference" between GET and POST methods, redirections etc etc.
// 30-11-2005 Fixes a null reference exception that occurs later on if no reference is available.
That comment does not belong in the code, it belongs in the comment field of the commit of the fix to the code repository. It is a typical comment that may go obsolete without being removed when someone else figures out that the null reference never occurs because the Account class invariant ensures its existence, and therefore deletes the if-statement.
In general, historical stuff should not be in the code but in the CVS (or Subversion or whatever) repository. Same with dead code. It should be deleted, not commented out.
Of course it was a joke. Everything is a joke. It has to be, it is the only rational explanation. Seriously. Anyhow, I fully agree with Nietzsche's words: "Was mich nicht umbringt macht mich stärker"! Skål!
Alcohol can become lethal, And so what. Everything in moderation. Even water is poisonous, as was clear from recent news reporting in Denmark. A young otherwise healthy woman drank excessive amounts of unsalted water as part of a selfadministered "cleansing", which skewed her salt balance and caused brain damage and subsequent death.
So please take everything with a grain of salt! (And a slice of lemon if it's tequila.)
That *is* a joke page, right? It must be. Please. It *has* to be. Don't people know what's inside their walls? I am a peaceful person, but I would kill and rob any person who has enough money to buy such a cable, without hesitation. I wouldn't even be doing any harm, as such a person already is braindead by any meaningful definition.
I think that "try and stay organized" is a rather unhelpful answer. It's precisely that which the original question was about.
My guess is that donniejones belongs to a group of creative problem solvers who simply are less capable of staying organized in a systematic way - perhaps that "disability" is precisely what makes them (us) good problem solvers.
In the good old days I suspect such people would have had a personal secretary assigned to deal with all the paperwork, deadlines, schedules, mail, etc so they could focus on the problems within their expertise.
But today, everybody has to be a touch-typing super-organized secretary and planner *in addition* to what they are supposed to do.
I see no solution to this at the moment, in fact it would seem that this very problem gets far too little attention.
In this situation, even a partial solution in software would be better than nothing. However given that you often can't even choose which e-mail and calendar software you want to use, the problem remains strong.
If you are lucky to chose the software yourself, the next problem is, that you will most likely need a custom application that suits precisely *your* way of working. And I am certain none of the existing software allows sufficient customization to achieve this. If at least there were some small building blocks you could use, instead of the current bunch of huge, difficult-to-learn, impossible-to-master monolithic software.
Anybody want to start an OSS project for making those building blocks?
Slashdot Mirror
I think that a crucial point that either of you has failed to notice or point out is that the autogenerated comment in question is a Javadoc comment. If we take only the perspective of somebody reading the source code of the class, then lahi is right that the comment is absolutely worthless. If we take the perspective of somebody reading the Javadocs, on the other hand, having the comment does convey some information.
You are right, I viewed the comment as a code comment, not as API documentation, which javadoc is supposed to be. As I stated in my other comment, it is my understanding that accessors are conceptually corresponding to public attributes, and should be documented as such. If there is a public side-effect, it should not be done as an accessor. The API docs of a public attribute should document the meaning of the attribute, without regard for whether it is a synthetic attribute (for instance through proxying) or a real attribute. After all the status as a real or synthetic attribute could change in a subclass.
The only contrived trivial example I can think of at the moment is geometric points, where you could choose to have an interface with both polar and cartesian attributes. The cartesian implementation would have the polar coordinates as synthetic attributes and vice versa. Of course in practice you wouldn't make such a type mutable.
In any case, the comment is as useless as documentation as it is as a code comment.
Still, I think that the stated reason you provide for having such comments ("to explain that this really is only a simple variable accessor") is no good. If I'm reading the Javadocs, why should I care at all whether the code for the getter is just a trivial return statement, or something more complicated? What I care about is the conceptual model that the class provides, not its implementation. The class models some kind of object within a problem domain; those objects have such-and-such properties, and these are the operations that one can perform on them.
Those well-intended IDE-autogenerated javadoc comments pave the road from here to Hell. I look at them almost every day, and they are useless, to the point that I don't bother with javadoc. You could argue that it is the fault of the programmers whose code I am reading, but I really think javadoc has to share the blame. Documentation is difficult, and good documentation is a lot harder than good code, and trying to fix this by adding a special type of comment to your code solves very little. Autogenerating such comments OTOH is plain offensive, because real documentation cannot be generated. If the IDE could tell you why you wrote the code, it could just as easily write the code itself. By putting parrot-talk in those comments by default, you give the lazy programmer (= any intelligent programmer) a good enough bad excuse not to fill in something meaningful.
Having an IDE that could tie the documentation, and indeed the whole process from requirements, use cases and unit tests, together with the coding process would be a marvellous thing. Writing some documentation in a word processor, some in a UML tool, possibly interacting through some simple generation with the IDE and the code is not optimal, though.
I am suffering from lots of code which may or may not be out of sync with documentation, so I'd love to see a solution.
Meanwhile, I am very cautious about anything in a source file except actual live code. Even so, I sometimes look at what appears to be live code only to find out that it is dead, superseded by something else, but not thoroughly documented. Comments may be used as hints, but they can't be trusted. Period.
Executable comments, in the form of invariants, pre- and postconditions, like in Eiffel, are different. They are part of the code, and necessarily up to date.
-Lasse
Sorry, but that _was_ what you wrote, wasn't it? ;-)
Actually, we probably agree to a large extent. Whether you use a preprocessor that generates Java or an IDE doesn't matter much. Effectively, you are programming in a language that is not quite Java, but hides some of its less fortunate properties. I just personally would prefer the language to be different, rather than having its rough edges smoothed over by an IDE. But viewed through the spectacles of semiotics, an IDE is not that different from any other language.
I am certainly not complaining about Java portability. My homebanking works fine, and in the past I have had BEA WebLogic 6 running on NetBSD. But perhaps I will start with giving NetBeans a try.
-Lasse
Oh. It occurs to me that you may have missed that we are talking about automatically generated accessor functions:
... }
... }
For example... you add your object attributes and then rightmouse -> refactor -> 'generate accessor methods'. And blink... you have properly formatted, commented, and scoped getters and setters.
I agree that a nontrivial accessor might benefit from a comment, just as a nontrivial statement, but it doesn't follow that therefore all accessors or all statements (including my increment example) deserve comments.
Please explain to me how an automatically generated (thus presumably trivial) accessor function can have automatically generated comments that are not absolutely trivial. I agree that an accessor function could be bestowed with additional functionality, but then:
- It might cross the border where it ceases to be just an accessor function, and should be named according to its behaviour, rather than getFoo/setFoo.
- You provide the behaviour and the comment yourself.
Perhaps in Java 6 we'll see something like:
class Foobar { public Foo foo;
being taken as shorthand for:
class Foobar { private Foo foo; public Foo getFoo() { return foo; }; public void setFoo(Foo newfoo) { foo = newfoo; }
and of course permitting you to make foo private in a subclass if you provide public accessor functions. (Presumably with additional behaviour.)
Also, naturally, accessing foobar.foo would be understood as foobar.getFoo(), and foobar.foo = bar as foobar.setFoo(bar).
If I remember correctly, Dylan does accessor functions more or less like this. Probably other languages do too. Ruby is arguably one of them. +1 for Ruby.
BTW, I have read too much buggy, badly commented code, to trust any comment. Semantically significant annotations - such as Eiffel invariants, pre- and postconditions - would be a different matter.
-Lasse
I must conclude that you don't think
/* increment i */ is silly either.
i++;
Let's just leave it there, then.
-Lasse
class Hello { public static void Main(String[] arg) { System.out.println("Hello World"); }
versus:
print "Hello World\n"
Of course it's a trivial, useless example - except it only gets worse from here. It doesn't matter if the IDE generates everything for me and can manipulate the AST correctly and transparently when refactoring - I don't want to see that mess.
Interestingly enough, many people seem to prefer C syntax if(){}else{} for blocks, because it saves a few keystrokes, although many studies have shown that Ada-like "if then else endif" syntax (or the variant used in Ruby) is less error-prone, and IMO more readable. (And don't give me any crap about how noone makes mistakes with that anyway, so it doesn't matter, and the IDE prettyprints your statements and does everything for you etc. I have seen mistakes happen from this too.)
As for using IDEs: I'd like to, but for some reason despite being written in Java and therefore allegedly portable, at least Eclipse seems to come with a platform-native startup-program that I haven't had much success with on NetBSD so far, despite having compiled working native NetBSD versions of Sun JDK 1.4 and 1.5 myself. I will get around to it eventually.
Oh, and could you please show me an example of one of those "properly formatted, commented, and scoped getters [or] setters." I somehow strongly doubt that an IDE can automatically generate any meaningful comment for a getter or setter. The best I can come up with is this piece of garbage (carefully adapted from this):Please be an honest, intelligent person and admit that that's just silly!
-Lasse
Good example; and in this case I would use code generation. I almost never write getters or setters in Java - my IDE does it (and then manages them) for me. If I look at the class properties in NetBeans, I only see the variables ('bean properties') - the code is all hidden and managed for me.
I suppose that is becoming common. However, I would argue that you are then not actually programming in Java. You are programming in a variant language, which happens to be close to Java, and which generates Java. I'm not saying that is a bad thing, on the contrary. It also has a strong precedent, for instance using yacc generated parsers with C. I can think of two negative things to say about it, though:
1. The language you use is probably not portable beyond the IDE, by definition. If I were to edit your code in vi or emacs, I would not be able to use your language. At the end of the day, it's just a hack to circumvent Java's (and Java beans') design flaws.
2. The language you use can be viewed as a kind of domain-specific language. However it does not go all the way, and you are confined to whatever the IDE-makers decide to give you, unless you modify the IDE yourself. Of course that is the original SmallTalk toolbox idea, illustrated in the Taj Mahal cartoon in the August 1981 issue of Byte Magazine, and with open-source IDEs like NetBeans and Eclipse it becomes a possibility. (Of course some lisp weenies will tell us that they have been doing exactly that since forever, or at least since lisp was invented. But I don't lisp, although I am known to st-st-stutter sometimes.)
-Lasse
Ah. The joys of previewing and still missing silly mistakes. And although English isn't my native language, I don't think that counts for much of an excuse.
"where often teased with": read "were often teased about". Or something like that anyway.
-Lasse
What it means is if that you restrict the memory allowed to Java to 64MB, Netbeans will run fine.
Thank you for reminding me of one thing I just don't understand about Java.
Back in the nineties, I converted from CP/M to become a Mac-fanboi. There, I admit it. (I have since recovered. Now I'm a NetBSD-weenie.) At that time, we Mac-folk where often teased with a particular working mode which seemed ridiculous to Windows and Unix people alike. (And in retrospect, they were right. Of course, at the time I would never have admitted that.)
Every Mac-application had two "static" configuration parameters: The minimum memory size it could work with, and the maximum it was allowed to use. If for some reason the max was too low, say, if you suddenly wanted to create a large image in PhotoShop, then you would be told, "sorry not enough memory", and then you could quit, fix the Max-size, and start again. If you had a suite of programs running at all times, you might also have to adjust the sizes of those to fit in your available memory.
Today, Java VMs come with the same usage pattern. Recently we had to set -Xmx=1536M for our J2EE web portal at work. Naturally that causes downtime. Before that it would thrash under heavy load, and die with heapdumps due to the garbage collector giving up. (Now, I know that this is typically an indication of a problem in the application, but that is not the point here: the machine had enough memory, but the JVM just wouldn't use it beyond the 1024M it was previously allotted, and it works fine today with 1.5G.)
I wonder why we have to live with that in this century. It was already a bad idea in the last.
Oh, to be on-topic: I suppose Ruby, like Perl, will happily consume all the memory you have, no questions asked.
+1 for Ruby on this assumption.
-Lasse
come from a connection that is looser than it should be
or a luser more connected than he should be.
-Lasse
that they can forget about it.
-Lasse
And us real hard nuts use NutBSD...aeh, NetBSD...
-Lasse
Pod this up, Jack: Is a jackpod required to podjack?
-Lasse
I'm atheist, you insensitive pod.
-Lasse
And if HTTP could use MIME multipart-mixed to deliver the page, the HTML together with all the media components could easily be delivered in one response. (I almost said APDU.)
-Lasse
Sorry, but there is just about everytrhing wrong with the protocol. If I remember correctly, most of what is wrong with it was obvious from the start, all the way back to HTTP/0.8. It is suited only for a subset of what it is today abused for. The useful subset is restricted to static pages and elements, and only barely. Anything that needs sessions has to use the stupid hack which is cookies or the even stupider hack which is URL rewriting, because HTTP was foolishly designed as a stateless protocol, despite using TCP. Basic authentication is a joke which at the time of its invention had long ceased to be funny. (Other protocols had at that time realized the problems with sending passwords unencrypted.) And don't get me started on the insanity of URL-encoding, query-strings, the "difference" between GET and POST methods, redirections etc etc.
-Lasse
// 30-11-2005 Fixes a null reference exception that occurs later on if no reference is available.
That comment does not belong in the code, it belongs in the comment field of the commit of the fix to the code repository. It is a typical comment that may go obsolete without being removed when someone else figures out that the null reference never occurs because the Account class invariant ensures its existence, and therefore deletes the if-statement.
In general, historical stuff should not be in the code but in the CVS (or Subversion or whatever) repository. Same with dead code. It should be deleted, not commented out.
-Lasse
Of course it was a joke. Everything is a joke. It has to be, it is the only rational explanation. Seriously. Anyhow, I fully agree with Nietzsche's words: "Was mich nicht umbringt macht mich stärker"! Skål!
-Lasse
Alcohol can become lethal,
And so what. Everything in moderation. Even water is poisonous, as was clear from recent news reporting in Denmark. A young otherwise healthy woman drank excessive amounts of unsalted water as part of a selfadministered "cleansing", which skewed her salt balance and caused brain damage and subsequent death.
So please take everything with a grain of salt! (And a slice of lemon if it's tequila.)
-Lasse
I sure as hell hope it's not triclosan. The use of triclosan should be banned, or we end up with many more resistant bacteria strains.
-Lasse
Hotblack Desiato? Hm, I would guess his subwoofer was powered by a medium-sized nuclear powerplant. More powerful indeed.
-Lasse
That *is* a joke page, right? It must be. Please. It *has* to be. Don't people know what's inside their walls? I am a peaceful person, but I would kill and rob any person who has enough money to buy such a cable, without hesitation. I wouldn't even be doing any harm, as such a person already is braindead by any meaningful definition.
-Lasse
And of course, conversely, God's greatest trick was convincing the world that he did exist.
-Lasse
Sorry if I'm just showing my age (my knowledge of audio systems is a couple decades behind the times.)
Can someone please enlighten me on what "digital amplification" is?
Bigger ones and zeros????
-Lasse
I think that "try and stay organized" is a rather unhelpful answer. It's precisely that which the original question was about.
My guess is that donniejones belongs to a group of creative problem solvers who simply are less capable of staying organized in a systematic way - perhaps that "disability" is precisely what makes them (us) good problem solvers.
In the good old days I suspect such people would have had a personal secretary assigned to deal with all the paperwork, deadlines, schedules, mail, etc so they could focus on the problems within their expertise.
But today, everybody has to be a touch-typing super-organized secretary and planner *in addition* to what they are supposed to do.
I see no solution to this at the moment, in fact it would seem that this very problem gets far too little attention.
In this situation, even a partial solution in software would be better than nothing. However given that you often can't even choose which e-mail and calendar software you want to use, the problem remains strong.
If you are lucky to chose the software yourself, the next problem is, that you will most likely need a custom application that suits precisely *your* way of working. And I am certain none of the existing software allows sufficient customization to achieve this. If at least there were some small building blocks you could use, instead of the current bunch of huge, difficult-to-learn, impossible-to-master monolithic software.
Anybody want to start an OSS project for making those building blocks?
-Lasse
So in other (fewer) words, NetBSD is toast?
-Lasse