Why do people concerned about usability spend so much time worrying about what people can do in the first 5 minutes after they sit down at a 'puter and so little time worrying about what people will be able to accomplish over the next five years?
Because there is a large number of potential users who will use something else if they can't work out how the thing works in less than five minutes.
It's a trade off. You can either spend your time making the software good and not having many users. Or you can spend your time making the software easy to use and have crappy software that everyone uses.
You can't "innovate" either since that herd of users can't deal with change. Plan9 is an example of an "innovative" OS, it essentially was a great unix2 with a motto of "No really, this time *everything* is a file". Look how well Plan9 did in the OS market share...
Re:OK, most are ugly, but fvwm is the fug-ugliest
on
fvwm Turns Ten
·
· Score: 1
Because that doesn't work on a Tektronix X terminal.
And even fewer people know how to bring up the menu on them then know how to exit 9wm:)
I believe the cameras have a 3% of 3km/h (whicherver is the higher) error allowance tacked on.
Plus I think our speedos are only required to have an error of somewhere around 10%, so you get that as well:)
Though maybe it's Victoria I'm thinking of?
What I hate about speed cameras is the delay, you get booked but don't know about it until you get a letter. By which time you've probably travelled at the same speed on a number of occassions and can look forward to yet more mail. Well I've never been booked by a speed camera - but I think that's what I'd hate...
After all the argument is for "safety" not revenue, so it seems unfair to book me numerous times when as soon as you booked me once I would slow down. Plus maybe I made an honest mistake about the posted speed limit (if you've seen how they change up and down numerous time in one section of road in Sydney you'd understand how easy that is).
There are many sections of road whose speed limit I can't work out because there is no speed signs between my entrance and my exit, and it clearly isn't a default 60 zone, since everyone is doing 80. It's probably 80, but it could be 70 - that road flips and changes between the two in other areas. I'd be annoyed if I suddenly got 5 tickets, because the limit was actually 70 and I was doing 82 because I was merging with traffic that was doing that and I thought the limit was 80.
Re:OK, most are ugly, but fvwm is the fug-ugliest
on
fvwm Turns Ten
·
· Score: 1
I found 9wm combined with 9term works wonders. You never have to log out since no one can work out how to get run anything, and if they fluke on starting a 9term they won't work out the extra drag step.
Plus there's no 'exit' or 'logout' option, and the inability to get a terminal window will prevent them exiting the window manager, even if they know the command.
I still haven't worked out how to stop a power cycle logging me off though.
If you consider "damn" and "hell" swearing I suggest you tell daddy to not let you use the computer anymore.
Clearly the work "stupid" annoyed some people. I can't understand why, since it was used in the description of a method of scoring, not in the description of a person or the entire product.
In fact in that context stupid and pointless are synonymous, so why have you put them in differnt categories? I used stupid to mean pointless. And I considered it an extreme circumstance - as in it was something I thought was a major flaw in an otherwise good product.
If a the winner of a race was declared the one who took the longest to run it, I would use the word stupid to describe that scoring mechanism.
Similarly, a logic game which awarded more points for longer, more complicated, less efficient solutions is something for which I would also describe the scoring system as stupid.
I honestly think the scoring system described for that game is stupid - ie. pointless and worthless. But only the scoring system, the rest of it seems good and useful to me.
I didn't insult the author of the game at all. I didn't take my frustrations out on them.
I simply criticised one aspect of the game that I think is not just suboptimal but damaging to the rest of the game. And mentioned something about making getting the code more difficult than it needs to be.
I still can't see how it wasn't constructive.
A scoring system which would give a higher score to adding a large number of randomly interconnected gates and then adding a not gate before each output that was wrong; then it would to actually thinking and creating an efficient cricuit seems counter-productive to me.
I said the scoring system was stupid. That's orthogonal to the actual program.
I even explained why I though it was stupid.
Stupid is synonymous with pointless in the context I used. I stand by my statement that a scoring system which encourages inefficient logic is pointless for learning logic.
I pointed out something I thought was wrong with the scoring system. *And* gave a suggestion that I think would be better. If that isn't constructive ciriticism, then what the hell is?
I pointed out that "source available on request" is far less likely to get people hacking on the source, it adds an extra step that isn't necessary. Especially if you are going to email the source to nayone that asks anyway - since that's functionally identical to allowing downloads aside from the email address thing, but hotmail addresses are disposable. That seems constructive to me as well?
Saying "That program sucks" would be non-constructive. But I didn't say that.
That's just stupid, play the increedible machine if you want to make convoluted stupid ways of doing things...
It also doesn't help with teaching logic or starting up your brain in the morning, after all the usual aim is to minimise either the cost (by using cheaper gates and as few as possible) or the delay (by using faster gates and as few in series as possible) plus you can always make something more complicated whereas there is a 'best' solution (possible a few) using cheaper/faster as the metric.
Also if you want to flesh it out more posting the damn source on your web page would be a good start, "source available on request" just means I won't bother wasting my time...
I've seen some reasonably modern banking code (which my wife was working on), wrappers on wrappers on wrappers each fixing some small flaw in the layer it wrapped around (and adding a few of its own) because changing the lower wrapper was either impossible or too scary to contemplate...
My first computer was a little "dick smith" (think radio shack or tandy) machine for which I had a basic catridge. It got stolen and replaced with the vastly superior C64 by the insurance company which was nice:)
As for optimising the code, I was thinking of something along the lines of:
Whch has the additional assumption of ints being 4x a char (in size), and possibly that char is unsigned but I haven't actually though about that, and that src and dst are aligned appropriately for ints, and numerous other things I haven't considered....
But on an appropriate 32 bit machine, doing 4 operations in parallel (which we can do because the 20-100 limit means there won't be any 'overflow' between the bytes) will be a win, especially if 8 bit char access requires bit masking/shifting on the processor.
Doing 100000 loops of the orig, your pointer version, a loop unrolled version, and my ugly unmaintainable int pointer version (clock count):
I'm not a prof, I'm not saddled with first year classes - I taught some CS2 classes a few years ago which doesn't make me a prof and doesn't mean I still do it.
I've been progrmming for about 20 years too, though a large chunk of that was C64 assembler and basic when I was yet to be teenager.
I've paid the rent hacking code originally written by biologists, trust me I've worked with crappy code which uses undocumented binary only buggy libraries and unoptimised crap that needed fixing in order to have the run not take all week...
My main programming at the moment is on a micro with 512 bytes of RAM (though I'm mainly writing prose at the moment), a few hours ago the delivery guy dropped of a package of some *drool* 32KB srams... My code is now twice as fast, not due to the sram (which is for something else) but due to the 8Mhz crystals he also dropped off, I changed a '4' to an '8' in my code swapped the crystal and it's now twice as fast... And my code is just as readable as before:)
But all that is irrelevant.
I understand that hand optimising C code sometimes leads to better programs.
However, your example was silly - which is what I was pointing out, but you decided it was worth defending and hence I can only assume you don't consider it completely silly.
The original code was inneficient because the programmer was using functions which are designed to work with strings of unknown length (strlen and strcpy) when in fact they had a known length string and should have been using functions designed to work with those (sizeof and memcpy).
'Fixing' the code by writing a bunch of char assignments may improve the speed (or may kill it completely due to the increase in code size - though with just 4 chars it will likely reduce the code size too) but at the cost of a massive decrease in maintainability. Since using sizeof and memcpy will give the same speed improvement and not make the code any less readable it seems the better solution. As a bonus memcpy might even copy word sized chunks instead of bytes - maybe i you get lucky.
There are many better examples, in which the solution is actually hand optimising as opposed to being the use of an appropriate special purpose function/macro instead of a slower more general one.
The example sucked and simply wasn't an example where hand optimising produces a useful benefit.
Trading maintainablility for speed is not uncommon, just giving it away for no return is a bit silly though.
Unrolling a loop is a common enough technique to speed things up, but your choice of example presented memcpy as the solution. Writing a set of memcpy macros which automate the loop unrolling is easy enough - especially if your compiler supports modern C++ templates (though in that case I would suspect it unrolls loops just fine itself thanks).
Wouldn't provoke the same response from me if it was unrolled, since if it is too slow it isn't due to the str* functions but due to loop overhead (or too slow hardware, full stop.)
So how would you optimise that?
What if you know that the values are always between 20 and 100 (feel free to add some other known constraints)?
In my (I admit not exactly exhaustive experience) the best value optmisations are those that are based upon things the programmer knows that are not expressed in the code and hence the compiler doesn't. Of course if you are using a shitty old compiler you also get the joys of doing by hand all the optimisations that have been automated for the last decade or two:)
And hopefully those many programmers are out of a job, for producing hideously difficult code to maintain for absolutely no benefit.
And of course the strlen() isn't the problem, since in that case it can be replaced with sizeof() since the array declaration is visible, the strcpy is the problem. But of course there is another function called memcpy for use when you *know* the length.
If your compiler (with appropriate optimiser settings) doesn't produce equivalent code (for the loop unrolling, using literal loads instead of movs in the assembler is another story and in practice isn't what you want because you'd just rename foo_init to foo and drop the const in that case:) to your unmaintainable hand unrolled piece of shit from:
Then you need to get a new compiler (or write a for loop, which the compiler will unroll, if your libc is the problem...)
Now change foo_init to:a different string" and then to "yet another different string" and then to "short". I think I prefer my version that lets the compiler do the unrolling and requires only one simple modification to do that, as opposed to your which requires every line except the first to be modified to achieve such a simple change.
I did hear rumors about insurance companies wanting to charge drivers by the mile! This really pisses me off since I use to do copier repair. Why should I be charged for driving my own car so I can work?
Why should I pay the same as you when I only drive 20km a week, and hence spend less time on the road?
Over time the "lines" will break. Since "Capstone" is much shorter than "University Commons" it might take a while though...
Many many years ago we had some labs at uni called the "duck labs", due to machines called huey, duey, and louie. Long after those machines were abandoned the name stuck. I remember ugrads who started after those machines were history still having icons for them on their X window managers (since they just copied configs year after year).
Now they are called "the LG40s', by everyone even those who were around in the duck labs days.
data are stored in a safe storage within tens of milliseconds on average
For ACID you have to wait until that happens. SDRAM has a write cycle time measured in nanoseconds, which is a damn sight faster than "tens of milliseconds".
Higher level languages (well C and nothing else) will be used more and more.
But for a long time yet there will be a use for little microcontrollers, the ones with only tens of registers and a 2 or 3 level hardware stack as memory. The C code wouldn't be any simpler than the assembler. Of course with the beasty 'micro'controllers with 4KB of RAM and 16KB of ROM and clocks of 16Mhz your really programming an early PC so C is the obvious solution:)
Even when you code in C, you tend to write the occassional bit of assembler when timing becomes important and you need N clocks and no more in order to meet it, or when it is just plain simpler to twiddle IO ports in assembler:)
The whole thing was about not writing to disk *ever* (in the normal running of the database anyway).
No matter how much memory buffer cache the database is using, in order to be ACID it has to be *writing* to the disk and waiting for those writes to be *written to disk*.
Removing the disk completely removes any need for all that...
Slashdot Mirror
It's a trade off. You can either spend your time making the software good and not having many users. Or you can spend your time making the software easy to use and have crappy software that everyone uses.
You can't "innovate" either since that herd of users can't deal with change. Plan9 is an example of an "innovative" OS, it essentially was a great unix2 with a motto of "No really, this time *everything* is a file". Look how well Plan9 did in the OS market share...
Because that doesn't work on a Tektronix X terminal.
:)
And even fewer people know how to bring up the menu on them then know how to exit 9wm
Our automatic speed cameras overlook such things.
:)
I believe the cameras have a 3% of 3km/h (whicherver is the higher) error allowance tacked on.
Plus I think our speedos are only required to have an error of somewhere around 10%, so you get that as well
Though maybe it's Victoria I'm thinking of?
What I hate about speed cameras is the delay, you get booked but don't know about it until you get a letter. By which time you've probably travelled at the same speed on a number of occassions and can look forward to yet more mail. Well I've never been booked by a speed camera - but I think that's what I'd hate...
After all the argument is for "safety" not revenue, so it seems unfair to book me numerous times when as soon as you booked me once I would slow down. Plus maybe I made an honest mistake about the posted speed limit (if you've seen how they change up and down numerous time in one section of road in Sydney you'd understand how easy that is).
There are many sections of road whose speed limit I can't work out because there is no speed signs between my entrance and my exit, and it clearly isn't a default 60 zone, since everyone is doing 80. It's probably 80, but it could be 70 - that road flips and changes between the two in other areas. I'd be annoyed if I suddenly got 5 tickets, because the limit was actually 70 and I was doing 82 because I was merging with traffic that was doing that and I thought the limit was 80.
I found 9wm combined with 9term works wonders. You never have to log out since no one can work out how to get run anything, and if they fluke on starting a 9term they won't work out the extra drag step.
Plus there's no 'exit' or 'logout' option, and the inability to get a terminal window will prevent them exiting the window manager, even if they know the command.
I still haven't worked out how to stop a power cycle logging me off though.
Usage defined meaning, so dilution certainly affects it.
:)
Then again I guess it could be argued that 'damn' the context I used it could mean "the least valuable bit". Or even just plain "damned".
Anyway this is slashdot, informal writing is much more common than formal.
If you consider "damn" and "hell" swearing I suggest you tell daddy to not let you use the computer anymore.
Clearly the work "stupid" annoyed some people. I can't understand why, since it was used in the description of a method of scoring, not in the description of a person or the entire product.
In fact in that context stupid and pointless are synonymous, so why have you put them in differnt categories? I used stupid to mean pointless. And I considered it an extreme circumstance - as in it was something I thought was a major flaw in an otherwise good product.
If a the winner of a race was declared the one who took the longest to run it, I would use the word stupid to describe that scoring mechanism.
Similarly, a logic game which awarded more points for longer, more complicated, less efficient solutions is something for which I would also describe the scoring system as stupid.
I honestly think the scoring system described for that game is stupid - ie. pointless and worthless. But only the scoring system, the rest of it seems good and useful to me.
I didn't insult the author of the game at all. I didn't take my frustrations out on them.
I simply criticised one aspect of the game that I think is not just suboptimal but damaging to the rest of the game. And mentioned something about making getting the code more difficult than it needs to be.
I still can't see how it wasn't constructive.
A scoring system which would give a higher score to adding a large number of randomly interconnected gates and then adding a not gate before each output that was wrong; then it would to actually thinking and creating an efficient cricuit seems counter-productive to me.
Learn how to read.
I said the scoring system was stupid. That's orthogonal to the actual program.
I even explained why I though it was stupid.
Stupid is synonymous with pointless in the context I used. I stand by my statement that a scoring system which encourages inefficient logic is pointless for learning logic.
How the hell was that cot constructive?!?!?!?
I pointed out something I thought was wrong with the scoring system. *And* gave a suggestion that I think would be better. If that isn't constructive ciriticism, then what the hell is?
I pointed out that "source available on request" is far less likely to get people hacking on the source, it adds an extra step that isn't necessary. Especially if you are going to email the source to nayone that asks anyway - since that's functionally identical to allowing downloads aside from the email address thing, but hotmail addresses are disposable. That seems constructive to me as well?
Saying "That program sucks" would be non-constructive. But I didn't say that.
It also doesn't help with teaching logic or starting up your brain in the morning, after all the usual aim is to minimise either the cost (by using cheaper gates and as few as possible) or the delay (by using faster gates and as few in series as possible) plus you can always make something more complicated whereas there is a 'best' solution (possible a few) using cheaper/faster as the metric.
Also if you want to flesh it out more posting the damn source on your web page would be a good start, "source available on request" just means I won't bother wasting my time...
I've seen some reasonably modern banking code (which my wife was working on), wrappers on wrappers on wrappers each fixing some small flaw in the layer it wrapped around (and adding a few of its own) because changing the lower wrapper was either impossible or too scary to contemplate...
:)
:)
My first computer was a little "dick smith" (think radio shack or tandy) machine for which I had a basic catridge. It got stolen and replaced with the vastly superior C64 by the insurance company which was nice
As for optimising the code, I was thinking of something along the lines of:
*(unsigned int*)dst = *(unsigned int*)src*2;
dst[4] = src[4]*2;
Whch has the additional assumption of ints being 4x a char (in size), and possibly that char is unsigned but I haven't actually though about that, and that src and dst are aligned appropriately for ints, and numerous other things I haven't considered....
But on an appropriate 32 bit machine, doing 4 operations in parallel (which we can do because the 20-100 limit means there won't be any 'overflow' between the bytes) will be a win, especially if 8 bit char access requires bit masking/shifting on the processor.
Doing 100000 loops of the orig, your pointer version, a loop unrolled version, and my ugly unmaintainable int pointer version (clock count):
orig: 340000
unrolled: 110000
ptrs: 330000
int: 20000
Of course on a different machine, the int version just plain won't work
I'm not a prof, I'm not saddled with first year classes - I taught some CS2 classes a few years ago which doesn't make me a prof and doesn't mean I still do it.
:)
// ...
:)
I've been progrmming for about 20 years too, though a large chunk of that was C64 assembler and basic when I was yet to be teenager.
I've paid the rent hacking code originally written by biologists, trust me I've worked with crappy code which uses undocumented binary only buggy libraries and unoptimised crap that needed fixing in order to have the run not take all week...
My main programming at the moment is on a micro with 512 bytes of RAM (though I'm mainly writing prose at the moment), a few hours ago the delivery guy dropped of a package of some *drool* 32KB srams... My code is now twice as fast, not due to the sram (which is for something else) but due to the 8Mhz crystals he also dropped off, I changed a '4' to an '8' in my code swapped the crystal and it's now twice as fast... And my code is just as readable as before
But all that is irrelevant.
I understand that hand optimising C code sometimes leads to better programs.
However, your example was silly - which is what I was pointing out, but you decided it was worth defending and hence I can only assume you don't consider it completely silly.
The original code was inneficient because the programmer was using functions which are designed to work with strings of unknown length (strlen and strcpy) when in fact they had a known length string and should have been using functions designed to work with those (sizeof and memcpy).
'Fixing' the code by writing a bunch of char assignments may improve the speed (or may kill it completely due to the increase in code size - though with just 4 chars it will likely reduce the code size too) but at the cost of a massive decrease in maintainability. Since using sizeof and memcpy will give the same speed improvement and not make the code any less readable it seems the better solution. As a bonus memcpy might even copy word sized chunks instead of bytes - maybe i you get lucky.
There are many better examples, in which the solution is actually hand optimising as opposed to being the use of an appropriate special purpose function/macro instead of a slower more general one.
The example sucked and simply wasn't an example where hand optimising produces a useful benefit.
Trading maintainablility for speed is not uncommon, just giving it away for no return is a bit silly though.
Unrolling a loop is a common enough technique to speed things up, but your choice of example presented memcpy as the solution. Writing a set of memcpy macros which automate the loop unrolling is easy enough - especially if your compiler supports modern C++ templates (though in that case I would suspect it unrolls loops just fine itself thanks).
An example like:
char res[5];
char src[5];
for (int i=0; i<5; ++i)
res[i] = src[i] + src[i]
Wouldn't provoke the same response from me if it was unrolled, since if it is too slow it isn't due to the str* functions but due to loop overhead (or too slow hardware, full stop.)
So how would you optimise that?
What if you know that the values are always between 20 and 100 (feel free to add some other known constraints)?
In my (I admit not exactly exhaustive experience) the best value optmisations are those that are based upon things the programmer knows that are not expressed in the code and hence the compiler doesn't. Of course if you are using a shitty old compiler you also get the joys of doing by hand all the optimisations that have been automated for the last decade or two
*Every* compiler that can compile C++ code will be able to inline and unroll bloody memcpy.
And if you stuck with some compiler written by a first year CS student that doesn't, then there are these things called macros...
Those macros will already exist if your libc wasn't also written by a first year CS student (as extensions of to the standard functions).
Compotent programmers would use them rather than writing a bunch of assignments by hand and making the code completely unmaintainable.
Honestly a programmer who produced that code would be sacked in an instant if I happened to be making hiring/firing decisions...
That code has to be the worst C++ I've ever seen (and I've taught (and hence marked the code of) around 1500 intro C++ students)...
And hopefully those many programmers are out of a job, for producing hideously difficult code to maintain for absolutely no benefit.
:) to your unmaintainable hand unrolled piece of shit from:
:a different string" and then to "yet another different string" and then to "short". I think I prefer my version that lets the compiler do the unrolling and requires only one simple modification to do that, as opposed to your which requires every line except the first to be modified to achieve such a simple change.
And of course the strlen() isn't the problem, since in that case it can be replaced with sizeof() since the array declaration is visible, the strcpy is the problem. But of course there is another function called memcpy for use when you *know* the length.
If your compiler (with appropriate optimiser settings) doesn't produce equivalent code (for the loop unrolling, using literal loads instead of movs in the assembler is another story and in practice isn't what you want because you'd just rename foo_init to foo and drop the const in that case
char *foo;
const char foo_init[] = "bar";
foo = new char[sizeof(foo_init)];
memcpy(foo, foo_init, sizeof(foo_init));
Then you need to get a new compiler (or write a for loop, which the compiler will unroll, if your libc is the problem...)
Now change foo_init to
What a useful analogy.
After all the average slashdot reader is far more likely to know more about mechanics than about unix...
Or if you've ever taken a non-flash photo at night - that wasn't actually of the stars...
And if it was on the news it must be true!!!
Maybe if your phone had an antenna 5 miles long, and 4 foot wide...
Oh and the high powered laser beams bouncing back and forth inside:)
Over time the "lines" will break. Since "Capstone" is much shorter than "University Commons" it might take a while though...
Many many years ago we had some labs at uni called the "duck labs", due to machines called huey, duey, and louie. Long after those machines were abandoned the name stuck. I remember ugrads who started after those machines were history still having icons for them on their X window managers (since they just copied configs year after year).
Now they are called "the LG40s', by everyone even those who were around in the duck labs days.
None of those things are even near the pain level caused by having your family shot by adrenaline overdosed SWAT officers.
You can't continue until the data is on the disk. In the RAM buffer isn't good enough, since if it goes down right then it isn't on disk...
Higher level languages (well C and nothing else) will be used more and more.
:)
:)
But for a long time yet there will be a use for little microcontrollers, the ones with only tens of registers and a 2 or 3 level hardware stack as memory. The C code wouldn't be any simpler than the assembler. Of course with the beasty 'micro'controllers with 4KB of RAM and 16KB of ROM and clocks of 16Mhz your really programming an early PC so C is the obvious solution
Even when you code in C, you tend to write the occassional bit of assembler when timing becomes important and you need N clocks and no more in order to meet it, or when it is just plain simpler to twiddle IO ports in assembler
Writing to a disk (even without a seek) is no where near the speed of writing to RAM.
No that's not right.
The whole thing was about not writing to disk *ever* (in the normal running of the database anyway).
No matter how much memory buffer cache the database is using, in order to be ACID it has to be *writing* to the disk and waiting for those writes to be *written to disk*.
Removing the disk completely removes any need for all that...