The error pages are good place to put "cute" stuff that you don't want elsewhere on your site.
The 404 page at one of the MIT sites used to say something about having eaten the page you wanted, but offering the comment that it was "tart on my tongue" Came off sounding like William Carlos Williams.
The 404 pages at SGI used to feature pictures of babies, probably babies of employees. You got a different one, chosen at random from a pool of a dozen or so, on each 404 page.
Sadly, both these cute 404 pages seem to have been discontinued. At least I can't find them any more.
You try to make a little joke, but there is always some Poindexter out there who takes you literally and points out your "mistake" in mind-numbing detail...
The Louisiana band Better Than Ezra has a track at the end of their album "Deluxe" that includes a long period of silence. The track starts with the song "Coyote", which is followed by a very long silence, a minute or two, then there is what can only be described as a nonsense song which has the refrain "Der pork und beans mit saurkrauten". So why didn't John Cage's minions get upset over that - merely because it's not listed in the credits as a separate song?
The silence always fools me into thinking that the music is over - which is probably what it's meant to do, being at the end of the CD. It's especially confusing when I'm listening to a bunch of randomized mp3s; I hit that silence and "What, my playlist is over already?" If I'm coding or something, I just tolerate the silence, thinking I'll start some new tracks at the next compile. Then the "hidden" song starts, and I realize I've been fooled again.
The Cage estate should sue BTE and make them recall all those nasty hurtful fooling CDs. More lawyers! Litigation solves everything!
BTW, Tom Petty put a little CD-only track into the middle of his "Full Moon Fever" CD many years ago. It was a spoken bit, with the studio musicians in the background making barnyard noises, and Tom says "Hello CD listeners! We've come to the point in this album where those listening on record or cassette will have to stand up, or sit down and turn over the record or tape. In fairness to those listeners, we'll now take a few seconds before we begin side2... Thank you. Here's side2..."
"...saying that sofware written FOR Windows is usually lame is a bit fanatical."
No, that's simply my experience. I've found that WinDOZE software usually is lame, especially when it comes to TWAIN drivers. Of the seven or eight TWAIN drivers I've used over the years, the Nikon driver is the first to offer the ability to auto-number files according to a user-provided pattern. Hell, it's the first to even remember its settings from one use to the next. I have an HP flatbed scanner sitting on my desk. When I use my TWAIN driver, I have to click off the scan settings every time the driver comes up. It's a small thing, but it makes using the scanner more difficult than it needs to be. (And that's when it's not crashing or locking up the calling applicatien.) It's lame software.
My experience with general-purpose software is that Macintosh software is usually the easiest to use. It's a cliche, but it's true. Unix/linux software generally provides the klunkiest UIs, but almost always provides a way to drop down into script mode so I can program whatever is missing from the UI. That's why I use my HP flatbed scanner with linux and scanimage. Finally, I find that WinDOZE software generally is the most awkward to use because you're locked into the poor UI. Want to do something the UI designer hadn't thought of? Too bad, you're almost always out of luck.
Finding a TWAIN scanner driver that makes the job of scanning and archiving photos so easy was a startling experience. I expected the Nikon scanner driver to be pure crap, like most TWAIN drivers. It's not only better than most TWAIN drivers, it's also better than most winDOZE software. It's actually very impressive. But maybe I just have higher expectations than you do.
Oh, and I call it "Windoze" not to be clever, but to express my utter contempt for it. I don't give a shit what you think of that.
I thought the slide feeder was for the LS-4000 only. Not that it matters - after shelling out nearly $800 for the LS-40, I couldn't afford the slide scanner even if it would fit my model.
For scanning 35mm negatives, the Nikon Coolscan IV (LS-40) can auto-feed the entire negative strip. The Windoze driver software can auto-scan the entire strip, auto-save each scan, and auto-name the files with incremented numbers in the name. The driver can also remember numbers between strips so when you scan the next strip, the filenames take up where the last one left off. It makes scanning negatives as painless as possible. Unfortunately, if you're scanning slides, you have to hand-feed each one, but the driver software can still handle the auto-saving and auto-naming of each scan file.
For Windoze software, it's actually very impressive. Nikon's scanner was expensive, but unlike some slide scanners I've had (*cough* Minolta *cough*) the Coolscan lives up to my expectations.
That's "pass by value", while you were expecting "pass by reference".
Which reminds me of an old fortune cookie:
"Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-les Worth). Which is to say that Europeans call him by name, but Americans call him by value"
BTW, you can make PHP pass arguments by reference if you put an ampersand in front of the argument name.
The best way to learn is to have someone dump a PHP system on you before they leave. You learn quickly when people start hauling out promises that were never delivered or scream about devastating problems they ignored a month ago.
That's called Trial By Fire. It's taught at the School of Hard Knocks. In a couple of years, you'll look back on this and laugh... as the attendant wheels you out of your padded cell for your daily session with the Software Recovery group. Enjoy!
So while I'll agree on the point that you have to have some hands-on to master a language, I'll strenuously object to the idea that hands-on can replace a good book (or other training source).
I never said hands-on would replace books or even training classes. In fact, I believe I said several times that the hands-on needed to be accompanied by reference or tutorial material. But I don't think that books and training are the critical factors in learning a new language; I think real hands-on experience is.
Furthermore, I absolutely do not equate experimenting with a language to "trial-and-error". Just the opposite: in playing around with a language, once you know the basic control structures and syntax, I expect you to learn the language's strengths and weaknesses: how good is its object model (say), or its data structures, its exceptions, etc., etc. I expect you to test it, to put it through its paces. True, you can read about these things in the language reference, but until you actually put them into play, you don't get that deep visceral feel for how well they actually work in practice. In particular, I like to take difficult problems that I encountered in the past in other languages, and see how well the new language is set up to deal with the same problem: does it deal with it better, or worse? What are the tradeoffs? Clearly now we're way past "hello world", but as I said: you want to implement some nontrivial program of your own design.
Nor do reject the idea of learning from reading, be it "best practices" or "don't do this". That kind of material definitely has its place in the equation, but I don't think it becomes effective until you're reasonably fluent in a language, and especially until you've had the chance to transfer your own skills from other languages. I think you have to draw on all that you have available, but I don't think any of it is really effective unless you absorb it with a keyboard at your fingertips.
Finally, on the subject of becoming more than a good programmer, I'll say this: software is like painting: anybody can learn to slap paint onto a surface well enough to paint a barn. It's an essential skill, but if you want to move above painting barns and learn to paint something like the Mona Lisa, then you need to learn a whole additional set of skills. Good programming is relavitely easy; good software design is hard.
Learning how to design software, and learning how to implement a design by programming in a language are two different (but related) things. Software design skills tend to apply across broad swaths of languages, though of course design skills change depending on the language: designing for an object-oriented language is and should be different than designing for a non-OO language. (Though an OO language can be reduced to a non-OO language if you don't use it well; who was it that said "A good programmer can write FORTRAN in any language"?)
"Diving in" doesn't necessarily lead to horrible style and structure. A good disciplined programmer can dive into a new language and find ways to transfer his good coding skills to programming well in the new language. Good style is largely orthogonal to specific languages - likewise if you're a sloppy C programmer you'll probably also be a sloppy perl, PHP, or Python programmer.
My comment wasn't meant as a criticism - in fact what you said about the website doco was right on the mark. I learned PHP myself by downloading the HTML manual and reading it while I played with the language.
But whenever I see someone say something like "The best way to learn programming language Z is to..." it kind of sets me off. Of all the programmers I've known, the best ones always want to get their hands on the compiler first thing when learning a new language. And that's my personal experience too: it's all find and dandy to read something in a book, but deep learning, the kind that sinks in and stays, doesn't begin until I actually use the language.
And I'll say it again. The best way to learn php is through the php website.
I've said it before and I'll say it again: the best way to learn a language is by using it. Sit down at a computer with the manuals and start slinging code. You can't really learn a language by reading a book or going to a class. Real programmers learn by doing.
If you want to supplement your programming with a book or tutorial, fine, but keep your fingers on the keyboard. If you want to run sample programs, fine, but experiment and play with them. Change them, tweak them, go off on your own tangents. Better yet: throw out the tutorial as soon as you can write "hello world" and try to write some program of your own design. Keep the language and library references handy, because you'll need to refer to them often, but let your imagination and curiousity be your guide. Explore. Play. Learn. Real programmers learn by doing.
According to a report and interview on NPR All Things Considered this afternoon, it only took about an hour to discover the password. The hard part was finding a copy of the old DOS-based database software that was capable of opening the database.
The institute now keeps copies of all its passwords locked in a safe. Of course, if all its passwords are as bad as the lost password, then what's the point?
Really. Do us a favor, Taco & Co.: the next time someone writes in to say that he has a web server running on his ancient computer / handheld computer / kitchen appliance / Craftsman power tool / wife's electronic pleasure toy, please DON'T BOTHER to post it unless the submitter can reasonably claim that said device can handle the slashdot effect. Now, if they have a how-to / making-of site complete with story and pictures, on a server that can handle the load, now that's cool. But this assisted suicide of unusual web servers is just kind of pointless and perverse otherwise.
Why not Nichelle Nichols? After all, Uhura was the communications officer.
And if you want to talk about universal translators in sci-fi, Larry Niven's version was much better done in the Ringworld series. It didn't just magically make everyone speak English (or Interworld or whatever), it had limitations too: it had to listen to the foreign tongue for some time, to learn a minimal vocabulary, before it could begin communicating, which it did only haltingly at first. It sometimes couldn't translate words like <something> for which it had no context to deduce meaning. These limitations made for some interesting moments like the time Louis Wu had been captured by a woman who didn't talk much, and so he had to bide his time until the translator finally heard enough words to learn her language.
The bill you pay to the cable company is just to get the service to your house (unless you purchase HBO or something).
If by "something" you mean "anything other than the non-basic service, which in my neighborhood consists of nothing of value that I couldn't get via rabbit-ears" then I agree with you. But I have never, never, been satisfied with basic service. I always opt at least for the "expanded" service - just to get a few channels that I want, plus a lot of other crap that I don't, but the cable company doesn't make it possible for me to buy just the channels I want, so don't get me started on that soapbox - and don't tell me that I'm paying for infrastructure and getting a bunch of free service. I'm not.
I hardly think this sort of thing puts us on a slippery slope. If anything, there is *already* an epidemic problem of people being able to patent stupid and obvious things. This particular patent is just one snowflake in the storm
You miss the point. It's not the patent itself that's dangerous. What's dangerous is the idea of accepting silly software patents in order to do away with a relatively minor nuisance. If you're going to oppose software patents, then you need to be uniformly and consistently opposed to them, and resist the temptation to accept the convenient ones.
Slashdot Mirror
The fake moon landing: an analysis of "photographs" brought back from the "moon" show that the "landing" was faked. Read on:
NASA Fakes Moon Landing!
--Jim
The error pages are good place to put "cute" stuff that you don't want elsewhere on your site.
The 404 page at one of the MIT sites used to say something about having eaten the page you wanted, but offering the comment that it was "tart on my tongue" Came off sounding like William Carlos Williams.
The 404 pages at SGI used to feature pictures of babies, probably babies of employees. You got a different one, chosen at random from a pool of a dozen or so, on each 404 page.
Sadly, both these cute 404 pages seem to have been discontinued. At least I can't find them any more.
--Jim
You try to make a little joke, but there is always some Poindexter out there who takes you literally and points out your "mistake" in mind-numbing detail...
Hear, hear, well spoken Bruce!
--Jim, father of two
The Louisiana band Better Than Ezra has a track at the end of their album "Deluxe" that includes a long period of silence. The track starts with the song "Coyote", which is followed by a very long silence, a minute or two, then there is what can only be described as a nonsense song which has the refrain "Der pork und beans mit saurkrauten". So why didn't John Cage's minions get upset over that - merely because it's not listed in the credits as a separate song?
The silence always fools me into thinking that the music is over - which is probably what it's meant to do, being at the end of the CD. It's especially confusing when I'm listening to a bunch of randomized mp3s; I hit that silence and "What, my playlist is over already?" If I'm coding or something, I just tolerate the silence, thinking I'll start some new tracks at the next compile. Then the "hidden" song starts, and I realize I've been fooled again.
The Cage estate should sue BTE and make them recall all those nasty hurtful fooling CDs. More lawyers! Litigation solves everything!
BTW, Tom Petty put a little CD-only track into the middle of his "Full Moon Fever" CD many years ago. It was a spoken bit, with the studio musicians in the background making barnyard noises, and Tom says "Hello CD listeners! We've come to the point in this album where those listening on record or cassette will have to stand up, or sit down and turn over the record or tape. In fairness to those listeners, we'll now take a few seconds before we begin side2... Thank you. Here's side2..."
Am I offtopic yet?
--Jim
"...saying that sofware written FOR Windows is usually lame is a bit fanatical."
No, that's simply my experience. I've found that WinDOZE software usually is lame, especially when it comes to TWAIN drivers. Of the seven or eight TWAIN drivers I've used over the years, the Nikon driver is the first to offer the ability to auto-number files according to a user-provided pattern. Hell, it's the first to even remember its settings from one use to the next. I have an HP flatbed scanner sitting on my desk. When I use my TWAIN driver, I have to click off the scan settings every time the driver comes up. It's a small thing, but it makes using the scanner more difficult than it needs to be. (And that's when it's not crashing or locking up the calling applicatien.) It's lame software.
My experience with general-purpose software is that Macintosh software is usually the easiest to use. It's a cliche, but it's true. Unix/linux software generally provides the klunkiest UIs, but almost always provides a way to drop down into script mode so I can program whatever is missing from the UI. That's why I use my HP flatbed scanner with linux and scanimage. Finally, I find that WinDOZE software generally is the most awkward to use because you're locked into the poor UI. Want to do something the UI designer hadn't thought of? Too bad, you're almost always out of luck.
Finding a TWAIN scanner driver that makes the job of scanning and archiving photos so easy was a startling experience. I expected the Nikon scanner driver to be pure crap, like most TWAIN drivers. It's not only better than most TWAIN drivers, it's also better than most winDOZE software. It's actually very impressive. But maybe I just have higher expectations than you do.
Oh, and I call it "Windoze" not to be clever, but to express my utter contempt for it. I don't give a shit what you think of that.
--Jim
I thought the slide feeder was for the LS-4000 only. Not that it matters - after shelling out nearly $800 for the LS-40, I couldn't afford the slide scanner even if it would fit my model.
--Jim
For scanning 35mm negatives, the Nikon Coolscan IV (LS-40) can auto-feed the entire negative strip. The Windoze driver software can auto-scan the entire strip, auto-save each scan, and auto-name the files with incremented numbers in the name. The driver can also remember numbers between strips so when you scan the next strip, the filenames take up where the last one left off. It makes scanning negatives as painless as possible. Unfortunately, if you're scanning slides, you have to hand-feed each one, but the driver software can still handle the auto-saving and auto-naming of each scan file.
For Windoze software, it's actually very impressive. Nikon's scanner was expensive, but unlike some slide scanners I've had (*cough* Minolta *cough*) the Coolscan lives up to my expectations.
--Jim
The version of gcc that the admin recently installed converts "xor" to "^" in the *preprocessing* stage, apparently.
This is a good reason to learn how to run "gcc -E" or "gcc -P".
--Jim
I wouldn't put my real name on a story like that either.
--Jim
That's "pass by value", while you were expecting "pass by reference".
Which reminds me of an old fortune cookie:
"Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-les Worth). Which is to say that Europeans call him by name, but Americans call him by value"
BTW, you can make PHP pass arguments by reference if you put an ampersand in front of the argument name.
--Jim
No, it's all that single-malt Scotch they drink on their way to the Loch.
--Jim
When the going gets weird, the weird turn pro.
-- Hunter S. Thompson
Score: -1 Offtopic.
The best way to learn is to have someone dump a PHP system on you before they leave. You learn quickly when people start hauling out promises that were never delivered or scream about devastating problems they ignored a month ago.
That's called Trial By Fire. It's taught at the School of Hard Knocks. In a couple of years, you'll look back on this and laugh... as the attendant wheels you out of your padded cell for your daily session with the Software Recovery group. Enjoy!
--Jim
So while I'll agree on the point that you have to have some hands-on to master a language, I'll strenuously object to the idea that hands-on can replace a good book (or other training source).
I never said hands-on would replace books or even training classes. In fact, I believe I said several times that the hands-on needed to be accompanied by reference or tutorial material. But I don't think that books and training are the critical factors in learning a new language; I think real hands-on experience is.
Furthermore, I absolutely do not equate experimenting with a language to "trial-and-error". Just the opposite: in playing around with a language, once you know the basic control structures and syntax, I expect you to learn the language's strengths and weaknesses: how good is its object model (say), or its data structures, its exceptions, etc., etc. I expect you to test it, to put it through its paces. True, you can read about these things in the language reference, but until you actually put them into play, you don't get that deep visceral feel for how well they actually work in practice. In particular, I like to take difficult problems that I encountered in the past in other languages, and see how well the new language is set up to deal with the same problem: does it deal with it better, or worse? What are the tradeoffs? Clearly now we're way past "hello world", but as I said: you want to implement some nontrivial program of your own design.
Nor do reject the idea of learning from reading, be it "best practices" or "don't do this". That kind of material definitely has its place in the equation, but I don't think it becomes effective until you're reasonably fluent in a language, and especially until you've had the chance to transfer your own skills from other languages. I think you have to draw on all that you have available, but I don't think any of it is really effective unless you absorb it with a keyboard at your fingertips.
Finally, on the subject of becoming more than a good programmer, I'll say this: software is like painting: anybody can learn to slap paint onto a surface well enough to paint a barn. It's an essential skill, but if you want to move above painting barns and learn to paint something like the Mona Lisa, then you need to learn a whole additional set of skills. Good programming is relavitely easy; good software design is hard.
--Jim
Learning how to design software, and learning how to implement a design by programming in a language are two different (but related) things. Software design skills tend to apply across broad swaths of languages, though of course design skills change depending on the language: designing for an object-oriented language is and should be different than designing for a non-OO language. (Though an OO language can be reduced to a non-OO language if you don't use it well; who was it that said "A good programmer can write FORTRAN in any language"?)
"Diving in" doesn't necessarily lead to horrible style and structure. A good disciplined programmer can dive into a new language and find ways to transfer his good coding skills to programming well in the new language. Good style is largely orthogonal to specific languages - likewise if you're a sloppy C programmer you'll probably also be a sloppy perl, PHP, or Python programmer.
--Jim
My comment wasn't meant as a criticism - in fact what you said about the website doco was right on the mark. I learned PHP myself by downloading the HTML manual and reading it while I played with the language.
But whenever I see someone say something like "The best way to learn programming language Z is to..." it kind of sets me off. Of all the programmers I've known, the best ones always want to get their hands on the compiler first thing when learning a new language. And that's my personal experience too: it's all find and dandy to read something in a book, but deep learning, the kind that sinks in and stays, doesn't begin until I actually use the language.
--Jim
And I'll say it again. The best way to learn php is through the php website.
I've said it before and I'll say it again: the best way to learn a language is by using it. Sit down at a computer with the manuals and start slinging code. You can't really learn a language by reading a book or going to a class. Real programmers learn by doing.
If you want to supplement your programming with a book or tutorial, fine, but keep your fingers on the keyboard. If you want to run sample programs, fine, but experiment and play with them. Change them, tweak them, go off on your own tangents. Better yet: throw out the tutorial as soon as you can write "hello world" and try to write some program of your own design. Keep the language and library references handy, because you'll need to refer to them often, but let your imagination and curiousity be your guide. Explore. Play. Learn. Real programmers learn by doing.
What I tell you three times is true.
--Jim
According to a report and interview on NPR All Things Considered this afternoon, it only took about an hour to discover the password. The hard part was finding a copy of the old DOS-based database software that was capable of opening the database.
The institute now keeps copies of all its passwords locked in a safe. Of course, if all its passwords are as bad as the lost password, then what's the point?
--Jim
Really. Do us a favor, Taco & Co.: the next time someone writes in to say that he has a web server running on his ancient computer / handheld computer / kitchen appliance / Craftsman power tool / wife's electronic pleasure toy, please DON'T BOTHER to post it unless the submitter can reasonably claim that said device can handle the slashdot effect. Now, if they have a how-to / making-of site complete with story and pictures, on a server that can handle the load, now that's cool. But this assisted suicide of unusual web servers is just kind of pointless and perverse otherwise.
--Jim
ROFL! I didn't know the Pak were such awful whiners! Eat scrith, you scurvy plant-eaters!
Why not Nichelle Nichols? After all, Uhura was the communications officer.
And if you want to talk about universal translators in sci-fi, Larry Niven's version was much better done in the Ringworld series. It didn't just magically make everyone speak English (or Interworld or whatever), it had limitations too: it had to listen to the foreign tongue for some time, to learn a minimal vocabulary, before it could begin communicating, which it did only haltingly at first. It sometimes couldn't translate words like <something> for which it had no context to deduce meaning. These limitations made for some interesting moments like the time Louis Wu had been captured by a woman who didn't talk much, and so he had to bide his time until the translator finally heard enough words to learn her language.
But then again, the Ringworld was unstable...
--Jim
What's subversive about a PDA?
--Jim
The bill you pay to the cable company is just to get the service to your house (unless you purchase HBO or something).
If by "something" you mean "anything other than the non-basic service, which in my neighborhood consists of nothing of value that I couldn't get via rabbit-ears" then I agree with you. But I have never, never, been satisfied with basic service. I always opt at least for the "expanded" service - just to get a few channels that I want, plus a lot of other crap that I don't, but the cable company doesn't make it possible for me to buy just the channels I want, so don't get me started on that soapbox - and don't tell me that I'm paying for infrastructure and getting a bunch of free service. I'm not.
--Jim
I hardly think this sort of thing puts us on a slippery slope. If anything, there is *already* an epidemic problem of people being able to patent stupid and obvious things. This particular patent is just one snowflake in the storm
You miss the point. It's not the patent itself that's dangerous. What's dangerous is the idea of accepting silly software patents in order to do away with a relatively minor nuisance. If you're going to oppose software patents, then you need to be uniformly and consistently opposed to them, and resist the temptation to accept the convenient ones.
--Jim