If the temperature dropped wouldn't the polar caps grow?
Not necessarily. Lower global temperatures means less evaporation from the oceans, etc. Less evaporation means less water in the air to precipitate out. Less precipitation means less snowfall. Less snowfall means the polar caps shrink.
Nothing about climatology is as obvious as it appears at first glance. Too many interacting feedback cycles, some negative, some positive, some that start out one way and then change at a certain threshhold.
(And remember that water vapor has a far bigger greenhouse effect than CO2, which is why e.g. dry deserts get cold at night.)
Climate change is happening, and it's happening now, whether or not you actually believe in it.
Of course it is. It happens all the time, as evidenced by how many times and ways the climate has changed over the history of the planet.
scientists studying it said that there wasn't enough information to make any predictions about the future of the climate. Of course, there were a few nutjob scientists who thought that the end of the world was coming,
And this is different now how, exactly?
Once the newspapers and fear-merchants got hold of it, they blew it all out of proportion.
The clean-up at Rocky Flats (one of the places they used to machine plutonium into the precise shapes needed for weapons, among other fun tasks) also found a lot of plutonium in the ventilation systems and filters. Not (AFAIK) in near-critical concentrations, but enough (spread over the miles of ducts) to make a bomb or two.
Then there were the rooms where e.g. a spill had occured and they just abandoned the room and bricked up the doors.
(NB, the ventilation systems mentioned above were the sealed ventilation systems for the gloveboxes, etc, totally separate from the normal "breathing air" ventilation systems.)
What would be better than real-time for voice recognition software?
Doing speech-to-text from a speeded-up recording, or simultaneously doing multiple transcripts from different audio inputs. Or doing.wav file to text in less time than playing the.wav file takes.
I remember messing around with voice recognition in the 90s but the CPU power wasn't there to do real time voice.
Depends on the approach. I recall circa 1980 or so a prof at Concordia U. had a speech recognizer on a VAX 11/780 (with an A/D adapter). It didn't have to be trained on the speaker, and recognized my "Mary had a little lamb, its fleece was white as snow"(*) in a mere 10 or 15 minutes.
Okay, hardly real time, but that was on a 1 MIPS machine. It was also logging all the steps it took to analyze the speech input. It ought to be real time (or better?) on current hardware.
But is it really technically correct? Is the ability to cook an egg for breakfast an important skill for programmers?
Yes indeed.
Consider the choices that go into cooking an egg for breakfast. What is the desired end result - scrambled, boiled (hard or soft?), fried (sunnyside up, over easy, over, with the yolk broken?), made into an omelette? These choices in turn will affect your choice of tools - a pot of water or an egg cooker? a skillet? microwave oven? Or conversely, the tool(s) available may influence the choice of end result. The really adept can make do -- one can fry an egg in a saucepan, or boil one in a skillet, if one is truly desparate and sufficiently skilled. Salt and/or pepper? Maybe a little curry in with the scrambled egg?
And so on. Cooking an egg for breakfast is an allegory for the kind of decisions and need for an array of expertise that any skilled programmer can expect to face.
Guido Van Rossum's answer shows great wisdom and insight. Or maybe (like me after writing all this) he was just hungry.
Design Patterns was written to describe and categorize patterns that the authors had already observed "in the wild". That's certainly useful, it added to the vocabulary of discussion of design, and provides a cornerstone on which to build.
But good, experienced programmers/designers were already using many of these patterns without having that vocabulary to describe them.
That said, I would imagine most of the respondents have a copy of DP on their bookshelves -- along with other classics like Brooks's "Mythical Man-Month" or Knuth's "The Art of Computer Programming", etc. But they had to pick just one. K&R's book doesn't surprise me, although personally I think I learned more about programming (vs a particular language) from Kernighan & Plauger's "Software Tools".
Computer languages have nothing to do with human (natural) languages, except that some of the computer languages happen to borrow a very few words from English or some other natural language. (As an example of one that doesn't, consider APL.)
Computer languages are a symbology for breaking problems down into discrete steps. This is what makes a good programmer -- the ability to break down a problem into discrete steps that a machine can follow. Learning different symbologies (computer languages) in which to do that is downright trivial where the languages are largely similar, and for good programmers not that much harder where the concepts are quite different (LISP vs APL vs any of your Algol-derived languages, etc). (That latter is why, when hiring, I tend to look for programmers with a diverse programming language background rather than a high level of expertise in the language du jour.)
Human languages can be used for conveying discrete sequences of instructions, but they're better at "fuzzy" logic, abstract descriptions, conveying emotion, and the other things that humans use communication for. Someone who is totally incapable of breaking a problem down into discrete steps may still be adept at learning foreign languages, and someone who is adept at a score or more computer "languages" may have a hard time even with his native language.
(Although I'm inclined to think the latter may be less true -- I suspect that someone who has problems with eg spelling and grammar in their native language probably isn't a very good programmer either. As compared to other programmers, at least, not necessarily compared to the population at large (most of whom have a tough time programming a VCR or a microwave oven).)
since 1981. [...] in all that time, I really don't recall an over abundance of the word elegant being used to describe software.
Well, that's perfectly understandable -- look at when Microsoft (to pick a random example) really started to dominate the software business.
I think what you're seeing today is the corruption or dilution of the word for marketing purposes -- kind of like how a certain large software company uses "innovation" or "rich" (as in "rich user experience" or "rich text").
What part of "bug in the software" didn't you understand?
If the requirements don't say "it must have a save feature", then that's a bug in the requirements, not the software. If the spec or requirement says "must have the usual features of a word processor", then that's close enough to specifying that it must have a save feature, since word processors are a fairly ubiquitous class of software. That's not good enough for more detailed requirements. (Save as a dump of memory? Save in a particular format? Which format(s)? etc, etc)
Expectations don't count unless they are in some way communicated to the software developers. If you're grabbing software off the shelf (or the download site), then it's up to you to determine if it meets your spec, not the software developer's.
Knuth used to have this great offer where he'd send you a check for pi or e or something if you managed to find a bug in his code.
I think you're conflating two things. The check was (is?) for $50 or some such. The version number of the software is pi (or e) to whatever number of decimals, where each subsequent release adds a decimal place (becomes a closer approximation to the real thing.)
No, his concept of a bug is a deviation from the specified functionality.
That's the only reasonable definition of a bug in the software.
But what if that functionality is wrong or sucks?
Then that's a bug in the specification or in the requirements. I spent the better part of six months debugging the requirements on a major project once. Part of that was getting mutual agreement from three major customers, part of that was resolving internal inconsistencies in the requirements document, and part of that was a high level design process in parallel, to be sure we had a chance of actually satisfying the requirements.
Of course the end user (especially of off-the-shelf software) generally doesn't differentiate between a bug in the software vs a bug in the specification or requirements. The end user generally never sees the spec, and only has a vague idea of the requirements. (Sometimes worse than vague -- how many people do you know who use a spreadsheet for a database?)
(And to BadAnalogyGuy -- I'm not disagreeing, just amplifying.)
they tested it by using a program that systemattically scans code for common errors.
A method known to have flaws. It raises a ton of false positives, things that might "look like" potential bugs but aren't because of the data flow. You have to do a data flow analysis to see if they really are bugs.
For example, not checking for buffer overflows when copying strings, etc, is usually considered a (potential) bug. Certainly it is when dealing with unknown input. However, in a function buried deep behind layers of other code that has already filtered out potentially overrunning strings, it is quite safe. (At least until said code is changed, so it is considered bad practise, but the fact remains that if there's no data path that can cause a problem, it's not a bug.)
Mind, there's bugs and there's bugs. The Space Shuttle software is generally considered to be about the most defect-free software around, but they'll launch with some bugs. Specifically, minor bugs in the display (ie a misspelled word, a column that doesn't quite align) are allowed because they're a much lower risk than going in and changing the software to fix them (and possibly introducing a different bug).
Yep. Star Wars, the story of a poor kid on Arakkis who grew up and went to Trantor. But movies and TV series routinely rip off whatever they can, tweaking it just enough to (usually) avoid lawsuits.
Not to say that science fiction (and other) writers don't rip off too, but they're usually much better at filing off the serial numbers, and taking from totally different genres (as well as being long since in the public domain). Asimov's inspiration for the Foundation Trilogy (back when it was a trilogy) was, loosely speaking, "The Rise and Fall of the Roman Empire". Forbidden Planet was loosely based on Shakespeare's "The Tempest" (and of course Star Trek ripped off a lot from Forbidden Planet). And so on.
(In fact Hollywood is often closer to the original when they rip something off than they are when they buy the property and make a movie from it. Joke. Joke.)
its not like he's spending more than anyone else, especially considering the intense special effects.
Well no, but I imagine that Industrial Light & Magic might cut him a special deal on those. Ditto for the THX sound labs.
(I'll say one thing for Lucas -- whatever horrible things he's done to the StarWars franchise, he did reinvest a lot of the money he made off the first few into improving movie-making technology. Not sure what he's done for us lately, though.)
What acceleration technique can we use that provides 1000g acceleration roughly consistently over a 5km distance in one second?
The same technique that provides 2000g (from TFA) of centripetal acceleration consistently over a 6.28 km distance (pi * 2km, from TFA) in just under a second (6.28/7, taking escape velocity as 7km/sec, although TFA uses 10km/sec).
Actually, the former would be a lot easier, which is my point.
(The payload is not tied to a string or riding on rails, the only thing that can provide that centripetal force is the magnets. TFA keeps referring to a "sled" without further specification. If you can think of something other than magnetic fields that would support said sled at 2000g and Mach 23 without destroying itself and the ring, I'd love to hear about it.)
If the magnets are only providing a few g, how at high speeds do they provide enough force to turn the payload enough to keep it from running into the circular accelerator walls?
At escape velocity, about half a second after the payload is heading south in that accelerator (at about 7km/sec), it will be heading north at 7km/sec (ie, the same speed but with the opposite velocity vector). Compute the acceleration necessary to do this, given that the payload can make no physical contact with the accelerator walls. How much force do the magnets need to apply?
Do the math. A linear accelarator with half the linear acceleration that this has angular acceleration would be shorter than the circumference of what they're proposing.
Unfortunately, no. Which is a shame because Heinlein was too intelligent to have his catapults waste energy whirling the damn payload in circles for hours before launching it. A simple straight line suffices and is more efficient.
Anyone seeing a parallel is insulting Heinlein. Parody is more like it.
Slashdot Mirror
If the temperature dropped wouldn't the polar caps grow?
Not necessarily. Lower global temperatures means less evaporation from the oceans, etc. Less evaporation means less water in the air to precipitate out. Less precipitation means less snowfall. Less snowfall means the polar caps shrink.
Nothing about climatology is as obvious as it appears at first glance. Too many interacting feedback cycles, some negative, some positive, some that start out one way and then change at a certain threshhold.
(And remember that water vapor has a far bigger greenhouse effect than CO2, which is why e.g. dry deserts get cold at night.)
Climate change is happening, and it's happening now, whether or not you actually believe in it.
Of course it is. It happens all the time, as evidenced by how many times and ways the climate has changed over the history of the planet.
scientists studying it said that there wasn't enough information to make any predictions about the future of the climate. Of course, there were a few nutjob scientists who thought that the end of the world was coming,
And this is different now how, exactly?
Once the newspapers and fear-merchants got hold of it, they blew it all out of proportion.
Hmm, not different at all, I guess.
The clean-up at Rocky Flats (one of the places they used to machine plutonium into the precise shapes needed for weapons, among other fun tasks) also found a lot of plutonium in the ventilation systems and filters. Not (AFAIK) in near-critical concentrations, but enough (spread over the miles of ducts) to make a bomb or two.
Then there were the rooms where e.g. a spill had occured and they just abandoned the room and bricked up the doors.
(NB, the ventilation systems mentioned above were the sealed ventilation systems for the gloveboxes, etc, totally separate from the normal "breathing air" ventilation systems.)
We won't know for sure until we open the box.
I'd hope they'd have to label them as similarly protected CDs are labeled, or not be allowed to use the DVD logo.
Disney, for one, has never used the DVD-Video logo, They have their own "Disney DVD" logo that they've been using all along.
What would be better than real-time for voice recognition software?
.wav file to text in less time than playing the .wav file takes.
Doing speech-to-text from a speeded-up recording, or simultaneously doing multiple transcripts from different audio inputs. Or doing
I remember messing around with voice recognition in the 90s but the CPU power wasn't there to do real time voice.
Depends on the approach. I recall circa 1980 or so a prof at Concordia U. had a speech recognizer on a VAX 11/780 (with an A/D adapter). It didn't have to be trained on the speaker, and recognized my "Mary had a little lamb, its fleece was white as snow"(*) in a mere 10 or 15 minutes.
Okay, hardly real time, but that was on a 1 MIPS machine. It was also logging all the steps it took to analyze the speech input. It ought to be real time (or better?) on current hardware.
(* a phrase of some historical significance.)
But is it really technically correct? Is the ability to cook an egg for breakfast an important skill for programmers?
Yes indeed.
Consider the choices that go into cooking an egg for breakfast. What is the desired end result - scrambled, boiled (hard or soft?), fried (sunnyside up, over easy, over, with the yolk broken?), made into an omelette? These choices in turn will affect your choice of tools - a pot of water or an egg cooker? a skillet? microwave oven? Or conversely, the tool(s) available may influence the choice of end result. The really adept can make do -- one can fry an egg in a saucepan, or boil one in a skillet, if one is truly desparate and sufficiently skilled. Salt and/or pepper? Maybe a little curry in with the scrambled egg?
And so on. Cooking an egg for breakfast is an allegory for the kind of decisions and need for an array of expertise that any skilled programmer can expect to face.
Guido Van Rossum's answer shows great wisdom and insight. Or maybe (like me after writing all this) he was just hungry.
Design Patterns was written to describe and categorize patterns that the authors had already observed "in the wild". That's certainly useful, it added to the vocabulary of discussion of design, and provides a cornerstone on which to build.
But good, experienced programmers/designers were already using many of these patterns without having that vocabulary to describe them.
That said, I would imagine most of the respondents have a copy of DP on their bookshelves -- along with other classics like Brooks's "Mythical Man-Month" or Knuth's "The Art of Computer Programming", etc. But they had to pick just one. K&R's book doesn't surprise me, although personally I think I learned more about programming (vs a particular language) from Kernighan & Plauger's "Software Tools".
Computer languages have nothing to do with human (natural) languages, except that some of the computer languages happen to borrow a very few words from English or some other natural language. (As an example of one that doesn't, consider APL.)
Computer languages are a symbology for breaking problems down into discrete steps. This is what makes a good programmer -- the ability to break down a problem into discrete steps that a machine can follow. Learning different symbologies (computer languages) in which to do that is downright trivial where the languages are largely similar, and for good programmers not that much harder where the concepts are quite different (LISP vs APL vs any of your Algol-derived languages, etc). (That latter is why, when hiring, I tend to look for programmers with a diverse programming language background rather than a high level of expertise in the language du jour.)
Human languages can be used for conveying discrete sequences of instructions, but they're better at "fuzzy" logic, abstract descriptions, conveying emotion, and the other things that humans use communication for. Someone who is totally incapable of breaking a problem down into discrete steps may still be adept at learning foreign languages, and someone who is adept at a score or more computer "languages" may have a hard time even with his native language.
(Although I'm inclined to think the latter may be less true -- I suspect that someone who has problems with eg spelling and grammar in their native language probably isn't a very good programmer either. As compared to other programmers, at least, not necessarily compared to the population at large (most of whom have a tough time programming a VCR or a microwave oven).)
since 1981. [...] in all that time, I really don't recall an over abundance of the word elegant being used to describe software.
Well, that's perfectly understandable -- look at when Microsoft (to pick a random example) really started to dominate the software business.
I think what you're seeing today is the corruption or dilution of the word for marketing purposes -- kind of like how a certain large software company uses "innovation" or "rich" (as in "rich user experience" or "rich text").
A pity, really.
What part of "bug in the software" didn't you understand?
If the requirements don't say "it must have a save feature", then that's a bug in the requirements, not the software. If the spec or requirement says "must have the usual features of a word processor", then that's close enough to specifying that it must have a save feature, since word processors are a fairly ubiquitous class of software. That's not good enough for more detailed requirements. (Save as a dump of memory? Save in a particular format? Which format(s)? etc, etc)
Expectations don't count unless they are in some way communicated to the software developers. If you're grabbing software off the shelf (or the download site), then it's up to you to determine if it meets your spec, not the software developer's.
wine for example [...] we all know it by far doesn't always do what we want it to do.
;-)
Sounds like a pretty fair emulation of Windows to me.
Knuth used to have this great offer where he'd send you a check for pi or e or something if you managed to find a bug in his code.
I think you're conflating two things. The check was (is?) for $50 or some such. The version number of the software is pi (or e) to whatever number of decimals, where each subsequent release adds a decimal place (becomes a closer approximation to the real thing.)
No, his concept of a bug is a deviation from the specified functionality.
That's the only reasonable definition of a bug in the software.
But what if that functionality is wrong or sucks?
Then that's a bug in the specification or in the requirements. I spent the better part of six months debugging the requirements on a major project once. Part of that was getting mutual agreement from three major customers, part of that was resolving internal inconsistencies in the requirements document, and part of that was a high level design process in parallel, to be sure we had a chance of actually satisfying the requirements.
Of course the end user (especially of off-the-shelf software) generally doesn't differentiate between a bug in the software vs a bug in the specification or requirements. The end user generally never sees the spec, and only has a vague idea of the requirements. (Sometimes worse than vague -- how many people do you know who use a spreadsheet for a database?)
(And to BadAnalogyGuy -- I'm not disagreeing, just amplifying.)
they tested it by using a program that systemattically scans code for common errors.
A method known to have flaws. It raises a ton of false positives, things that might "look like" potential bugs but aren't because of the data flow. You have to do a data flow analysis to see if they really are bugs.
For example, not checking for buffer overflows when copying strings, etc, is usually considered a (potential) bug. Certainly it is when dealing with unknown input. However, in a function buried deep behind layers of other code that has already filtered out potentially overrunning strings, it is quite safe. (At least until said code is changed, so it is considered bad practise, but the fact remains that if there's no data path that can cause a problem, it's not a bug.)
Mind, there's bugs and there's bugs. The Space Shuttle software is generally considered to be about the most defect-free software around, but they'll launch with some bugs. Specifically, minor bugs in the display (ie a misspelled word, a column that doesn't quite align) are allowed because they're a much lower risk than going in and changing the software to fix them (and possibly introducing a different bug).
The GPLv3 is still in draft. Nobody can choose it yet.
The question is troll/flamebait.
Or to quote the Magic 8-Ball: "Ask again later" -- like in 6 months or so.
Yep. Star Wars, the story of a poor kid on Arakkis who grew up and went to Trantor. But movies and TV series routinely rip off whatever they can, tweaking it just enough to (usually) avoid lawsuits.
Not to say that science fiction (and other) writers don't rip off too, but they're usually much better at filing off the serial numbers, and taking from totally different genres (as well as being long since in the public domain). Asimov's inspiration for the Foundation Trilogy (back when it was a trilogy) was, loosely speaking, "The Rise and Fall of the Roman Empire". Forbidden Planet was loosely based on Shakespeare's "The Tempest" (and of course Star Trek ripped off a lot from Forbidden Planet). And so on.
(In fact Hollywood is often closer to the original when they rip something off than they are when they buy the property and make a movie from it. Joke. Joke.)
Yes, well where do you think Lucas stole the ide..er, got his inspiration?
Of course, there's always the chance as the verbal history was passed down, tellers embellished a bit to impress the kids better.
"In my day, we not only had to walk uphill both ways to school, we had to part the seas to do it!"
"You parted the seas?! Lucky bastard! We had to hold breath and walk along the bottom..."
"Oh yes. Well, at least you were walking. We had to outrun the whole Egyptian army.. And wander in the desert for forty days."
"Days? We had to wander for forty weeks!"
"Well I say days, it was really forty years. But we were tough, it just seemed like days to us..."
its not like he's spending more than anyone else, especially considering the intense special effects.
Well no, but I imagine that Industrial Light & Magic might cut him a special deal on those. Ditto for the THX sound labs.
(I'll say one thing for Lucas -- whatever horrible things he's done to the StarWars franchise, he did reinvest a lot of the money he made off the first few into improving movie-making technology. Not sure what he's done for us lately, though.)
And now you know why Google is bouncing Sourceforge email.
Or vice versa.
Or, to put it another way,
What acceleration technique can we use that provides 1000g acceleration roughly consistently over a 5km distance in one second?
The same technique that provides 2000g (from TFA) of centripetal acceleration consistently over a 6.28 km distance (pi * 2km, from TFA) in just under a second (6.28/7, taking escape velocity as 7km/sec, although TFA uses 10km/sec).
Actually, the former would be a lot easier, which is my point.
(The payload is not tied to a string or riding on rails, the only thing that can provide that centripetal force is the magnets. TFA keeps referring to a "sled" without further specification. If you can think of something other than magnetic fields that would support said sled at 2000g and Mach 23 without destroying itself and the ring, I'd love to hear about it.)
If the magnets are only providing a few g, how at high speeds do they provide enough force to turn the payload enough to keep it from running into the circular accelerator walls?
At escape velocity, about half a second after the payload is heading south in that accelerator (at about 7km/sec), it will be heading north at 7km/sec (ie, the same speed but with the opposite velocity vector). Compute the acceleration necessary to do this, given that the payload can make no physical contact with the accelerator walls. How much force do the magnets need to apply?
Show your work.
Do the math. A linear accelarator with half the linear acceleration that this has angular acceleration would be shorter than the circumference of what they're proposing.
Am I the only one seeing the parallel?
Unfortunately, no. Which is a shame because Heinlein was too intelligent to have his catapults waste energy whirling the damn payload in circles for hours before launching it. A simple straight line suffices and is more efficient.
Anyone seeing a parallel is insulting Heinlein. Parody is more like it.