But what would your comment say? For instance, would you indicate in your comment that this code will *not* properly handle HTML comments or Javascript content?
IMO, this is the evilness of perl: it leads you on to think that the trivial hack is actually a correct solution.
And no one has come up with a technology to take out shield armed opponents at a distance besides the lasgun? Here's one, a cannon that shoots nets. You do it today to capture birds, why not Sardaurkar. Once their safely entangled in your nets, smash their heads with a sledgehammer.
I think this may have been deliberate: one of the (subplots? themes? ideas?) in the book was that humanity had stagnated. Forty thousand years of peace and stability have made the race settled and complacent; there are signs of this elsewhere (such as the gradual weakening of the Sardaukar, the deeply stratified society and the aristocratic obsession with vendetta). A lack of invention could just be another such sign.
Little? Perl? Surely you jest. And speaking of standard... exactly where is it installed, *standardly*? (This actually is important: if I want to set up a cron job on a large network of machines I don't admin, for instance.) In the same vein: perl has very little in the way of version-independent documentation; the set of standard modules changes too frequently.
Literal translations are rarely very interesting or insightful: see Bernard Shaw's preface to "Man and Superman" for why he believed "Superman" is the better translation.
The analogy I think of is speeding tickets. If cops really wanted to slow traffic down, they could stop their cars in a conspicuous location that everyone would see. Instead, they conceal themselves and catch people in speed traps, because their real objective is to raise money.
This is not in fact the most effective method: you (the police) are then limited by the number of cars they have, which is usually less than the number of streets they need to watch. By hiding, they spread the uncertainty out: every road carries nonzero risk of getting caught, which effectively reduces the total amount of speeding.
The analogy is a very good one, though: the threat of this software being installed on your computer is probably a more effective deterrant to your misuse than any actual monitoring.
This is entirely offset however, by certain operating systems which require about half a gig to install comfortably. Moores law should not be used as a crutch or excuse for sloppy coding. I sincerely doubt that there is a single piece of microsoft software out there that could not be made in half the size with twice the speed.
Quite unprovable; I'm not convinced that MS programmers are either sloppy or stupid.
If Microsoft had some intelligence and foresight, they would have designed a half decent filesystem. Then they wouldn't have to worry about the conversion between FAT and FAT32. Hmm. Is it elegance when they make kludges to patch up bad decisions? Hmmm . . .
If the Linux programmers had some intelligence and foresight, they would have designed a half decent filesystem and not have had to worry about ext/ext2. Repeat the above for a.out/elf, or the glibc compatibility nightmare.
HTML mail?!??? What in the hell are you guys smoking? The only thing as annoying as html mail is html newsgroup posts. GAAARGGH!! SLAP!!! *BONK* HISSS!!!! Cool features my ass. Why can't people stick to ASCII and attachments? Sigh.
Standards evolve when vendors provide more features; this is normal and healthy, and the way the industry is supposed to work. HTML mail is good because it's a simple, portable, non-patented extension; in contrast, Word document attachments are evil because they're complicated, non-portable and proprietary. Given that people actually *want* more structure to their mail than ASCII can provide, this is a natural direction for the industry to take. (Remember that we can't (and shouldn't) standardise before we have implementation experience!)
Most people don't use even a hundred of the gazzilion word features. Few people even used the spiffy label editor that comes with it. So why package it all into one blob? Keep it as seperate components and let users install precisely what they need.
Most people don't know, at install time, which set of features they'll need; their requirements do change over time. Besides, would you really want to spend hours figuring out which of the thousand features you want, specially when the resource you seem to be optimising for (disk/memory space?) is in fact quite plentiful? (A gigabyte of disk is worth ~$30; how many man-hours is that worth?)
I like "codewright": I've been describing myself that way for a while now, and most people do seem to get it...
Re:Excuse my ignorance but...
on
UK Linux Conf
·
· Score: 1
I wasn't aware of NTFS doing this, but is it really possible to do useful (read non-trivial) things with OS-maintained metadata? I'm concerned about semantic differences between
cp filea fileb
mv filea fileb
cat filea >fileb
cat filea filec >fileb
cat filea >>fileb
Given the prevalence of shell scripts in Unix systems, sloppy semantics could easily lead to a debugging nightmare...
Slashdot Mirror
But what would your comment say? For instance, would you indicate in your comment that this code will *not* properly handle HTML comments or Javascript content?
IMO, this is the evilness of perl: it leads you on to think that the trivial hack is actually a correct solution.
I think this may have been deliberate: one of the (subplots? themes? ideas?) in the book was that humanity had stagnated. Forty thousand years of peace and stability have made the race settled and complacent; there are signs of this elsewhere (such as the gradual weakening of the Sardaukar, the deeply stratified society and the aristocratic obsession with vendetta). A lack of invention could just be another such sign.
(*a)(b, c, d);
Grep that!
insert into some_table rand()
For heterogeneous backends, a query that succeeds on one but fails on another (because of, e.g., VARCHAR/BLOB/INTEGER size limits).
Failures due to other reasons than a machine going down (such as a bad disk sector).
Little? Perl? Surely you jest. And speaking of standard ... exactly where is it installed, *standardly*? (This actually is important: if I want to set up a cron job on a large network of machines I don't admin, for instance.) In the same vein: perl has very little in the way of version-independent documentation; the set of standard modules changes too frequently.
Literal translations are rarely very interesting or insightful: see Bernard Shaw's preface to "Man and Superman" for why he believed "Superman" is the better translation.
This is not in fact the most effective method: you (the police) are then limited by the number of cars they have, which is usually less than the number of streets they need to watch. By hiding, they spread the uncertainty out: every road carries nonzero risk of getting caught, which effectively reduces the total amount of speeding.
The analogy is a very good one, though: the threat of this software being installed on your computer is probably a more effective deterrant to your misuse than any actual monitoring.
Quite unprovable; I'm not convinced that MS programmers are either sloppy or stupid.
If Microsoft had some intelligence and foresight, they would have designed a half decent filesystem. Then they wouldn't have to worry about the conversion between FAT and FAT32. Hmm. Is it elegance when they make kludges to patch up bad decisions? Hmmm . . .
If the Linux programmers had some intelligence and foresight, they would have designed a half decent filesystem and not have had to worry about ext/ext2. Repeat the above for a.out/elf, or the glibc compatibility nightmare.
HTML mail?!??? What in the hell are you guys smoking? The only thing as annoying as html mail is html newsgroup posts. GAAARGGH!! SLAP!!! *BONK* HISSS!!!! Cool features my ass. Why can't people stick to ASCII and attachments? Sigh.
Standards evolve when vendors provide more features; this is normal and healthy, and the way the industry is supposed to work. HTML mail is good because it's a simple, portable, non-patented extension; in contrast, Word document attachments are evil because they're complicated, non-portable and proprietary. Given that people actually *want* more structure to their mail than ASCII can provide, this is a natural direction for the industry to take. (Remember that we can't (and shouldn't) standardise before we have implementation experience!)
Most people don't use even a hundred of the gazzilion word features. Few people even used the spiffy label editor that comes with it. So why package it all into one blob? Keep it as seperate components and let users install precisely what they need.
Most people don't know, at install time, which set of features they'll need; their requirements do change over time. Besides, would you really want to spend hours figuring out which of the thousand features you want, specially when the resource you seem to be optimising for (disk/memory space?) is in fact quite plentiful? (A gigabyte of disk is worth ~$30; how many man-hours is that worth?)
I like "codewright": I've been describing myself that way for a while now, and most people do seem to get it ...
Given the prevalence of shell scripts in Unix systems, sloppy semantics could easily lead to a debugging nightmare ...
Or understands sendmail well enough to redirect mail to root --- which isn't really all that hard.