Actually, percentages are quite simply a sucky way of judging whether something is obsolete.
In the context of this discussion, a skill is obsolete when it is no longer needed to do something that is still being done today - For example, nobody needs to know how to load a program off tape on a C64 these days, because we don't have C64s anymore.
By this definition, assembly programming is obviously NOT obsolete. We still need assembly programmers: for device drivers, for kernel programming, for writing compilers, for reverse engineering old code that is no longer supported, for cracking dumb DRM schemes that take away our fair-use rights, etc etc etc. The fact that not many people know how to write assembly is irrelevant: does the fact that few people know how to build a human-rated space launch vehicule mean that it is obsolete?
There I was, busy using my mod points on this story, and I come across this post.
Maaaaate, if you're going to shoot your mouth of, do at least try to get the tech details right - this is/. after all.
USB hubs do NOT have to handle "the extra voltage" from the MBA, for the good reason that the USB power supply is a voltage source, not a current source. In other words, the Apple USB port delivers the same voltage as any other USB port. Where it is different is that it can supply more current than a normal port, but it does this if and only if the device is trying to draw more current. In other words, a normal USB device, trying to draw a normal amount of current for the device, will still draw the same amount of current as it does when plugged into any other powered USB port.
This of course means that the reality is the exact opposite of your post - a MacBook Air will quite happily drive multiple devices off the one USB port, when using a hub, because there is more current available to share between devices. One may even suspect that Apple deliberately designed it that way!
Sheesh! don't they teach anything in high school physics classes anymore????
heh, I'm a bit laste with this post, but, ohmigod, you know about Compucolors!!! That's how I got into computers. My father bought a Compucolour II waaaay back - 1980/81-ish IIRC.
As the Compucolor had very few games, if I wanted to play any, I had to write them myself. Being a 7 yr old at the time, that meant adapting games that appeared in magazines for other computers. My father also had access to Apple IIes and IIcs that he would bring home from work, so that's how I got my gaming fixes, but in between those weekends with the Apple, I was programming rather than playing...
A book like Hitchhikers Guide would make a poor game (IMO)
Ahhh, there you would be wrong:-) The game of THHGTTG was almost better than the book, in fact, for me, it was better than the book. I'll never forget the battles I had with the damned beverage dispenser, or the sheer thrill of finally getting the wretched babelfish out of the babelfish dispenser.
Lol. Well, yes, there is that too.:-) But I was more focused on trying to communicate the folly of using the results of a scientific instrument that we have, as of yet, been completely unable to calibrate due to the lack of any positive results.
That would be true, provided that we knew that LIGO actually worked. As it has to date failed to detect any gravity waves, we can not eliminate the possibility:
- that gravity waves don't exist (ie that GR is wrong)
- that the calculated sensitivity of LIGO is wrong by orders of magnitude
As a result, this study really doesn't tell us very much at all.
I can still remember the thrill of finally figuring out how to kill the dragon, or that you could water the plant to make it grow...
That said, I never did "finish" the damn thing. Just one more text adventure I never finished (how DO you get off the Heart Of Gold in Hitchhiker's Guide to the Galaxy?). And don't get me started on Zork. Actually, I still play text adventures to this day - some very good stuff can be found on the web - try here.
Well, I know of at least one other significant use of Ruby - RubyCocoa. With the release of Leopard, Apple has upgraded both Ruby and Python to near first-class citizens of it's desktop environment. I've tried it out, and for the first time in years I'm back in the desktop app development game:-)
Ouf, Google translator still needs some work. The French translation should look something like this (apologies to actual native french-speakers...):
Les programmeurs "agile" ont raison. Si le code est bien écrit, il va parler pour lui-même. Il n'y a pas besoin de dupliquer ce que dit le code dans un autre langue(par example anglais). C'est un peu comme si tu commentais tes paragraphes anglais avec la traduction française. à moins que le français soit ta langue maternelle, de tels commentaires ne vont qu'obscurer la lecture de l'anglais. En tant que programmeur, c'est mon boulot de "parler courrament" mon language de programmation de choix. Lire du code devrait être aussi facile que de lire un bouquin....
Célà dit, parfois on est obligé d'écrire quelque chose d'anormale, et dans ce cas, on devrait le commenter. Pourtant, ces cas sont très rares..
I suppose I should explain why I just corrected (as well as I am able) the translation. I work for a French company - all of the programmers are French, except me, and yet they have a stupid corporate policy where all comments in code should be written in English, as are identifiers (variable names, function names, type names).
The result is that comments are very sparse, and generally limited to simply repeating, using fixed phrasing, what is already très clair in the actual code. On the few occassions where somebody actually tries to go a bit further, the lack of mastery of little things like prepositions (in, of, to, at, on, in), which is fine in day to day speech, can sometimes completely destroy/inverse the meaning of a comment, making it worse than useless.
Now, with programming being such an international endeavour, it is becoming quite rare that all of the programmers on a project have the same native language. In such an enviroment, bastardised English comments are next to useless - non-native English speakers won't read or write them, and native english speakers can't understand what has been written by non-native speakers.
My conclusion from all of this? Forget about documentation. Try to make the code as self-documenting as possible. With the time saved from not havig to write documentation, write unit tests instead. Your code (and the world) will be better for it.
I couldn't agree with you more. Sadly, having tried this style of commenting/documenting at my last couple of jobs, I'm ready to give up.
I've tried writing large block comments at the start of a module, explaining what the module does, and then comments in a block before each function of the module, explaining how that function fits into the big scheme outlined in the big comment above. I've tried doing pretty much the same, except putting the large comments that were at the start of the code module in a seperate architecture document. I've added UML diagrams to said doculent to make it clearer. I've put the comments both in the module, and in a document at the same time. I've written additional documentation explaining how the code artifacts (objects, files, variables) relate to the terms used in the specification.
And you know what? No-one bloody well reads the stuff. People figure that it's easier to come to me to help plan out a modification than to read the comments which would have answered all of their questions if they'd just taken 10 minutes out of their oh-so-busy lives. As that level of documentation typically takes 2-4 weeks to write, depending on the size of a project, I have come to the conclusion that it's a waste of time, and that I could better spend that time by writing bigger and meaner unit tests. That way when an idiot modifies code in a module that they haven't read the documentation for, and hence don't understand, their scope to actually wreck the system is limited.
Here's a couple of my own stories from the trenches:
1) My company sticks me on the booth at a trade show to demo the product that I have spent the last 6 months working on. There were nulerous men that would ask me for a description of how a feature worked, and when I told them, they'd simply say 'nah, it doesn't work like that. If you understood the technology, you would know that that's impossible'. The funny thing was that some would still insist that my description was wrong even after I explained that I was the programmer.
2) Still at the same company. The company rule was that when the receptionist was absent, everyone else would pitch in to answer the phones. The reality was that everyone left me to answer the phones, being the only other woman in the office. Which meant that I got more than my fair share of support calls. In general the call would go something like: customer - Hi, I need to speak to a tech to resolve a problem. me - Sure, what is the problem? customer - I'd rather just speak to the tech directly thanks me - I'm one of the engineers that designs the product, you can talk to me. customer - (and I kid you not) No, I need to speak to a man.
That particular response was far from rare.
me - Um, OK, well can you at least tell me which product it concerns? customer - me - um, look, I'm the only person in the company that knows that code - I wrote it, and no-one else has touched the project. You're going to need to talk to me. customer - can I speak to your manager please. me - . Sure
5 minutes later my boss would typically forward the call back to me. Not once in 2 years did the caller apologise to me for blowing me off at first.
In a more general sense, I have a party trick that I like to pull out when this topic comes up in a group of tech workers. I ask each person in the group to say how many times they have been promoted. Take the average number of promotions for men, and the average number of promotions for women, adjust for number of years worked in the industry, and I guarantee you that the numbers will show that men are promoted 2-3 times as much as women. Most women are simply never promoted - we advance by changing jobs. Apparently recruiting is less apt to discriminate.
Your reasoning is simplistic in the extreme - you forgot to take into account the opposing scenario:
In Society 1, a guy gets drunk in a bar, gets agro, and starts taking a swing at his neighbours. They sit on him until he quietens down.
In Society 2, a guy gets drunk in a bar, gets agro, reaches for his sword, and starts hacking people up until someone manages to finds where they have stashed their own sword to retaliate. Several people die.
I would submit that this scenario is way more likely than your nutcase with a samurai sword scenario... To back up my assertion, I invite you to consider how well the US fares in terms of number of deaths caused by firearms, compared to countries that seriously restrict access to firearms. That's the real world result of your theory.
Actually, that's not so hard. If you try to decrypt an encrypted message using the wrong key, what you get out the other end looks like a randomised byte stream. If instead you see a non-random distribution of bytes, you can be pretty damn sure that you have the right key. The number of false positives from this very simple check is really quite small.
Where you do get into a bit of a mess is when you try to decrypt a compressed data stream, because compression basically tries to remove all predictability from a message - in other words, the message looks to be random. In such a case, a knowledge of the compression algorithm being used (and there aren't that many of them in use today), will quickly enable this to be taken into account.
Actually, you have to get it from your house - but make sure you climb up a really high triangle in mid-route to refreeze it, otherwise it'll melt and slip from your grasp, smashing into many pieces:-(
Which was kind of where I was going. Quantum weirdness and the speed limit on the transmission of information both make me think of the way cellular automata function.
I was listining to a podcast the other day (Escape Pod - scifi stories), and the story was about a guy that learns that his world is in a simulator, but there are bugs, especially found in an on-line game. You can make objects leave the game and appear in the "real world".
Which brings me back to the question. We live in a "real world" which exhibits at least some of the aspects that we would expect of a simulated world, and I keep wondering what sort of programming artifacts (bugs) could exist, how could we find them, and how could we exploit them...
Anyway, I don't intend to spend my life researching answers to those questions, but they seem to me to be every bit as valid for scientific research as , for example, SETI.
I mean, if even on our simpler computer systems, we are unable to simulate a computer well enough to hide the existence of the external simulator from the internal computer system, then it makes it a little difficult to believe that we could hide the fact that all of reality was being simulated, as in the case of the Matrix...
Or, maybe this work isn't really applicable philosophically.. Maybe they aren't describing a fundamental limit of the idea, but simply some problems with current implementations.
While your listing other open source kernels, don't forget about Darwin... There are probably other open source kernels floating about out there as well...
Well, I probably got here too late, but f you are looking for some texts that could be read in an English class, but which pose big scientific questions, you couldn't really go wrong with Gregory Benford - I'm thinking in particular of two of his novels, Cosm and Timescape.
Benford's hook is that he uses research scientists as his protagonists. They are typically on the verge of making a big scientific discovery with accompanying moral dilemmas (will it save/destroy the world, who should profit from it, who 'owns' the science, etc). The characters live in our real world, and the physics is all valid (well, riffing of cutting edge unproven theories, but still possible - sending messages back in time, creating mini event horizon universes etc). But most importantly, the concerns of the characters are real world concerns.
The only downside is that the books are perhaps a bit too difficult for 8th graders... Cosm might work, but Timescape definately requires high level reading skills.
No, you're making the error of treating declinaisons of words as seperate words. Jump, jumps, jumped, jumping, they're all just conjugated forms of the one word - jump. Same thing for nouns, especially in gendered languages such as French. Gelé, gelés, gelée, gelées, they all just mean 'frozen', but declined for different subjects.
If you prefer, substitute "unique verbs/adjectives/nouns" for "words" in my original post. That's how linguists count vocabulary... If you think that most people have a vocab counted this way of more than 2000 "words" you are waaaay off mark.
Again, talking about French, I live in France. The reason I only have a vocabulary of 1500 words or so is because I just don't see/hear any other words often enough to retain them. Twilight, mist and marsh for example are well and truly in my vocabulary list - they are words that you can expect to hear/read around about once a week. It's words that you encounter at less than once a month that are difficult to learn, and words that you encounter once a year are nigh on impossible to learn without making a deliberate effort to learn a bigger vocabulary - they won't get learned organically.
Your numbers there are just flat out wrong. Most English dictionaries don't have 50 000 words! For most languages, you are considered to be a fluent speaker at a vocabulary of around about 1000 words. Someone that does a fair bit of reading will probably have a vocabulary of 3-4000 words, and spelling bee freaks can probably claim about 6000 words.
I speak French as a second language, and with a vocabulary of about 1500 words, I find myself to be about the equal of most native speakers in daily conversation. I can, for example, read a novel like The Da Vinci Code in French, without ever noticing that there are words that I don't know (well, if you put aside domain-specific nouns like 'atbash' or 'cilice'). I might struggle a bit when trying to read economics reports in newspapers, or a recipe, or some other article with a specific vocabulary attached, but 1500 words is more than enough for a normal usage of a language...
Slashdot Mirror
Actually, percentages are quite simply a sucky way of judging whether something is obsolete.
In the context of this discussion, a skill is obsolete when it is no longer needed to do something that is still being done today - For example, nobody needs to know how to load a program off tape on a C64 these days, because we don't have C64s anymore.
By this definition, assembly programming is obviously NOT obsolete. We still need assembly programmers: for device drivers, for kernel programming, for writing compilers, for reverse engineering old code that is no longer supported, for cracking dumb DRM schemes that take away our fair-use rights, etc etc etc. The fact that not many people know how to write assembly is irrelevant: does the fact that few people know how to build a human-rated space launch vehicule mean that it is obsolete?
Which is of course why they just put in Cocoa bridges for Python and Ruby in the latest release of OS X. Wait... What?
There I was, busy using my mod points on this story, and I come across this post.
/. after all.
Maaaaate, if you're going to shoot your mouth of, do at least try to get the tech details right - this is
USB hubs do NOT have to handle "the extra voltage" from the MBA, for the good reason that the USB power supply is a voltage source, not a current source. In other words, the Apple USB port delivers the same voltage as any other USB port. Where it is different is that it can supply more current than a normal port, but it does this if and only if the device is trying to draw more current. In other words, a normal USB device, trying to draw a normal amount of current for the device, will still draw the same amount of current as it does when plugged into any other powered USB port.
This of course means that the reality is the exact opposite of your post - a MacBook Air will quite happily drive multiple devices off the one USB port, when using a hub, because there is more current available to share between devices. One may even suspect that Apple deliberately designed it that way!
Sheesh! don't they teach anything in high school physics classes anymore????
heh, I'm a bit laste with this post, but, ohmigod, you know about Compucolors!!! That's how I got into computers. My father bought a Compucolour II waaaay back - 1980/81-ish IIRC.
As the Compucolor had very few games, if I wanted to play any, I had to write them myself. Being a 7 yr old at the time, that meant adapting games that appeared in magazines for other computers. My father also had access to Apple IIes and IIcs that he would bring home from work, so that's how I got my gaming fixes, but in between those weekends with the Apple, I was programming rather than playing...
I guess Les Flics are going to become Les Flix...
Ahhh, there you would be wrong :-) The game of THHGTTG was almost better than the book, in fact, for me, it was better than the book. I'll never forget the battles I had with the damned beverage dispenser, or the sheer thrill of finally getting the wretched babelfish out of the babelfish dispenser.
Of course, the game was interactive fiction...
Lol. Well, yes, there is that too. :-) But I was more focused on trying to communicate the folly of using the results of a scientific instrument that we have, as of yet, been completely unable to calibrate due to the lack of any positive results.
That would be true, provided that we knew that LIGO actually worked. As it has to date failed to detect any gravity waves, we can not eliminate the possibility:
- that gravity waves don't exist (ie that GR is wrong)
- that the calculated sensitivity of LIGO is wrong by orders of magnitude
As a result, this study really doesn't tell us very much at all.
Geez, I wonder why I never managed to figure that out!
I can still remember the thrill of finally figuring out how to kill the dragon, or that you could water the plant to make it grow...
That said, I never did "finish" the damn thing. Just one more text adventure I never finished (how DO you get off the Heart Of Gold in Hitchhiker's Guide to the Galaxy?). And don't get me started on Zork. Actually, I still play text adventures to this day - some very good stuff can be found on the web - try here.
Well, I know of at least one other significant use of Ruby - RubyCocoa. With the release of Leopard, Apple has upgraded both Ruby and Python to near first-class citizens of it's desktop environment. I've tried it out, and for the first time in years I'm back in the desktop app development game :-)
Which desert?
Ouf, Google translator still needs some work. The French translation should look something like this (apologies to actual native french-speakers...):
...
Les programmeurs "agile" ont raison. Si le code est bien écrit, il va parler pour lui-même. Il n'y a pas besoin de dupliquer ce que dit le code dans un autre langue(par example anglais). C'est un peu comme si tu commentais tes paragraphes anglais avec la traduction française. à moins que le français soit ta langue maternelle, de tels commentaires ne vont qu'obscurer la lecture de l'anglais. En tant que programmeur, c'est mon boulot de "parler courrament" mon language de programmation de choix. Lire du code devrait être aussi facile que de lire un bouquin.
Célà dit, parfois on est obligé d'écrire quelque chose d'anormale, et dans ce cas, on devrait le commenter. Pourtant, ces cas sont très rares..
I suppose I should explain why I just corrected (as well as I am able) the translation. I work for a French company - all of the programmers are French, except me, and yet they have a stupid corporate policy where all comments in code should be written in English, as are identifiers (variable names, function names, type names).
The result is that comments are very sparse, and generally limited to simply repeating, using fixed phrasing, what is already très clair in the actual code. On the few occassions where somebody actually tries to go a bit further, the lack of mastery of little things like prepositions (in, of, to, at, on, in), which is fine in day to day speech, can sometimes completely destroy/inverse the meaning of a comment, making it worse than useless.
Now, with programming being such an international endeavour, it is becoming quite rare that all of the programmers on a project have the same native language. In such an enviroment, bastardised English comments are next to useless - non-native English speakers won't read or write them, and native english speakers can't understand what has been written by non-native speakers.
My conclusion from all of this? Forget about documentation. Try to make the code as self-documenting as possible. With the time saved from not havig to write documentation, write unit tests instead. Your code (and the world) will be better for it.
I couldn't agree with you more. Sadly, having tried this style of commenting/documenting at my last couple of jobs, I'm ready to give up.
I've tried writing large block comments at the start of a module, explaining what the module does, and then comments in a block before each function of the module, explaining how that function fits into the big scheme outlined in the big comment above. I've tried doing pretty much the same, except putting the large comments that were at the start of the code module in a seperate architecture document. I've added UML diagrams to said doculent to make it clearer. I've put the comments both in the module, and in a document at the same time. I've written additional documentation explaining how the code artifacts (objects, files, variables) relate to the terms used in the specification.
And you know what? No-one bloody well reads the stuff. People figure that it's easier to come to me to help plan out a modification than to read the comments which would have answered all of their questions if they'd just taken 10 minutes out of their oh-so-busy lives. As that level of documentation typically takes 2-4 weeks to write, depending on the size of a project, I have come to the conclusion that it's a waste of time, and that I could better spend that time by writing bigger and meaner unit tests. That way when an idiot modifies code in a module that they haven't read the documentation for, and hence don't understand, their scope to actually wreck the system is limited.
Yeah, tell me about it!
Here's a couple of my own stories from the trenches:
1) My company sticks me on the booth at a trade show to demo the product that I have spent the last 6 months working on. There were nulerous men that would ask me for a description of how a feature worked, and when I told them, they'd simply say 'nah, it doesn't work like that. If you understood the technology, you would know that that's impossible'. The funny thing was that some would still insist that my description was wrong even after I explained that I was the programmer.
2) Still at the same company. The company rule was that when the receptionist was absent, everyone else would pitch in to answer the phones. The reality was that everyone left me to answer the phones, being the only other woman in the office. Which meant that I got more than my fair share of support calls. In general the call would go something like:
customer - Hi, I need to speak to a tech to resolve a problem.
me - Sure, what is the problem?
customer - I'd rather just speak to the tech directly thanks
me - I'm one of the engineers that designs the product, you can talk to me.
customer - (and I kid you not) No, I need to speak to a man.
That particular response was far from rare.
me - Um, OK, well can you at least tell me which product it concerns?
customer -
me - um, look, I'm the only person in the company that knows that code - I wrote it, and no-one else has touched the project. You're going to need to talk to me.
customer - can I speak to your manager please.
me - . Sure
5 minutes later my boss would typically forward the call back to me. Not once in 2 years did the caller apologise to me for blowing me off at first.
In a more general sense, I have a party trick that I like to pull out when this topic comes up in a group of tech workers. I ask each person in the group to say how many times they have been promoted. Take the average number of promotions for men, and the average number of promotions for women, adjust for number of years worked in the industry, and I guarantee you that the numbers will show that men are promoted 2-3 times as much as women. Most women are simply never promoted - we advance by changing jobs. Apparently recruiting is less apt to discriminate.
Your reasoning is simplistic in the extreme - you forgot to take into account the opposing scenario:
In Society 1, a guy gets drunk in a bar, gets agro, and starts taking a swing at his neighbours. They sit on him until he quietens down.
In Society 2, a guy gets drunk in a bar, gets agro, reaches for his sword, and starts hacking people up until someone manages to finds where they have stashed their own sword to retaliate. Several people die.
I would submit that this scenario is way more likely than your nutcase with a samurai sword scenario... To back up my assertion, I invite you to consider how well the US fares in terms of number of deaths caused by firearms, compared to countries that seriously restrict access to firearms. That's the real world result of your theory.
Actually, that's not so hard. If you try to decrypt an encrypted message using the wrong key, what you get out the other end looks like a randomised byte stream. If instead you see a non-random distribution of bytes, you can be pretty damn sure that you have the right key. The number of false positives from this very simple check is really quite small.
Where you do get into a bit of a mess is when you try to decrypt a compressed data stream, because compression basically tries to remove all predictability from a message - in other words, the message looks to be random. In such a case, a knowledge of the compression algorithm being used (and there aren't that many of them in use today), will quickly enable this to be taken into account.
Actually, you have to get it from your house - but make sure you climb up a really high triangle in mid-route to refreeze it, otherwise it'll melt and slip from your grasp, smashing into many pieces :-(
Which was kind of where I was going. Quantum weirdness and the speed limit on the transmission of information both make me think of the way cellular automata function.
I was listining to a podcast the other day (Escape Pod - scifi stories), and the story was about a guy that learns that his world is in a simulator, but there are bugs, especially found in an on-line game. You can make objects leave the game and appear in the "real world".
Which brings me back to the question. We live in a "real world" which exhibits at least some of the aspects that we would expect of a simulated world, and I keep wondering what sort of programming artifacts (bugs) could exist, how could we find them, and how could we exploit them...
Anyway, I don't intend to spend my life researching answers to those questions, but they seem to me to be every bit as valid for scientific research as , for example, SETI.
I mean, if even on our simpler computer systems, we are unable to simulate a computer well enough to hide the existence of the external simulator from the internal computer system, then it makes it a little difficult to believe that we could hide the fact that all of reality was being simulated, as in the case of the Matrix...
Or, maybe this work isn't really applicable philosophically.. Maybe they aren't describing a fundamental limit of the idea, but simply some problems with current implementations.
While your listing other open source kernels, don't forget about Darwin... There are probably other open source kernels floating about out there as well...
Well, I probably got here too late, but f you are looking for some texts that could be read in an English class, but which pose big scientific questions, you couldn't really go wrong with Gregory Benford - I'm thinking in particular of two of his novels, Cosm and Timescape.
Benford's hook is that he uses research scientists as his protagonists. They are typically on the verge of making a big scientific discovery with accompanying moral dilemmas (will it save/destroy the world, who should profit from it, who 'owns' the science, etc). The characters live in our real world, and the physics is all valid (well, riffing of cutting edge unproven theories, but still possible - sending messages back in time, creating mini event horizon universes etc). But most importantly, the concerns of the characters are real world concerns.
The only downside is that the books are perhaps a bit too difficult for 8th graders... Cosm might work, but Timescape definately requires high level reading skills.
No, you're making the error of treating declinaisons of words as seperate words. Jump, jumps, jumped, jumping, they're all just conjugated forms of the one word - jump. Same thing for nouns, especially in gendered languages such as French. Gelé, gelés, gelée, gelées, they all just mean 'frozen', but declined for different subjects.
If you prefer, substitute "unique verbs/adjectives/nouns" for "words" in my original post. That's how linguists count vocabulary... If you think that most people have a vocab counted this way of more than 2000 "words" you are waaaay off mark.
Again, talking about French, I live in France. The reason I only have a vocabulary of 1500 words or so is because I just don't see/hear any other words often enough to retain them. Twilight, mist and marsh for example are well and truly in my vocabulary list - they are words that you can expect to hear/read around about once a week. It's words that you encounter at less than once a month that are difficult to learn, and words that you encounter once a year are nigh on impossible to learn without making a deliberate effort to learn a bigger vocabulary - they won't get learned organically.
Your numbers there are just flat out wrong. Most English dictionaries don't have 50 000 words! For most languages, you are considered to be a fluent speaker at a vocabulary of around about 1000 words. Someone that does a fair bit of reading will probably have a vocabulary of 3-4000 words, and spelling bee freaks can probably claim about 6000 words.
I speak French as a second language, and with a vocabulary of about 1500 words, I find myself to be about the equal of most native speakers in daily conversation. I can, for example, read a novel like The Da Vinci Code in French, without ever noticing that there are words that I don't know (well, if you put aside domain-specific nouns like 'atbash' or 'cilice'). I might struggle a bit when trying to read economics reports in newspapers, or a recipe, or some other article with a specific vocabulary attached, but 1500 words is more than enough for a normal usage of a language...
What?!? You need all that? I can do it with a commander, a schizophrenic archaeologist, and a wise-cracking anti-establishment journalist.