> It sounds rather neat, I may have to go start reading the books.
You want to be a bit careful about getting started with Tad Williams books, because they tend to be rather lengthy, and when you get to the end of each book in a series, it feels just like a chapter break, and the story isn't really resolved at all until you get to the end of the *last* book.
Don't get me wrong, they're great books. You do want to read them, because they're interesting. Lots of good characters, lots of interesting stuff going on, stuff you don't fully understand at first and have to figure out along with the characters... well worth reading.
But you don't want to start in unless you can be pretty sure you're going to have some free time each day for the next several months, because reading a Tad Williams series has a tendency to take over your life for a while. At least with the Otherland series you don't have to keep track of a stack of maps like you do with The Dragonbone Chair.
Exactly. The Inner District had rules that mostly mimicked the real world, except that people's avatars could look weird. Treehouse had a different set of rules, but it still had rules (and, IIRC, if your avatar _didn't_ look weird, people tried to help you design a weirder one). Then there's Otherland itself, which had perhaps the strictest rules of all in its own way, since each section of it was designed around one person's vision (and a disturbingly high percentage of them seemed to be designed around Jongleur's vision in particular).
No, I like when the ISV passes the buck to the hardware manufacturer, who passes it on to the OS vendor, who passes it back to the ISV, who insists that they've never seen this problem in their software and it must be a hardware glitch, but the hardware manufacturer, after coming out to have a look at it, assures us that the hardware is working correctly and it must be an operating system problem, but the OS vendor tells us that it's a third-party software issue and we should contact the software vendor. Yeah, that little setup gets the problem solved *real* fast.
> "Can open source apps paste spreadsheet cells into an email?"
The follow-up question here is, "Supposing it does, how on earth will the recipient's email software know what to do with the resulting deformed and invalid message?"
I once came *this close* to coding up a set of hooks for Emacs to combine AUCTeX and Gnus into a mail/news client that send messages in TeX format, and can display said messages as they are intended to look, just to demonstrate the principle of message format standardization to some clown on usenet who was advocating some non-slarkish rich text format or another for newsgroup messages. ("What, can't your lame newsreader read my beautifully formatted messages? Mine can, see? [screenshot] Maybe you should get a better newsreader, one that supports TeX messages, and then you can join the modern world, haha!")
> Remember this isn't just one group of people with a lot of money. It's one group of > people with a lot of money who will also make a lot of money for a lot of other people
On top of that, the Olympics also has a very positive (one could almost say grandiose) public image among the general population. Any politician who is questioned about voting for something like this just has to talk about the spirit of the Olympics and international cooperation and competition and whatnot, and he'll be off the hook with most of the electorate in nothing flat.
> they have muscled around 'smaller' countries, but I would think that Canada wouldn't be so easily swayed.
I'm not sure size is really relevant, but...
Canada takes up a large chunk of land area on the map, but in other respects it is not as large as the square footage seems to imply. They have a smaller population than Colombia, for instance, and a smaller total GDP than Mexico.
Basically, the northern two-thirds of the country has roughly the same population density as the moon.
> I DO believe that the resentment is misplaced, as it's merely "jokers"
Actually, at one time there were people in the US who seriously considered annexing Canada, possibly even by force if necessary. However, that was a while ago. Benedict Arnold was involved with it, and as you may know he later betrayed us in a treasonous fashion and became perhaps the most infamous name in US history, a name still used as a synonym for traitor. I don't think anyone has taken the notion seriously since his day.
On the other hand, it's also true that while most people from the US think of Canada as "another country", a lot of us don't really think of Canada when we think of a *foreign* country. For instance, a conversation like this is not unusual:
Alice: Have you ever been to a foreign country? Bob: Yeah, actually I have. Alice: Really? Where? Bob: My dad and I went up to Ontario on a fishing trip three years ago... Alice: That's just Canada. That doesn't count!
I think a combination of several factors is at work here.
In the first place, Canada isn't overseas. Everyone knows foreign countries are overseas. (Mexico is foreign despite this, but Mexico is fairly third-world and also fails the other criteria below.)
In the second place, the cultural differences are, in a word, minor. (The biggest one I can think of off the top of my head is that Canadians are comfortable paying absolutely insane amounts of sales tax. Granted, people here have trouble *identifying* with that, but on the other hand it doesn't make you seem incomprehensibly alien, just... complacent. Oh, and your paper money looks weird, but this is becoming less and less of a big deal every time the US Treasury experiments more and more with stranger and stranger designs on our own money. First the enormous portraits, and did you know they're using colors besides green now? What do they think we are, the Republic of Milton Bradley? You get used to that, and Canadian money hardly even seems weird any more.)
Third, most Canadians speak English, with barely even an accent. Discounting the word "eh" and a few Commonwealth-style spellings, you practically speak *American* English. This by itself probably wouldn't by a very big deal, but in combination with the other factors it all starts to add up.
Also, you don't need a passport to go to Canada. You need one (and probably a visa as well) to go to any other country, including Mexico, but you can go to Canada for the weekend and just show your driver's license or birth certificate or something when you cross the border, no big deal.
Finally, there's no significant international tension between the US and Canada. Strong evidence of this is the fact that Canada would easily be capable of creating nuclear weapons but pointedly does not do so, even though (and perhaps partly because) we have them. When there's tension across the border, you see the opposite pattern. When the USSR got the atom bomb, China wanted it; when China got it, India needed it, and when India got it, Pakistan felt they needed it. But you never saw Canada going, "Oh, no, the US has this terrible weapon, what are we going to do? We have to have it too, so they can't use it on us!" But between the US and Canada there's no real tension, so the Canadian government has never been afraid that we're going to nuke them. (Indeed, using a nuke that close to US soil is absolutely unthinkable for us, even if it wouldn't start WWIII, which it might do.)
It's poker. Therefore, somebody was cheating, or at least trying to cheat. QED.
Where there's poker, there's always cheating. Sometimes it's not very sophisticated (e.g., table talk of the "I have the card he wants you to think he's got" variety), and sometimes it's more involved, but there's always cheating. Cheaters are drawn to poker like insects to electric lights.
> Not sure what the deal was on the IBM side but I'd guess simular.
Assuming FAT12, you just mark it as used in the allocation table but don't make any directory entry point to it. As long as nobody runs filesystem-checking software on it (along the lines of scandisk, but scandisk itself didn't exist back then, so it'd be a third-party utility), there shouldn't be a problem. And a game disk is probably meant to be read-only, in which case nobody has any business running filesystem checks on it.
This is assuming that the two formats don't both need certain specific sectors. In the case of FAT12, I *think* certain things have to go at the beginning of the disk (low-numbered sectors), but it's been a good while since I did any significant low-level filesystem fiddling, so I could be remembering that kind of detail incorrectly.
> The article also shows that among famous programmers, the ratio of > males to females is much larger than among normal programmers
You know, I never thought about this before, but off the top of my head I'm having a hard time thinking of *any* famous female programmers, unless you count Audrey Tang (who isn't technically female, in the strictest biological sense, and wasn't even making pretensions of being female in any sense at all when he became a famous programmer) or Mitchell Baker, who, although she's famous in conjunction with a programming project, is not, as far as I'm aware, actually a programmer herself. I'm sure I'm probably missing someone, perhaps even someone really obvious, but, honestly, I'm racking my brain here, and I'm coming up blank. I know of several female programmers, but none of them are especially famous outside a specific application space. There are a couple who are well-known in the interactive fiction community, for instance, but nobody who doesn't follow IF knows about them. There's a female programmer or three who's fairly well-known in the Perl community, but nobody who doesn't use Perl has ever heard of them.
Wait, I've been thinking of *current* famous programmers. Wasn't one of the very early third-generation programming languages designed by a woman? I can't remember which language, though...
> There's an add-on for firefox that adds emacs keybindings to firefox.
Except, it doesn't actually add Emacs functionality, so it's kind of worthless. Nobody uses Emacs for its default keybindings. (Indeed, a lot of us have made significant alterations to the key bindings in Emacs.) We use Emacs because we need software that does certain things, and the only choices are Gnu Emacs and XEmacs. Nothing else has the needed functionality.
> The idea is that if you pass a suspension of rigid spheres through a magnetic or electric > field, the viscosity of the liquid changes. (BTW, I have no idea what that means, just > trying to paraphrase from the abstract -- hope I got it right;-) )
I do know what it means, and they may as well say the device routes an inverse tachyon pulse through the vehicle's lateral sensor array to cut through the interference created by the turbulence of the atmosphere and allow the inertial dampers to operate at full efficiency.
> it just doesn't have any statistical rigor to back up their claims. They've got pretty > pictures and charts, but I don't see any good numbers to tell me exactly what I'm looking at.
That's because the whole thing is a big steaming heap of marketing.
> However, I don't see anything particularly wrong either.
You may not see it, but it's there.
> Their method is simple and should be easy to reproduce. > So maybe we'll get another group confirming their findings.
> 60+ posts all yelling snake oil, all from people clearly with little or no engine experience.
Maybe they don't have "engine experience" in the sense of being mechanics, but they are nevertheless absolutely correct in their assessment. The mechanism of action is implausible if you know any chemistry or physics whatsoever, and furthermore the inefficiency that the device ostensibly corrects (a full sixth of the fuel going uncombusted under normal vehicle operation) does not exist in the first place for any vehicle in reasonably good condition. The whole thing is a big steaming pile of marketing.
Yeah, my family had one, a 1987 Plymouth Horizon. It also had the punchiest acceleration of any car we ever owned. Getting on the freeway with that thing was a snap. If you put it in third gear, it would go from ramp speed (20mph or so) to 65 in two or three seconds. I actually liked driving that car, something I can't say for any vehicle we've had since.
However, the reason newer cars aren't more fuel efficient isn't because the fuel isn't fully combusted, as this phony product claims. There are a number of reasons, perhaps the largest being the increased emphasis on safety ratings, which has led to vehicles with a considerably larger mass.
For the device in question to work as the article summary describes, the car in its natural state would have to leave 16+% of its fuel uncombusted, meaning that for every gallon of gas you put into your car, you'd be sending two-thirds of a quart of petroleum product straight into the environment. (Yes, I know, "uncombusted" does not *necessarily* imply "straight into the exhaust uncombusted", but whatever winds up in the muffler or someplace and then the junkyard is still ultimately going into the environment.) The EPA would have a big hairy conniption fit and give birth to a full-grown Holstein if even *one* model of vehicle were put on the market with that property, let alone most/all of them as the article implies.
And then there's the fact that the mechanism whereby this device supposedly improves combustion efficiency sounds plausible only if you don't know any chemistry.
This device is in the same category as those stickers you can get to put on your batteries to improve battery life and the bracelets you can get that improve your circulation.
Statistics will admit to anything if you torture them enough, and this guy's gone out of his way in that department.
Just for example, have a look at his evaluation of the 1988 election. Less than 2%, he says. We are talking here about an election that was an extremely clear landslide. Okay, so it wasn't quite the epic skunking of '84, but it wasn't anywhere near close, either. Less than 2%, he says, but that's if you can cherry-pick the *specific* half-a-million-plus votes you want to change. At that point you might just about as well rearrange the districts until they all look like salamanders. Note too that in some cases he's changing the outcome in states that could have been called with a high degree of confidence *months* before the election, e.g., Montana. Sure, that's only 10739 votes, but what would it have taken for Dukakis to actually *get* those 10739 more votes in Montana? Note that that's not 10739 more people coming out to vote for him; that's 10739 people who voted for Bush changing their mind and going for Dukakis instead. In Montana, in 1988. Yeah, *that* could've happened, maybe, in some alternate universe where everyone wears a goatee. I remind you, in 1988 the iron curtain had not come down yet, and Reagan was *fantastically* popular even in the moderate states; in the conservative rural states he almost may as well have been the second coming of Abraham Lincoln. Bush made sure to be seen in public with Reagan a lot that year (go figure; funny how McCain hasn't been seen in public so much with his son). Sure, 10739 isn't very many votes. But the voters in some of those states *knew* where their states' electoral votes were going, and the turnout reflects that; if it had been a closer race, turnout would have been higher.
Even the 1984 election, which is about as decisive as a blowout can ever get in a country with actual free elections and more than one candidate, comes in at less than 7% in his reckoning. That ought to tell you something about how his numbers are constructed. I live in a major swing state and have only ever met one person who admitted to having voted the other way in that one.
> As far as I know, DHTML requires a client-side scripting language
My understanding has always been that DHTML *is* HTML with client-side scripting, by definition.
Well, okay, I suppose these days you could make a web page somewhat dynamic with CSS (using things like:hover), but at the time the term "DHTML" was coined that wasn't possible, so I'm not sure if it counts as DHTML.
> the most popular of which (only?) is JavaScript.
Javascript is the most common name for the only one that's even vaguely popular, which is also the only one implemented in more than one browser[1]. I'm not sure whether it's the only one enabled by default in a major browser, since I'm not sure at this point whether IE has VBScript enabled by default out of the box. (I mainly just use IE to test my own websites for IE compatibility, so I haven't kept up on all of its non-standard features.)
[1] Technically, the word "browser" here should probably be some more complicated term or phrase, along the lines of "vendor's browser framework" or whatnot, to account for the fact that the bulk of IE can be rebranded and/or embedded in a different UI to make things like MSN Explorer and Maxthon.
Yeah, if you'd kept reading, you'd have noticed that they also said at least three times that it didn't require Javascript, and then went on to explain that it requires DHTML and can be done with "browser scripting" instead of Javascript.
Here are some things that I consider to be inviolable rules for programming...
1. Never EVER design a user-interface around what you already know how to program. Design how the UI is supposed to work, and then learn whatever programming you need to learn to make it work that way. This is an inviolable rule as far as I'm concerned. Getting this wrong is how you end up with nightmarishly bad interfaces, like unresizeable dialog boxes too small to contain the information you put in them. Don't do stuff like that. Ever.
2. Don't hardcode numbers, unless they are physically incapable of being changed (e.g., pi).
3. If the application is going to be distributed outside the company, you probably don't want to hardcode strings (that the user will see), either. Some strings are for internal use by the application itself (e.g., part of a file format), or for communicating with other software (e.g., part of a protocol); those you can probably hardcode. Also, the "can't find configuration file" error message string will have to be hardcoded.
4. Error messages should start with an oversimplified end-user-oriented headline, consisting of 2-4 non-technical words, and the headline should be *unique* to that specific error message, because it's the only thing the user is going to remember and report when there's a problem. Including some technical detail may also be appropriate, depending on the situation, but you can't count on users to report the technical details back to you in bug reports, so make sure the friendly headline uniquely identifies the specific error.
5. It is *theoretically* possible to write too many sanity checks and send too much information to the log file, but as a beginning programmer, you are certainly going to err in the other direction, guaranteed. For now, it's best to assume that more sanity checks and more logfile entries are automatically better. When you reach the point where you have to start rethinking that and cutting back, it will be a milestone in your programming career.
6. Comments should tell *why* the code does a certain thing. Don't comment on what it does. That's redundant. Any competent programmer can tell *what* the code does, just by reading it. But the reasoning behind it may not be apparent even to you, when you look back at your old code in a few months, let alone to someone else. Explain _why_ in the comments.
7. Don't hardcode filenames or paths, ever. Even the config file location should be possible to override in some fashion (e.g., via command line argument or environment variable).
8. It is *theoretically* possible to make an application too configurable, but I am not aware of a single documented case of this actually happening in the entire history of computing. If you aren't sure whether anyone will want to change a certain thing, it's best to assume that someone will want to change it for some reason.
9. Options are for advanced users; default settings are for end users. Don't let end users tell you what should or shouldn't be configurable, and on the other hand don't let more advanced users tell you what the default settings should be. If the advanced users want something different from the default behavior, they'll be competent enough to change the settings. Design the defaults around end users, so they don't *have* to change any settings. Also note that you may want to create a UI for some of the simplest options, but it's okay to let more advanced users edit the config file for the more esoteric stuff, especially if the config file has comments explaining what the options do.
10. Don't get caught up in theoretical purisms. Sometimes the object-oriented approach is best, but sometimes a more functional approach works better. A good programmer chooses the approach that fits the problem at hand.
GIF has kind of lost its relevance since people started taking 24-bit color for granted.
Besides, it doesn't really matter what image format Paint supports. Nobody's using it for actual image editing work. (People who do that install real image-editing software, generally something that supports layers.) Paint exists so that people who *don't* do image editing (children, especially) can nonetheless fulfill the occasional irresistable urge to draw something.
WordPad is kind of similar. If you think of it as a word processing tool, it would be well worth getting rid of, but the thing is, sometimes people don't actually need a real word processor and don't want to bother to install one, but they still occasionally need to print up a wet paint sign, or the adorable little four-year-old wants to write a letter to grandma, or whatever. So it's nice that Windows comes with *something*, even though it's not something you'd ever use for serious work.
Slashdot Mirror
> It sounds rather neat, I may have to go start reading the books.
You want to be a bit careful about getting started with Tad Williams books, because they tend to be rather lengthy, and when you get to the end of each book in a series, it feels just like a chapter break, and the story isn't really resolved at all until you get to the end of the *last* book.
Don't get me wrong, they're great books. You do want to read them, because they're interesting. Lots of good characters, lots of interesting stuff going on, stuff you don't fully understand at first and have to figure out along with the characters... well worth reading.
But you don't want to start in unless you can be pretty sure you're going to have some free time each day for the next several months, because reading a Tad Williams series has a tendency to take over your life for a while. At least with the Otherland series you don't have to keep track of a stack of maps like you do with The Dragonbone Chair.
Exactly. The Inner District had rules that mostly mimicked the real world, except that people's avatars could look weird. Treehouse had a different set of rules, but it still had rules (and, IIRC, if your avatar _didn't_ look weird, people tried to help you design a weirder one). Then there's Otherland itself, which had perhaps the strictest rules of all in its own way, since each section of it was designed around one person's vision (and a disturbingly high percentage of them seemed to be designed around Jongleur's vision in particular).
I don't know, I think it could be pretty compelling without that, if you have the flak.
Personally I'm planning to get a telematic jack for my neurocannulum, so I can play even when I'm not at home!
My favourite quote from this series: "It is amazing how much distraction you can cause when you give a torch to a troop of flying monkeys."
No, I like when the ISV passes the buck to the hardware manufacturer, who passes it on to the OS vendor, who passes it back to the ISV, who insists that they've never seen this problem in their software and it must be a hardware glitch, but the hardware manufacturer, after coming out to have a look at it, assures us that the hardware is working correctly and it must be an operating system problem, but the OS vendor tells us that it's a third-party software issue and we should contact the software vendor. Yeah, that little setup gets the problem solved *real* fast.
> "Can open source apps paste spreadsheet cells into an email?"
The follow-up question here is, "Supposing it does, how on earth will the recipient's email software know what to do with the resulting deformed and invalid message?"
I once came *this close* to coding up a set of hooks for Emacs to combine AUCTeX and Gnus into a mail/news client that send messages in TeX format, and can display said messages as they are intended to look, just to demonstrate the principle of message format standardization to some clown on usenet who was advocating some non-slarkish rich text format or another for newsgroup messages. ("What, can't your lame newsreader read my beautifully formatted messages? Mine can, see? [screenshot] Maybe you should get a better newsreader, one that supports TeX messages, and then you can join the modern world, haha!")
> Remember this isn't just one group of people with a lot of money. It's one group of
> people with a lot of money who will also make a lot of money for a lot of other people
On top of that, the Olympics also has a very positive (one could almost say grandiose) public image among the general population. Any politician who is questioned about voting for something like this just has to talk about the spirit of the Olympics and international cooperation and competition and whatnot, and he'll be off the hook with most of the electorate in nothing flat.
> they have muscled around 'smaller' countries, but I would think that Canada wouldn't be so easily swayed.
I'm not sure size is really relevant, but...
Canada takes up a large chunk of land area on the map, but in other respects it is not as large as the square footage seems to imply. They have a smaller population than Colombia, for instance, and a smaller total GDP than Mexico.
Basically, the northern two-thirds of the country has roughly the same population density as the moon.
> But it might be wise to learn to say that in French ... "Vive le Québec", not "viva"
French, Spanish, what's the difference, eh?
> I DO believe that the resentment is misplaced, as it's merely "jokers"
Actually, at one time there were people in the US who seriously considered annexing Canada, possibly even by force if necessary. However, that was a while ago. Benedict Arnold was involved with it, and as you may know he later betrayed us in a treasonous fashion and became perhaps the most infamous name in US history, a name still used as a synonym for traitor. I don't think anyone has taken the notion seriously since his day.
On the other hand, it's also true that while most people from the US think of Canada as "another country", a lot of us don't really think of Canada when we think of a *foreign* country. For instance, a conversation like this is not unusual:
Alice: Have you ever been to a foreign country?
Bob: Yeah, actually I have.
Alice: Really? Where?
Bob: My dad and I went up to Ontario on a fishing trip three years ago...
Alice: That's just Canada. That doesn't count!
I think a combination of several factors is at work here.
In the first place, Canada isn't overseas. Everyone knows foreign countries are overseas. (Mexico is foreign despite this, but Mexico is fairly third-world and also fails the other criteria below.)
In the second place, the cultural differences are, in a word, minor. (The biggest one I can think of off the top of my head is that Canadians are comfortable paying absolutely insane amounts of sales tax. Granted, people here have trouble *identifying* with that, but on the other hand it doesn't make you seem incomprehensibly alien, just... complacent. Oh, and your paper money looks weird, but this is becoming less and less of a big deal every time the US Treasury experiments more and more with stranger and stranger designs on our own money. First the enormous portraits, and did you know they're using colors besides green now? What do they think we are, the Republic of Milton Bradley? You get used to that, and Canadian money hardly even seems weird any more.)
Third, most Canadians speak English, with barely even an accent. Discounting the word "eh" and a few Commonwealth-style spellings, you practically speak *American* English. This by itself probably wouldn't by a very big deal, but in combination with the other factors it all starts to add up.
Also, you don't need a passport to go to Canada. You need one (and probably a visa as well) to go to any other country, including Mexico, but you can go to Canada for the weekend and just show your driver's license or birth certificate or something when you cross the border, no big deal.
Finally, there's no significant international tension between the US and Canada. Strong evidence of this is the fact that Canada would easily be capable of creating nuclear weapons but pointedly does not do so, even though (and perhaps partly because) we have them. When there's tension across the border, you see the opposite pattern. When the USSR got the atom bomb, China wanted it; when China got it, India needed it, and when India got it, Pakistan felt they needed it. But you never saw Canada going, "Oh, no, the US has this terrible weapon, what are we going to do? We have to have it too, so they can't use it on us!" But between the US and Canada there's no real tension, so the Canadian government has never been afraid that we're going to nuke them. (Indeed, using a nuke that close to US soil is absolutely unthinkable for us, even if it wouldn't start WWIII, which it might do.)
Yeah, but there's an easier way to know.
It's poker. Therefore, somebody was cheating, or at least trying to cheat. QED.
Where there's poker, there's always cheating. Sometimes it's not very sophisticated (e.g., table talk of the "I have the card he wants you to think he's got" variety), and sometimes it's more involved, but there's always cheating. Cheaters are drawn to poker like insects to electric lights.
> You kid, but the stock market is actually worse than gambling.
Only in the short term (less than ten years), or if your portfolio has no diversity.
> At least when you gamble you know what your odds are.
Only if you can know that nobody's cheating. If there's any cheating going on, that plays havoc with the odds.
> Not sure what the deal was on the IBM side but I'd guess simular.
Assuming FAT12, you just mark it as used in the allocation table but don't make any directory entry point to it. As long as nobody runs filesystem-checking software on it (along the lines of scandisk, but scandisk itself didn't exist back then, so it'd be a third-party utility), there shouldn't be a problem. And a game disk is probably meant to be read-only, in which case nobody has any business running filesystem checks on it.
This is assuming that the two formats don't both need certain specific sectors. In the case of FAT12, I *think* certain things have to go at the beginning of the disk (low-numbered sectors), but it's been a good while since I did any significant low-level filesystem fiddling, so I could be remembering that kind of detail incorrectly.
You had sheepskins?
> The article also shows that among famous programmers, the ratio of
> males to females is much larger than among normal programmers
You know, I never thought about this before, but off the top of my head I'm having a hard time thinking of *any* famous female programmers, unless you count Audrey Tang (who isn't technically female, in the strictest biological sense, and wasn't even making pretensions of being female in any sense at all when he became a famous programmer) or Mitchell Baker, who, although she's famous in conjunction with a programming project, is not, as far as I'm aware, actually a programmer herself. I'm sure I'm probably missing someone, perhaps even someone really obvious, but, honestly, I'm racking my brain here, and I'm coming up blank. I know of several female programmers, but none of them are especially famous outside a specific application space. There are a couple who are well-known in the interactive fiction community, for instance, but nobody who doesn't follow IF knows about them. There's a female programmer or three who's fairly well-known in the Perl community, but nobody who doesn't use Perl has ever heard of them.
Wait, I've been thinking of *current* famous programmers. Wasn't one of the very early third-generation programming languages designed by a woman? I can't remember which language, though...
> There's an add-on for firefox that adds emacs keybindings to firefox.
Except, it doesn't actually add Emacs functionality, so it's kind of worthless. Nobody uses Emacs for its default keybindings. (Indeed, a lot of us have made significant alterations to the key bindings in Emacs.) We use Emacs because we need software that does certain things, and the only choices are Gnu Emacs and XEmacs. Nothing else has the needed functionality.
> The idea is that if you pass a suspension of rigid spheres through a magnetic or electric ;-) )
> field, the viscosity of the liquid changes. (BTW, I have no idea what that means, just
> trying to paraphrase from the abstract -- hope I got it right
I do know what it means, and they may as well say the device routes an inverse tachyon pulse through the vehicle's lateral sensor array to cut through the interference created by the turbulence of the atmosphere and allow the inertial dampers to operate at full efficiency.
> it just doesn't have any statistical rigor to back up their claims. They've got pretty
> pictures and charts, but I don't see any good numbers to tell me exactly what I'm looking at.
That's because the whole thing is a big steaming heap of marketing.
> However, I don't see anything particularly wrong either.
You may not see it, but it's there.
> Their method is simple and should be easy to reproduce.
> So maybe we'll get another group confirming their findings.
Good luck with that.
> 60+ posts all yelling snake oil, all from people clearly with little or no engine experience.
Maybe they don't have "engine experience" in the sense of being mechanics, but they are nevertheless absolutely correct in their assessment. The mechanism of action is implausible if you know any chemistry or physics whatsoever, and furthermore the inefficiency that the device ostensibly corrects (a full sixth of the fuel going uncombusted under normal vehicle operation) does not exist in the first place for any vehicle in reasonably good condition. The whole thing is a big steaming pile of marketing.
> I do not know the credibility of the publication.
I can deduce the credibility of the publication from the fact that they published this article.
Yeah, my family had one, a 1987 Plymouth Horizon. It also had the punchiest acceleration of any car we ever owned. Getting on the freeway with that thing was a snap. If you put it in third gear, it would go from ramp speed (20mph or so) to 65 in two or three seconds. I actually liked driving that car, something I can't say for any vehicle we've had since.
However, the reason newer cars aren't more fuel efficient isn't because the fuel isn't fully combusted, as this phony product claims. There are a number of reasons, perhaps the largest being the increased emphasis on safety ratings, which has led to vehicles with a considerably larger mass.
For the device in question to work as the article summary describes, the car in its natural state would have to leave 16+% of its fuel uncombusted, meaning that for every gallon of gas you put into your car, you'd be sending two-thirds of a quart of petroleum product straight into the environment. (Yes, I know, "uncombusted" does not *necessarily* imply "straight into the exhaust uncombusted", but whatever winds up in the muffler or someplace and then the junkyard is still ultimately going into the environment.) The EPA would have a big hairy conniption fit and give birth to a full-grown Holstein if even *one* model of vehicle were put on the market with that property, let alone most/all of them as the article implies.
And then there's the fact that the mechanism whereby this device supposedly improves combustion efficiency sounds plausible only if you don't know any chemistry.
This device is in the same category as those stickers you can get to put on your batteries to improve battery life and the bracelets you can get that improve your circulation.
Statistics will admit to anything if you torture them enough, and this guy's gone out of his way in that department.
Just for example, have a look at his evaluation of the 1988 election. Less than 2%, he says. We are talking here about an election that was an extremely clear landslide. Okay, so it wasn't quite the epic skunking of '84, but it wasn't anywhere near close, either. Less than 2%, he says, but that's if you can cherry-pick the *specific* half-a-million-plus votes you want to change. At that point you might just about as well rearrange the districts until they all look like salamanders. Note too that in some cases he's changing the outcome in states that could have been called with a high degree of confidence *months* before the election, e.g., Montana. Sure, that's only 10739 votes, but what would it have taken for Dukakis to actually *get* those 10739 more votes in Montana? Note that that's not 10739 more people coming out to vote for him; that's 10739 people who voted for Bush changing their mind and going for Dukakis instead. In Montana, in 1988. Yeah, *that* could've happened, maybe, in some alternate universe where everyone wears a goatee. I remind you, in 1988 the iron curtain had not come down yet, and Reagan was *fantastically* popular even in the moderate states; in the conservative rural states he almost may as well have been the second coming of Abraham Lincoln. Bush made sure to be seen in public with Reagan a lot that year (go figure; funny how McCain hasn't been seen in public so much with his son). Sure, 10739 isn't very many votes. But the voters in some of those states *knew* where their states' electoral votes were going, and the turnout reflects that; if it had been a closer race, turnout would have been higher.
Even the 1984 election, which is about as decisive as a blowout can ever get in a country with actual free elections and more than one candidate, comes in at less than 7% in his reckoning. That ought to tell you something about how his numbers are constructed. I live in a major swing state and have only ever met one person who admitted to having voted the other way in that one.
> As far as I know, DHTML requires a client-side scripting language
:hover), but at the time the term "DHTML" was coined that wasn't possible, so I'm not sure if it counts as DHTML.
My understanding has always been that DHTML *is* HTML with client-side scripting, by definition.
Well, okay, I suppose these days you could make a web page somewhat dynamic with CSS (using things like
> the most popular of which (only?) is JavaScript.
Javascript is the most common name for the only one that's even vaguely popular, which is also the only one implemented in more than one browser[1]. I'm not sure whether it's the only one enabled by default in a major browser, since I'm not sure at this point whether IE has VBScript enabled by default out of the box. (I mainly just use IE to test my own websites for IE compatibility, so I haven't kept up on all of its non-standard features.)
[1] Technically, the word "browser" here should probably be some more complicated term or phrase, along the lines of "vendor's browser framework" or whatnot, to account for the fact that the bulk of IE can be rebranded and/or embedded in a different UI to make things like MSN Explorer and Maxthon.
Yeah, if you'd kept reading, you'd have noticed that they also said at least three times that it didn't require Javascript, and then went on to explain that it requires DHTML and can be done with "browser scripting" instead of Javascript.
You young whippersnappers these days think you know everything. Haven't you ever seen a MUD?
Here are some things that I consider to be inviolable rules for programming...
1. Never EVER design a user-interface around what you already know how to program. Design how the UI is supposed to work, and then learn whatever programming you need to learn to make it work that way. This is an inviolable rule as far as I'm concerned. Getting this wrong is how you end up with nightmarishly bad interfaces, like unresizeable dialog boxes too small to contain the information you put in them. Don't do stuff like that. Ever.
2. Don't hardcode numbers, unless they are physically incapable of being changed (e.g., pi).
3. If the application is going to be distributed outside the company, you probably don't want to hardcode strings (that the user will see), either. Some strings are for internal use by the application itself (e.g., part of a file format), or for communicating with other software (e.g., part of a protocol); those you can probably hardcode. Also, the "can't find configuration file" error message string will have to be hardcoded.
4. Error messages should start with an oversimplified end-user-oriented headline, consisting of 2-4 non-technical words, and the headline should be *unique* to that specific error message, because it's the only thing the user is going to remember and report when there's a problem. Including some technical detail may also be appropriate, depending on the situation, but you can't count on users to report the technical details back to you in bug reports, so make sure the friendly headline uniquely identifies the specific error.
5. It is *theoretically* possible to write too many sanity checks and send too much information to the log file, but as a beginning programmer, you are certainly going to err in the other direction, guaranteed. For now, it's best to assume that more sanity checks and more logfile entries are automatically better. When you reach the point where you have to start rethinking that and cutting back, it will be a milestone in your programming career.
6. Comments should tell *why* the code does a certain thing. Don't comment on what it does. That's redundant. Any competent programmer can tell *what* the code does, just by reading it. But the reasoning behind it may not be apparent even to you, when you look back at your old code in a few months, let alone to someone else. Explain _why_ in the comments.
7. Don't hardcode filenames or paths, ever. Even the config file location should be possible to override in some fashion (e.g., via command line argument or environment variable).
8. It is *theoretically* possible to make an application too configurable, but I am not aware of a single documented case of this actually happening in the entire history of computing. If you aren't sure whether anyone will want to change a certain thing, it's best to assume that someone will want to change it for some reason.
9. Options are for advanced users; default settings are for end users. Don't let end users tell you what should or shouldn't be configurable, and on the other hand don't let more advanced users tell you what the default settings should be. If the advanced users want something different from the default behavior, they'll be competent enough to change the settings. Design the defaults around end users, so they don't *have* to change any settings. Also note that you may want to create a UI for some of the simplest options, but it's okay to let more advanced users edit the config file for the more esoteric stuff, especially if the config file has comments explaining what the options do.
10. Don't get caught up in theoretical purisms. Sometimes the object-oriented approach is best, but sometimes a more functional approach works better. A good programmer chooses the approach that fits the problem at hand.
GIF has kind of lost its relevance since people started taking 24-bit color for granted.
Besides, it doesn't really matter what image format Paint supports. Nobody's using it for actual image editing work. (People who do that install real image-editing software, generally something that supports layers.) Paint exists so that people who *don't* do image editing (children, especially) can nonetheless fulfill the occasional irresistable urge to draw something.
WordPad is kind of similar. If you think of it as a word processing tool, it would be well worth getting rid of, but the thing is, sometimes people don't actually need a real word processor and don't want to bother to install one, but they still occasionally need to print up a wet paint sign, or the adorable little four-year-old wants to write a letter to grandma, or whatever. So it's nice that Windows comes with *something*, even though it's not something you'd ever use for serious work.