I suppose you were trying to write "lack of knowledge or will to learn".
It is common knowledge that Ctrl-N should be a shortcut to create a new item. Presumably an item one often wants to create a new one of. For example a message. In Notes, I get a new database. What am I suppose to do with that? I am not designing any databases! I press the spacebar to page down in a mail - only to get told some action or other is "not allowed". What? So Notes goes against my knowledge - you can call that a lack. As for my willingness to learn: right, I am not willing to learn an awkward and archaic interface, to any extent beyond what is absolutely necessary to get my job done. It doesn't seem cost-effective to me.
And looking at "properties", I get a neat window with more than half a dozen tabs, containing information I don't want to care about and would prefer not to be bothered with. I think it was the third one that gave me some info about the size of the mailbox. By the way: the silly person who thought a propeller-hat icon was cute for "expert" options - I really hope he or she doesn't work with development of Notes anymore.
A while ago, a message circulated at the office, containing a "script" or "extension" for Notes, which showed a column indicating mails where you are just CC:ed. Naively tempted by the apparant usefulness of this thingy, I installed it. It hosed my mailbox, and took a couple of smarter guys about an hour to disentangle, and I wasn't the only one for which this happened. Apparantly you shouldn't trust such hacks - but if the customizability of Notes is so extensive that "amateurs" with good intentions can fuck up the mail app for numerous colleagues, it is so dangerous that perhaps it wasn't a good idea in the first place.
As for my admin: I didn't mention it before, but I work at IBM. I suppose if anyone "could of", the IBM Notes guys "would of".
I don't know if Jeff Raskin said it quite like this, but I suppose he would have agreed. If you design an application to be totally customizable, chances are that you did so because you are too lazy or just not smart enough to simply make it do the right thing in the first place. It's like responding to a customer's demand for a program by giving him a C compiler and hello.c and say: "There you are: this thing can do anything you need. You just use the C compiler to customize it first."
I don't know about you, but I am paid to do other things than explore, program, reprogram, tune and configure my e-mail application. All the time I waste trying to second-guess Notes is completely unproductive from my point of view. Especially when I know that if the UI had actually been designed to be intuitive to learn and use, I could be far more productive. Yes, I dare blame Notes for that. It is the same reason I prefer using (a small subset of) vi rather than emacs, and NetBSD rather than Linux. I like tools that do one thing well. (And wouldn't you know, I am a former Mac user.)
I would rather read my mail using "less" on individual files in a QMail Maildir! Heck, extracting them from the raw disk device with dd would be an improvement over Notes! And I wouldn't be bothered much by sending mail by typing straight SMTP commands into telnet $mailhost 25. At least it would be far more consistent than Notes.
You must be using a different R7 than I am. Oh, sure, it probably has all those features. I just don't seem to be able to find the time to learn to use them. Notes is so counter-intuitive in all aspects of its user interface, it is an abomination. Why do I have to concern myself with the way "database replication" is set up? Why should I have to deal with these mysterious "databases" anyway? How about using some terms I can relate to? What are all those arcane icons and figures I see when I choose "properties" by accident? Why are some buttons mysteriously disabled when I want to click them? The list of awkward interface issues is endless.
Noone can complain about the features of Notes. And noone is, I guess. Every sane person would complain about the interface, though. Notes looks as if it was designed by FORTRAN and COBOL programmers thinking (dreaming, living) in punch cards.
I feel like I have been taken on a cruise ship, but instead of sitting comfortably on the deck or in a lounge, I have been locked up in the darkened engine room, with unbearable noise and pungent diesel smells.
In my previous job, we used Outlook, and I hated it. But Notes makes me want to go back!
I have been using NetBSD on the desktop - or rather: laptop - for a long time. Started with a ThinkPad T22 in 2001, now I have a Thinkpad R50e. It just works.
There really is no mess. SI just needs to accept the de facto norm that the base and exponent of the multiplier of a prefix depends on the unit it prefixes.
So, for all traditional physical units: k : base = 10 , exponent = 3, M: base = 10, exponent = 6, etc
For bits and bytes etc: k: base = 2, exponent = 10, M: base = 2, exponent = 20, etc
Simple. No bibology or kibology or any other sillyness needed.
Although I am not a card-carrying donaldist (though definitely donaldist), I find it appropriate to counter your Dorfman book with some sense. It's been some time since I read that book, but I believe that some of its arguments are quite far-fetched, to say the least. Further I believe some of it was related to locally (South America) produced material using Disney figures (just as we in Europe have a large production of Donald Duck comics, that is probably completely unknown in the United States.)
The ministry of culture in Denmark recently published a cultural "canon", cultural works that have a strong and integral relation to Danish culture. The canon consists of lists of items from the categories architecture, music, art, film, theater, design, literature, and children culture. The only item in the entire canon which is not of Danish origin is to be found on the last list, and it is a Donald Duck story by Carl Barks: The Golden Helmet.
Disney may have produced a lot of shit, and done a lot wrong, but they definitely also have produced lots of stuff that I happily enjoy together with my children. Disney may even be evil in some ways (in the past exemplified by such practices as keeping the actual artists in total anonymity, like Carl Barks was for a long time.) But some of Disney's production can definitely be counted as great and original art. An example could be "Dumbo", just to name one of my favorites.
I can only hope that maybe with Jobs on the board, the stupid Eisner policy of stopping the most creative cartoon series after a fixed amount of episodes will be changed, so we can get new episodes of KP and Buzz Lightyear!
You don't know geography far enough then! In addition to the admittedly long route around the Baltic Sea (supposing mainland Europe is represented by Germany) through Poland, Lithuania, Estonia, Latvia, Russia and Finland, you can go the more direct route through Denmark. There has been a bridge over Øresund since 2000.
that would be another good reason to use the existing fusion source (solar energy) instead of building expensive tokamaks. However, even "real" local fusion energy would have a far better cost pattern than the existing use of fusion fuel in weapon systems. The reason being that the device used to create the fusion has a far longer lifetime than the fractions of a second in a bomb. Thus the initial cost can be amortized. In principle I can't see anything preventing the price per joule from going down to effectively zero. It would probably take a few centuries, though. My personal opinion is that developing technology for harvesting the existing energy flow from the sun will succeed in an acceptable price far sooner than developing local fusion energy sources.
As for oils use for plastic and other chemistry - as a builder of plastic scale models (we are an almost extinct kind of dinosaurs) I am very much for this use. Oil should be used for chemicals and plastic, and plastic should be reused far more than it is today.
If you have effectively free electrical energy, you can produce other energy sources from that, can't you? I guess you could even transform any excessive CO2 from the atmosphere into pure carbon and oxygen. Of course pure carbon isn't very useful for cars, but again, it could be transformed into gasoline. You could even make diamonds (literally out of the air) if you wanted to.
However, I for one much would prefer using that one fusion energy source we already have, at a fairly safe distance. I know that theoretically a malfunctioning local fusion engine would halt and not run amok, but although I might want to bet the farm on it, I'd rather not bet the entire planet.
To me at least that is a scary prospect which is unfortunately probably true. I am aware of it, at you are aware of it, and any Slashdotter who would care about it is probably also aware of it.
But the large majority of people can't tell the difference between a cheap CD and an expensive one, other than the price. (My own father has an old analog video camera, and he *reuses* the Hi8 tapes after copying to VHS, even though I ask him not to, because he feels the tapes are too expensive.) And they don't understand that while photographic negatives may deteriorate, but probably still make a viewable print, a defective CD will probably mean that anything on it is lost forever and for good. The *lucky* ones are those who will print all their pictures on paper, using some ink that doesn't fade too badly. The sad ones (or their children, or grandchildren) will one day look at a CD with {pictures some emotionally important event or person} written on it, put it in the drive, read the error message and feel the tears of disappointment flowing.
The thought of millions of people crying such tears a few decades from now makes me want to start a movement to prevent it. Join in! Tell people to be careful with their valuable data! For the sake of their children, grandchildren, and future historians. If not, our time will probably be known as the "Erased Era", because there will remain so little information about it.
And for some people, such as my parents, it is by far better to just stick with analog stuff. At least B&W photography has a verified lifetime exceeding 100 years, and not just a calculated expected lifetime.
-Lasse
Re:Which market is most important to us?
on
Ambient Findability
·
· Score: 2, Insightful
Your "Freudian slip" is interesting, because it hints at a far more serious issue. The important question is not how to guarantee easy access to information, we have that, more or less, today. The problem is that with this - precisely expressed - easy information excess, finding the relevant information in time, and keeping the irrelevant information out, becomes harder, not easier.
There are many sub-issues. I'd like to point out just two:
The first issue is that when not all information is digitized, the analog data already in our collective possession will tend to be ignored, and the digital data will be preferred. So a lazy search will show only the digital results, and omit relevant analog results, which would only have been found by harder work.
The second is that while digitally stored information is much easier to copy, it is also much easier to destroy. And a lot of information which would in the past have been rendered in a form that was self-contained and easily transferred physically is now stored in very few copies on harddisks which are volatile. Two examples of this are personal correspondence and photo albums.
The first problem (should it be called "digital boundary"?) can perhaps be postponed by digitizing more, and by digitally published reference works referring the off-line data, although this may actually compound the overall problem in the long run. There is an interesting sf story by Hal Draper(1961): _Ms fnd in a lbry_ on this matter.
The second problem can be "solved" by easier reproduction, distribution and archiving, however that again compounds the overall problem. Also, you may have mixed feelings about having the erotic snapshots you took of your wife last night safely stored at archive.org.
Speaking of which: The wayback machine is attractive, but delusive, as it doesn't really store everything, yet gives the impression that it does. Many websites are dynamic in a way which prevents proper archival. And even if you can archive individual websites, it is exponentially more difficult (=impossible) to archive the relations between websites. I "think" and remember "spatially", and I often would like to be able to go into one of the first libraries I visited, the way it was on the particular day I visited it. If I could do that, I might for instance be able to find a particular sf novel, which I know I have read, but can no longer remember the name of, by picking it from the shelf on which I know I found it.
Ultimately, the externalisation and sharing of human memory is what made civilization what it is today, but it may eventually turn out to also be the doom of civilization.
Actually I knew that much (and let me use this opportunity to say thx in public for having good sound in cinemas), but I didn't want to ruin what little joke there was, completely. Anyway I was under the impression that THX (as a cinema sound standard) had some form of retronymic definition, in addition to being a Lucas "special" mark.
And.. this breaks encapsulation - the the user of the class should neither know or care whether or not X comes from a database! The method that implemements that sort of functionality should be private.
If you believe that, then why do you put that very information in the docs? Make up your mind, should the user know about this or not? If yes, then it is relevant to put it in the docs and in the name; if no, then the property behaves for all intents and purposes as a public member variable and should be accessible as such, even if internally to the class it is represented differently.
If it is relevant for the user to know that X comes from the DB, then it should be in the name. If you choose to give it a standardized, but meaningless name because of tools, then IMO your tools are broken.
Calling NetBSD a "slightly less used desktop os" must be the understatement of the year! That's very kind of you!:-)
However, I am confident that with some effort, things can be made to work. It's only a question of finding the time. If I were really desperate, I'd just use the Linux version with NetBSD's Linux compatibility layer, but where's the fun in that?:-)
What can I say - you're absolutely right of course. But as I said, I already knew that the memory problem was indicating a problem in the code. That wasn't my point. My point was that in the past, I have used a platform where having to state memory demands explicitly was the norm, and that platform (Macintosh pre-OS X) was ridiculed by some for that reason. Yet noone seems to think that it is a problem now with the Java platform. I wonder why.
When I *want* to limit resources available to my programs on Unix, I would use ulimit.
Sorry, but it is my understanding that an accessor function provides an interface which conceptually is identical to a public attribute, only with the option to override with a method in a subclass. If you add behaviour to an accessor function, it should not be of any concern to the user of the class, and therefore whether you use it as foobar.setFoo(42) or foobar.foo = 42 shouldn't matter at all. OTOH, if your accessor has publicly known side-effects then it's not really just an accessor, and it is IMO wrong to write it as an accessor. Write a real method, with an appropriate name indicating the intended behaviour and side-effects.
My suggested scheme for implied accessor functions does not prevent you from having things work as you like, though. If you don't provide the public Foo foo attribute, but write the accessors yourself, you would get precisely what you want. It's similar to the way Java provides a default constructor. You can add your own instead. There's no restriction, it just works by default without you having to write anything. Of course I don't suppose you would be bothered by having to write (or have your IDE write) trivial constructors for your classes.
Being able to use plain assignment rather than calling the accessor methods is of course just nice glukosyntax.
Having just recently achieved the dubious title of Java Certified Programmer I understand that public attributes are considered as breaking encapsulation. So, instead of doing it the way I suggested, Java requires you to add accessors in all cases where you would want to use a public member, because of the few cases where you might want non-default behaviour of accessors. I believe that is a case of language design being ruined by bad and wrong priorities. And I think this should be fixed in the Java language itself rather than swept under the carpet by a "helpful" IDE.
Slashdot Mirror
I sure hope noone will ever let you have anything whatsoever to do with user interface design. Or any other kind of design for that matter.
-Lasse
I suppose you were trying to write "lack of knowledge or will to learn".
It is common knowledge that Ctrl-N should be a shortcut to create a new item. Presumably an item one often wants to create a new one of. For example a message. In Notes, I get a new database. What am I suppose to do with that? I am not designing any databases! I press the spacebar to page down in a mail - only to get told some action or other is "not allowed". What? So Notes goes against my knowledge - you can call that a lack. As for my willingness to learn: right, I am not willing to learn an awkward and archaic interface, to any extent beyond what is absolutely necessary to get my job done. It doesn't seem cost-effective to me.
And looking at "properties", I get a neat window with more than half a dozen tabs, containing information I don't want to care about and would prefer not to be bothered with. I think it was the third one that gave me some info about the size of the mailbox. By the way: the silly person who thought a propeller-hat icon was cute for "expert" options - I really hope he or she doesn't work with development of Notes anymore.
A while ago, a message circulated at the office, containing a "script" or "extension" for Notes, which showed a column indicating mails where you are just CC:ed. Naively tempted by the apparant usefulness of this thingy, I installed it. It hosed my mailbox, and took a couple of smarter guys about an hour to disentangle, and I wasn't the only one for which this happened. Apparantly you shouldn't trust such hacks - but if the customizability of Notes is so extensive that "amateurs" with good intentions can fuck up the mail app for numerous colleagues, it is so dangerous that perhaps it wasn't a good idea in the first place.
As for my admin: I didn't mention it before, but I work at IBM. I suppose if anyone "could of", the IBM Notes guys "would of".
I don't know if Jeff Raskin said it quite like this, but I suppose he would have agreed. If you design an application to be totally customizable, chances are that you did so because you are too lazy or just not smart enough to simply make it do the right thing in the first place. It's like responding to a customer's demand for a program by giving him a C compiler and hello.c and say: "There you are: this thing can do anything you need. You just use the C compiler to customize it first."
-Lasse
I don't know about you, but I am paid to do other things than explore, program, reprogram, tune and configure my e-mail application. All the time I waste trying to second-guess Notes is completely unproductive from my point of view. Especially when I know that if the UI had actually been designed to be intuitive to learn and use, I could be far more productive. Yes, I dare blame Notes for that. It is the same reason I prefer using (a small subset of) vi rather than emacs, and NetBSD rather than Linux. I like tools that do one thing well. (And wouldn't you know, I am a former Mac user.)
I would rather read my mail using "less" on individual files in a QMail Maildir! Heck, extracting them from the raw disk device with dd would be an improvement over Notes! And I wouldn't be bothered much by sending mail by typing straight SMTP commands into telnet $mailhost 25. At least it would be far more consistent than Notes.
-Lasse
You must be using a different R7 than I am. Oh, sure, it probably has all those features. I just don't seem to be able to find the time to learn to use them. Notes is so counter-intuitive in all aspects of its user interface, it is an abomination. Why do I have to concern myself with the way "database replication" is set up? Why should I have to deal with these mysterious "databases" anyway? How about using some terms I can relate to? What are all those arcane icons and figures I see when I choose "properties" by accident? Why are some buttons mysteriously disabled when I want to click them? The list of awkward interface issues is endless.
Noone can complain about the features of Notes. And noone is, I guess. Every sane person would complain about the interface, though. Notes looks as if it was designed by FORTRAN and COBOL programmers thinking (dreaming, living) in punch cards.
I feel like I have been taken on a cruise ship, but instead of sitting comfortably on the deck or in a lounge, I have been locked up in the darkened engine room, with unbearable noise and pungent diesel smells.
In my previous job, we used Outlook, and I hated it. But Notes makes me want to go back!
Notes is my worst nightmare!
-Lasse
I have been using NetBSD on the desktop - or rather: laptop - for a long time. Started with a ThinkPad T22 in 2001, now I have a Thinkpad R50e. It just works.
-Lasse
I'd say the problem is that these fasteners *aren't* screwed?!?
This whole idea is nuts!
-Lasse
May I suggest you change your name though simple transpositioning to stubidoratto? It would be more fitting.
Using your logic, everything is base 10, because whenever the word base is used, noone expects decimal numbers, right?
-Lasse
"Always be ready to speak your mind and a base man will avoid you." (William Blake)
Hey, lighten up! It's still not as bad as a drawing of Muhammad, now is it?
-Lasse
There really is no mess. SI just needs to accept the de facto norm that the base and exponent of the multiplier of a prefix depends on the unit it prefixes.
So, for all traditional physical units:
k : base = 10 , exponent = 3, M: base = 10, exponent = 6, etc
For bits and bytes etc:
k: base = 2, exponent = 10, M: base = 2, exponent = 20, etc
Simple. No bibology or kibology or any other sillyness needed.
-Lasse
Assembler isn't portable. C is portable assembler. It should be org.c.nerd.
-Lasse
Go back 9 years. Apple buys NeXT. If anyone could turn around Apple, Steve Jobs was the one who did it.
-Lasse
Although I am not a card-carrying donaldist (though definitely donaldist), I find it appropriate to counter your Dorfman book with some sense. It's been some time since I read that book, but I believe that some of its arguments are quite far-fetched, to say the least. Further I believe some of it was related to locally (South America) produced material using Disney figures (just as we in Europe have a large production of Donald Duck comics, that is probably completely unknown in the United States.)
The ministry of culture in Denmark recently published a cultural "canon", cultural works that have a strong and integral relation to Danish culture. The canon consists of lists of items from the categories architecture, music, art, film, theater, design, literature, and children culture. The only item in the entire canon which is not of Danish origin is to be found on the last list, and it is a Donald Duck story by Carl Barks: The Golden Helmet.
Disney may have produced a lot of shit, and done a lot wrong, but they definitely also have produced lots of stuff that I happily enjoy together with my children. Disney may even be evil in some ways (in the past exemplified by such practices as keeping the actual artists in total anonymity, like Carl Barks was for a long time.) But some of Disney's production can definitely be counted as great and original art. An example could be "Dumbo", just to name one of my favorites.
I can only hope that maybe with Jobs on the board, the stupid Eisner policy of stopping the most creative cartoon series after a fixed amount of episodes will be changed, so we can get new episodes of KP and Buzz Lightyear!
-Lasse
You don't know geography far enough then! In addition to the admittedly long route around the Baltic Sea (supposing mainland Europe is represented by Germany) through Poland, Lithuania, Estonia, Latvia, Russia and Finland, you can go the more direct route through Denmark. There has been a bridge over Øresund since 2000.
-Lasse
No problem, for drinking and smoking you just do like all the other Swedes: take a short to Denmark.
-Lasse
I thought people from Liverpool were lever pullers?
(Anyway, I prefer the blue meanies. I suppose they're from Birmingham.)
-Lasse
that would be another good reason to use the existing fusion source (solar energy) instead of building expensive tokamaks. However, even "real" local fusion energy would have a far better cost pattern than the existing use of fusion fuel in weapon systems. The reason being that the device used to create the fusion has a far longer lifetime than the fractions of a second in a bomb. Thus the initial cost can be amortized. In principle I can't see anything preventing the price per joule from going down to effectively zero. It would probably take a few centuries, though. My personal opinion is that developing technology for harvesting the existing energy flow from the sun will succeed in an acceptable price far sooner than developing local fusion energy sources.
As for oils use for plastic and other chemistry - as a builder of plastic scale models (we are an almost extinct kind of dinosaurs) I am very much for this use. Oil should be used for chemicals and plastic, and plastic should be reused far more than it is today.
-Lasse
If you have effectively free electrical energy, you can produce other energy sources from that, can't you? I guess you could even transform any excessive CO2 from the atmosphere into pure carbon and oxygen. Of course pure carbon isn't very useful for cars, but again, it could be transformed into gasoline. You could even make diamonds (literally out of the air) if you wanted to.
However, I for one much would prefer using that one fusion energy source we already have, at a fairly safe distance. I know that theoretically a malfunctioning local fusion engine would halt and not run amok, but although I might want to bet the farm on it, I'd rather not bet the entire planet.
-Lasse
To me at least that is a scary prospect which is unfortunately probably true. I am aware of it, at you are aware of it, and any Slashdotter who would care about it is probably also aware of it.
But the large majority of people can't tell the difference between a cheap CD and an expensive one, other than the price. (My own father has an old analog video camera, and he *reuses* the Hi8 tapes after copying to VHS, even though I ask him not to, because he feels the tapes are too expensive.) And they don't understand that while photographic negatives may deteriorate, but probably still make a viewable print, a defective CD will probably mean that anything on it is lost forever and for good. The *lucky* ones are those who will print all their pictures on paper, using some ink that doesn't fade too badly. The sad ones (or their children, or grandchildren) will one day look at a CD with {pictures some emotionally important event or person} written on it, put it in the drive, read the error message and feel the tears of disappointment flowing.
The thought of millions of people crying such tears a few decades from now makes me want to start a movement to prevent it. Join in! Tell people to be careful with their valuable data! For the sake of their children, grandchildren, and future historians. If not, our time will probably be known as the "Erased Era", because there will remain so little information about it.
And for some people, such as my parents, it is by far better to just stick with analog stuff. At least B&W photography has a verified lifetime exceeding 100 years, and not just a calculated expected lifetime.
-Lasse
Your "Freudian slip" is interesting, because it hints at a far more serious issue. The important question is not how to guarantee easy access to information, we have that, more or less, today. The problem is that with this - precisely expressed - easy information excess, finding the relevant information in time, and keeping the irrelevant information out, becomes harder, not easier.
There are many sub-issues. I'd like to point out just two:
The first issue is that when not all information is digitized, the analog data already in our collective possession will tend to be ignored, and the digital data will be preferred. So a lazy search will show only the digital results, and omit relevant analog results, which would only have been found by harder work.
The second is that while digitally stored information is much easier to copy, it is also much easier to destroy. And a lot of information which would in the past have been rendered in a form that was self-contained and easily transferred physically is now stored in very few copies on harddisks which are volatile. Two examples of this are personal correspondence and photo albums.
The first problem (should it be called "digital boundary"?) can perhaps be postponed by digitizing more, and by digitally published reference works referring the off-line data, although this may actually compound the overall problem in the long run. There is an interesting sf story by Hal Draper(1961): _Ms fnd in a lbry_ on this matter.
The second problem can be "solved" by easier reproduction, distribution and archiving, however that again compounds the overall problem. Also, you may have mixed feelings about having the erotic snapshots you took of your wife last night safely stored at archive.org.
Speaking of which: The wayback machine is attractive, but delusive, as it doesn't really store everything, yet gives the impression that it does. Many websites are dynamic in a way which prevents proper archival. And even if you can archive individual websites, it is exponentially more difficult (=impossible) to archive the relations between websites. I "think" and remember "spatially", and I often would like to be able to go into one of the first libraries I visited, the way it was on the particular day I visited it. If I could do that, I might for instance be able to find a particular sf novel, which I know I have read, but can no longer remember the name of, by picking it from the shelf on which I know I found it.
Ultimately, the externalisation and sharing of human memory is what made civilization what it is today, but it may eventually turn out to also be the doom of civilization.
-Lasse
Actually I knew that much (and let me use this opportunity to say thx in public for having good sound in cinemas), but I didn't want to ruin what little joke there was, completely. Anyway I was under the impression that THX (as a cinema sound standard) had some form of retronymic definition, in addition to being a Lucas "special" mark.
-Lasse
What is it BTW THX stands for? Total Hearing Xtermination?
-Lasse
And.. this breaks encapsulation - the the user of the class should neither know or care whether or not X comes from a database! The method that implemements that sort of functionality should be private.
If you believe that, then why do you put that very information in the docs? Make up your mind, should the user know about this or not? If yes, then it is relevant to put it in the docs and in the name; if no, then the property behaves for all intents and purposes as a public member variable and should be accessible as such, even if internally to the class it is represented differently.
If it is relevant for the user to know that X comes from the DB, then it should be in the name. If you choose to give it a standardized, but meaningless name because of tools, then IMO your tools are broken.
-Lasse
Calling NetBSD a "slightly less used desktop os" must be the understatement of the year! That's very kind of you! :-)
:-)
However, I am confident that with some effort, things can be made to work. It's only a question of finding the time. If I were really desperate, I'd just use the Linux version with NetBSD's Linux compatibility layer, but where's the fun in that?
-Lasse
What can I say - you're absolutely right of course. But as I said, I already knew that the memory problem was indicating a problem in the code. That wasn't my point. My point was that in the past, I have used a platform where having to state memory demands explicitly was the norm, and that platform (Macintosh pre-OS X) was ridiculed by some for that reason. Yet noone seems to think that it is a problem now with the Java platform. I wonder why.
When I *want* to limit resources available to my programs on Unix, I would use ulimit.
-Lasse
Sorry, but it is my understanding that an accessor function provides an interface which conceptually is identical to a public attribute, only with the option to override with a method in a subclass. If you add behaviour to an accessor function, it should not be of any concern to the user of the class, and therefore whether you use it as foobar.setFoo(42) or foobar.foo = 42 shouldn't matter at all. OTOH, if your accessor has publicly known side-effects then it's not really just an accessor, and it is IMO wrong to write it as an accessor. Write a real method, with an appropriate name indicating the intended behaviour and side-effects.
My suggested scheme for implied accessor functions does not prevent you from having things work as you like, though. If you don't provide the public Foo foo attribute, but write the accessors yourself, you would get precisely what you want. It's similar to the way Java provides a default constructor. You can add your own instead. There's no restriction, it just works by default without you having to write anything. Of course I don't suppose you would be bothered by having to write (or have your IDE write) trivial constructors for your classes.
Being able to use plain assignment rather than calling the accessor methods is of course just nice glukosyntax.
Having just recently achieved the dubious title of Java Certified Programmer I understand that public attributes are considered as breaking encapsulation. So, instead of doing it the way I suggested, Java requires you to add accessors in all cases where you would want to use a public member, because of the few cases where you might want non-default behaviour of accessors. I believe that is a case of language design being ruined by bad and wrong priorities. And I think this should be fixed in the Java language itself rather than swept under the carpet by a "helpful" IDE.
My comments on comments come in another comment.
-Lasse