With regards to wine tasting you are probably right regarding the rarity of the skill. It's more to do with lack of training than lack of talent in the general population, I believe however.
Tasting is very close to the sense of smell, and speaking for myself some smells bring forth very powerful memories sometimes (not always), so I do believe it is possible for some people to be very very good at tasting.
There are also stories of people affected with some temporary brain damage that suddently gave them a sense of smell as accurate as that of a dog. There is such a story in O. Sacks `the man who mistook his wife for a hat'.
For audiophiles I just don't know. Personally I can't tell the difference between a 128kb mp3 and the original CD unless I listen very very carefully yet I know a lot of people who say they can, no problem. However once I went to a (mild) audiophile's house and he made me listen to the difference between normal and top-quality RCA cables, and I thought I could hear the difference. I can *definitely* hear the difference between his rig and mine (which I bought when I was a student...).
Hearing is a wonderful thing. I know a classical professional musician friend of mine whom I was playing with a long time ago. One of us asked for a C. The guitarist obliged. And the musician friend said (from behind the guitarist) "no way, that's a B". Guitarist looks down at his instrument -- Correct, slides the finger one notch up.
However these things are like consumerism, one can never satisfy one's golden ear or tastebud, that's why some gear or some wine or some pushbikes are beyond the reach of mere mortals: because there is a demand.
There are people who can tell, having sipped a glass of wine, the grape, year and producer with total accuracy. These are not fluffy qualities, but hard facts easily verifiable. There are actually wine tasting competition along these lines.
Professional wine tasters don't get drunk, they don't swallow any of the wine. Apparently it's very bad on the teeth though.
From 1986. That beast had a 8MHz 8086 in it (not a 8088), I've upgraded the memory to 640k (the max you can get) and the CPU to a NEC V30, slightly faster and pin-compatible with the 8086. It runs MS-DOS 3.2 and lives in a piggery (litteraly), next to the machine that makes the soup for the pigs. It runs software I wrote for it years and years ago, my first production C program, written using Borland Turbo C 1.0. That program computes some growth statistics for piglets (basically the average daily weight they've gained while they were sucking their mum).
This is not a joke. It was deemed absolutely unnecessary to ever upgrade the hardware given that (a) it works and (b) it does the necessary computations in no time. The only bummer is getting the data out given it's only got a 5.25" floppy drive. We're waiting for that computer to die and it never has.
I suspect a newer PC would not last a month given the universe of grime it would live in.
> VS.NET 2003 is actually head and shoulders ahead > of g++ in terms of language compliance (g++ 3.4 > may correct this).
Are you sure about this? According to the latest Dr Dobbs Journal review of C++ compilers for Windows, g++ 3.3 has the best compliance. Do you have a specific feature in mind?
We'll see about the inevitability of what Ray Kurtzweil writes. Exponential growth are the stuff of pyramid schemes and bubbles. They all end up collapsing and deflating respectively.
Indefinite exponential growth in computing power also assume that human effort is infinitely dividable, infinite energy resources (cool those CPUs, man) and that all finite processes can easily be solved by standard computing solutions.
All of those assumptions are false. Even the last one isn't, NP-complete problems, anyone?
If/when quantum computation becomes feasible I'll reconsider that judgment.
As a rule the Nobel committee does not award prizes for theories that are hard to test. The quantum mechanists got lots of Nobel prizes because they could instantly explain structures and predict events and constants with great precision. On the other hand GRT was pretty much untestable; there was the Eddington expedition that showed that the Sun mass did bend light rays, but the classical theory predicts that as well, only the amount of bending is different (GRT predicts twice the bending of the classical theory), and the Eddington data was too cruddy to determine the amount of bending with enough precision.
Einstein should have been awarded a second Nobel after the Manhattan project, that showed the world that energy/matter conversion was a very real thing, but I guess the Nobel committee would have balked at what was really an anti-peace prize.
BTW the above is why string theorists are unlikely to be rewarded with a Nobel anytime soon.
> my time reading/. has convinced me that I don't > want to hire some hard core free software advocate
Sure, that's reasonable. Most people on/. are just OSS users, not developers though.
> And I don't really want to hire people who > aren't motivated by money.
I'm not sure OSS developers aren't motivated by money. It's relatively easy to be motivated by that!, but indeed maybe they also can be motivated by other things, like a taste for things well done, I don't know.
Interesting points you are making, however maybe the open-source project I've been working on was in fact the focus of my previous employment, i.e: it was developed on during working hours with the approval of the hierarchy. These things happen, this is in fact the case for me for example, and it is happening more and more.
The good thing about OSS projects is you can really check the proficiency of the candidate. You can look at his/her code, see if it works, if the candidate uses correct methodologies, if the documentation is written, etc.
This is extra information that the candidate is giving you that is very unlikely to come out of any classic interview. What if you found that the code is brilliant (not in my example)?
Largest project in CVS? not that huge, but ~1500 files, 400 kloc, 12 developers, so not trivial either. The biggest headache I've had in CVS is renaming, and merging of branches is a big pain, but is it really better handled in perforce?
My largest perforce project is smaller (200kloc). So far I haven't seen any huge advantage. Most little hassles like conflict are handled better in CVS I find. Maybe the big painful job I haven't experienced yet are indeed better handled in perforce.
I don't like the perforce various GUIs and web interface, I'm using the command line.
From the database and from expert knowledge you can develop consistent and checkable rules that will produce a correct diagnosis in 95% of the cases, exactly as you wrote. However you still need the expert to enter and filter the proper symptoms and other clinical signs.
The expert is a doctor, and a good doctor is pretty impressive at filtering the junk from the usable data. We are not yet at the stage where any sort of AI can emulate that, and we have made very little visible progres in the last 10-15 years in that regard.
The usefulness of automated systems lies where a doctor is not needed as an intermediary to get the input data: inside an MRI machine or a CAT scanner for example. And even in these cases you'll definitely need a second, human opinion, at least.
As an illustration there is an automated system in place in the US for helping with breast cancer regular checkups. It is the result of the largest international, both publicly and privately funded development effort over the last 10 years and is precisely in the situation that I describe above where an automated system has a chance to be useful, yet a recent audit demonstrated that it generated way too many false positive to be of any real value.
All the positives (false or otherwise) have to be checked by a human doctor. Instead of them having less work to do, they had more. And still the system is missing some cancers that humans can detect.
You are probably right in the long term, but we have a long way to go still, my friend.
I remember one of my distant colleagues, currently researcher at Harvard Medical School, telling me about his friend when he attended MIT 20 years ago. He says that his friend still occasionally wakes up in the middle of the night screaming "No, NO, Enough" or something like that. This was referred to by his wife as his `MIT nightmare', from when he was a student trying to stay afloat in the coursework.
I'd say that MIT is hard going. I thought I worked pretty hard at uni., but I was only having nightmares DURING the coursework.
What's the relationship between slackers and open source? I do my own open source software project after hours, it's something I and my co-workers use daily. It seems to me a lot of open-source people actually work very hard, meet difficult deadlines and have great work ethics.
Actually produces decent code on Solaris/sparc, it's one of the better supported platforms. Conversely I find the Sun C and C++ compilers useful in checking portability issues, but that the (small) performance difference on real application is basically a non-issue.
Finally until recently the Sun C++ compiler was very poor in terms of ISO compliance.
One word: vaporware. Maybe it will be fast, maybe not.
For the moment, notice how Intel does not publicize the integer performance of the Itanium2 very well. It's because it is not very good. Sure the FP is good, but that's not enough.
Honestly I believe the two languages will converge. Java is already used for scientific calculations for example. A few years ago that would have been unthinkable due to the non-standard floating point and the very poor speed, but both have been fixed to a tolerable extent.
Now you find Java compilers that don't require a JVM (they compile to native object code). In a few years time one will be able to write an O/S in Java.
I think the next round of C++ standardisation will include more Java-like features, such as standardized threads for example. With STL it has been possible to write good efficient C++ without using a single pointer.
I take it you've never seen an ADA program with generics or never heard of ML?
I don't understand what you mean. C++ did very well for a very long time without templates back in the days where OO was the rage. Then they were invented and made standard, and now they are useful since generic and template metaprogramming is the new fashion.
Because Java does not have templates they are not useful in that language? what kind of tautology is that?
Don't take this personnally but some time ago all the Java programmers were saying "Templates, we don't need no stinking templates!". Mind you C++ programmers were saying "Garbage collection, are you kidding, what on Earth for" at the same time.
Basically C++ and Java are going to end up pretty much the same a few years from now.
Because it forces down your throat the concept that everything is an Object. Many people find this counter-productive as object-oriented programming is only well adapted to a subclass of problems (and trying to use that methodology when it just doesn't work is downright ugly).
Besides inheriting from Object does not solve the same problem as templates do. Templates are super-macros designed for fast runtimes. Universal object orientedness with default virtual methods causes extra overhead that C++ programmers want to avoid a lot of the time.
Notice that single-object-derived libraries for C++ exist, for example the NIH library, but that they were never as successful as the STL is.
Inheriting from Object only solves the absence of multiple inheritance in Java.
Actually the 4x markup can be justified. We have had a Sun server here, hammered by hordes of scientists, that serves hundreds of GB of data, and has been doing that for 4 years with only scheduled downtimes. I'm not getting this level of reliability from my Linux box on my desk (mainly due to the crappy Nvidia driver, but anyway).
The problem for Sun is we don't need to upgrade for another couple of years.
Slashdot Mirror
With regards to wine tasting you are probably right regarding the rarity of the skill. It's more to do with lack of training than lack of talent in the general population, I believe however.
Tasting is very close to the sense of smell, and speaking for myself some smells bring forth very powerful memories sometimes (not always), so I do believe it is possible for some people to be very very good at tasting.
There are also stories of people affected with some temporary brain damage that suddently gave them a sense of smell as accurate as that of a dog. There is such a story in O. Sacks `the man who mistook his wife for a hat'.
For audiophiles I just don't know. Personally I can't tell the difference between a 128kb mp3 and the original CD unless I listen very very carefully yet I know a lot of people who say they can, no problem. However once I went to a (mild) audiophile's house and he made me listen to the difference between normal and top-quality RCA cables, and I thought I could hear the difference. I can *definitely* hear the difference between his rig and mine (which I bought when I was a student...).
Hearing is a wonderful thing. I know a classical professional musician friend of mine whom I was playing with a long time ago. One of us asked for a C. The guitarist obliged. And the musician friend said (from behind the guitarist) "no way, that's a B". Guitarist looks down at his instrument -- Correct, slides the finger one notch up.
However these things are like consumerism, one can never satisfy one's golden ear or tastebud, that's why some gear or some wine or some pushbikes are beyond the reach of mere mortals: because there is a demand.
There are people who can tell, having sipped a glass of wine, the grape, year and producer with total accuracy. These are not fluffy qualities, but hard facts easily verifiable. There are actually wine tasting competition along these lines.
Professional wine tasters don't get drunk, they don't swallow any of the wine. Apparently it's very bad on the teeth though.
How about the far huger number of people who still run Win95? Or Win3.11 for that matter. What's your point?
From 1986. That beast had a 8MHz 8086 in it (not a 8088), I've upgraded the memory to 640k (the max you can get) and the CPU to a NEC V30, slightly faster and pin-compatible with the 8086. It runs MS-DOS 3.2 and lives in a piggery (litteraly), next to the machine that makes the soup for the pigs. It runs software I wrote for it years and years ago, my first production C program, written using Borland Turbo C 1.0. That program computes some growth statistics for piglets (basically the average daily weight they've gained while they were sucking their mum).
This is not a joke. It was deemed absolutely unnecessary to ever upgrade the hardware given that (a) it works and (b) it does the necessary computations in no time. The only bummer is getting the data out given it's only got a 5.25" floppy drive. We're waiting for that computer to die and it never has.
I suspect a newer PC would not last a month given the universe of grime it would live in.
> VS.NET 2003 is actually head and shoulders ahead
> of g++ in terms of language compliance (g++ 3.4
> may correct this).
Are you sure about this? According to the latest Dr Dobbs Journal review of C++ compilers for Windows, g++ 3.3 has the best compliance. Do you have a specific feature in mind?
the Boehm GC protects you against leaks, not against buffer overflows. The latter is much worse than the former.
We'll see about the inevitability of what Ray Kurtzweil writes. Exponential growth are the stuff of pyramid schemes and bubbles. They all end up collapsing and deflating respectively.
Indefinite exponential growth in computing power also assume that human effort is infinitely dividable, infinite energy resources (cool those CPUs, man) and that all finite processes can easily be solved by standard computing solutions.
All of those assumptions are false. Even the last one isn't, NP-complete problems, anyone?
If/when quantum computation becomes feasible I'll reconsider that judgment.
As a rule the Nobel committee does not award prizes for theories that are hard to test. The quantum mechanists got lots of Nobel prizes because they could instantly explain structures and predict events and constants with great precision. On the other hand GRT was pretty much untestable; there was the Eddington expedition that showed that the Sun mass did bend light rays, but the classical theory predicts that as well, only the amount of bending is different (GRT predicts twice the bending of the classical theory), and the Eddington data was too cruddy to determine the amount of bending with enough precision.
Einstein should have been awarded a second Nobel after the Manhattan project, that showed the world that energy/matter conversion was a very real thing, but I guess the Nobel committee would have balked at what was really an anti-peace prize.
BTW the above is why string theorists are unlikely to be rewarded with a Nobel anytime soon.
> my time reading /. has convinced me that I don't
/. are just OSS users, not developers though.
> want to hire some hard core free software advocate
Sure, that's reasonable. Most people on
> And I don't really want to hire people who
> aren't motivated by money.
I'm not sure OSS developers aren't motivated by money. It's relatively easy to be motivated by that!, but indeed maybe they also can be motivated by other things, like a taste for things well done, I don't know.
Interesting points you are making, however maybe the open-source project I've been working on was in fact the focus of my previous employment, i.e: it was developed on during working hours with the approval of the hierarchy. These things happen, this is in fact the case for me for example, and it is happening more and more.
The good thing about OSS projects is you can really check the proficiency of the candidate. You can look at his/her code, see if it works, if the candidate uses correct methodologies, if the documentation is written, etc.
This is extra information that the candidate is giving you that is very unlikely to come out of any classic interview. What if you found that the code is brilliant (not in my example)?
Largest project in CVS? not that huge, but ~1500 files, 400 kloc, 12 developers, so not trivial either. The biggest headache I've had in CVS is renaming, and merging of branches is a big pain, but is it really better handled in perforce?
My largest perforce project is smaller (200kloc). So far I haven't seen any huge advantage. Most little hassles like conflict are handled better in CVS I find. Maybe the big painful job I haven't experienced yet are indeed better handled in perforce.
I don't like the perforce various GUIs and web interface, I'm using the command line.
> Diagnosing 95% of all ailments does not take
> training, it takes a good database.
Speaking as someone who developed an automated skin cancer diagnosis system, the database is the starting point, not the be-all and end-all.
From the database and from expert knowledge you can develop consistent and checkable rules that will produce a correct diagnosis in 95% of the cases, exactly as you wrote. However you still need the expert to enter and filter the proper symptoms and other clinical signs.
The expert is a doctor, and a good doctor is pretty impressive at filtering the junk from the usable data. We are not yet at the stage where any sort of AI can emulate that, and we have made very little visible progres in the last 10-15 years in that regard.
The usefulness of automated systems lies where a doctor is not needed as an intermediary to get the input data: inside an MRI machine or a CAT scanner for example. And even in these cases you'll definitely need a second, human opinion, at least.
As an illustration there is an automated system in place in the US for helping with breast cancer regular checkups. It is the result of the largest international, both publicly and privately funded development effort over the last 10 years and is precisely in the situation that I describe above where an automated system has a chance to be useful, yet a recent audit demonstrated that it generated way too many false positive to be of any real value.
All the positives (false or otherwise) have to be checked by a human doctor. Instead of them having less work to do, they had more. And still the system is missing some cancers that humans can detect.
You are probably right in the long term, but we have a long way to go still, my friend.
I remember one of my distant colleagues, currently researcher at Harvard Medical School, telling me about his friend when he attended MIT 20 years ago. He says that his friend still occasionally wakes up in the middle of the night screaming "No, NO, Enough" or something like that. This was referred to by his wife as his `MIT nightmare', from when he was a student trying to stay afloat in the coursework.
I'd say that MIT is hard going. I thought I worked pretty hard at uni., but I was only having nightmares DURING the coursework.
You can start by reading the recommended texts, some of them are really good.
Cheers.
What's the relationship between slackers and open source? I do my own open source software project after hours, it's something I and my co-workers use daily. It seems to me a lot of open-source people actually work very hard, meet difficult deadlines and have great work ethics.
What's your beef exactly?
Serious question.
I'm using both. I have almost exactly the same kind of problems and benefits with both pieces of software, only the commands differ somewhat.
What is available in perforce that is not in CVS?
Actually produces decent code on Solaris/sparc, it's one of the better supported platforms. Conversely I find the Sun C and C++ compilers useful in checking portability issues, but that the (small) performance difference on real application is basically a non-issue.
Finally until recently the Sun C++ compiler was very poor in terms of ISO compliance.
I was weaned on X and I find the ^C-^V method clumsy and slow. So who is right?
One word: vaporware. Maybe it will be fast, maybe not.
For the moment, notice how Intel does not publicize the integer performance of the Itanium2 very well. It's because it is not very good. Sure the FP is good, but that's not enough.
Thanks for the thoughtful comments.
It's not surprising it took 50 years. The dvp of nuclear weapons is still a hard task.
> What is impressive is that war has not spread like
> wildfire as it would of 50 years ago. Wars just
> don't escalate anymore.
They are not the same wars. WWI and II were between the superpowers of the time.
Honestly I believe the two languages will converge. Java is already used for scientific calculations for example. A few years ago that would have been unthinkable due to the non-standard floating point and the very poor speed, but both have been fixed to a tolerable extent.
Now you find Java compilers that don't require a JVM (they compile to native object code). In a few years time one will be able to write an O/S in Java.
I think the next round of C++ standardisation will include more Java-like features, such as standardized threads for example. With STL it has been possible to write good efficient C++ without using a single pointer.
I take it you've never seen an ADA program with generics or never heard of ML?
I don't understand what you mean. C++ did very well for a very long time without templates back in the days where OO was the rage. Then they were invented and made standard, and now they are useful since generic and template metaprogramming is the new fashion.
Because Java does not have templates they are not useful in that language? what kind of tautology is that?
Is 1.5 out yet? Can I try it?
Don't take this personnally but some time ago all the Java programmers were saying "Templates, we don't need no stinking templates!". Mind you C++ programmers were saying "Garbage collection, are you kidding, what on Earth for" at the same time.
Basically C++ and Java are going to end up pretty much the same a few years from now.
I was going to moderate, but there you go.
Because it forces down your throat the concept that everything is an Object. Many people find this counter-productive as object-oriented programming is only well adapted to a subclass of problems (and trying to use that methodology when it just doesn't work is downright ugly).
Besides inheriting from Object does not solve the same problem as templates do. Templates are super-macros designed for fast runtimes. Universal object orientedness with default virtual methods causes extra overhead that C++ programmers want to avoid a lot of the time.
Notice that single-object-derived libraries for C++ exist, for example the NIH library, but that they were never as successful as the STL is.
Inheriting from Object only solves the absence of multiple inheritance in Java.
Actually the 4x markup can be justified. We have had a Sun server here, hammered by hordes of scientists, that serves hundreds of GB of data, and has been doing that for 4 years with only scheduled downtimes. I'm not getting this level of reliability from my Linux box on my desk (mainly due to the crappy Nvidia driver, but anyway).
The problem for Sun is we don't need to upgrade for another couple of years.