Hm. First of all, let me just be clear here in saying that I am not saying that indexing is bad, or that Beagle is bad, or that you should use my search engine instead of Beagle. I just tried a search of a ten gigabyte mail folder. It took eight minutes. This is on a modern laptop with a laptop drive, but still, that's 2.2 megabytes per second, which is pretty pathetic. I would hope to get a bit closer to the drive's native speed with some optimization, of which I have so far done none - not even so basic an optimization as making sure that I'm reading ahead, and that I'm not double-copying data, much less any CPU pipeline-based optimizations.
Once those optimizations are done, some indexing might make sense, as long as it doesn't produce any false negatives. But that's really key - it has to produce no false negatives. Otherwise, a very precise search simply won't find anything. And it's difficult to produce no false negatives from an index. Consider if the search string includes the word "the". The index probably doesn't contain "the", because it's so common that it would appear in _any_ english document. There's no point in indexing "the". But if you don't, you get a false negative during the winnowing process. So you have to notice that "the" is a thing that's not indexed, and not use it to exclude any files. And then, potentially, you're left with the whole list anyway. So your indexing/winnowing has to be smart. Which is precisely why I'm doing it last.
Don't look for gofer as a replacement for spotlight on your kde desktop next week. Do look for it as a textual research tool next week.
I suspect Google does something a bit smarter than the naive indexing scheme I'm talking about. They've historically been very smart about searching. You'll get a better idea of why Google doesn't do well, though, if you try to find something relatively obscure on Google for which all the keywords you can think of are common. Google may return ten thousand matches, and the one you need could be anywhere on the list. If you have a relatively constrained source base, and you're searching for things that you know about (e.g., an email message you can recall, but you don't remember where you filed it), you can construct a good search for that relatively easily, either by restricting the location of the search or by remembering the name of the person who wrote it, for example.
However, if you are searching a domain whose contents you don't actually know, this is much harder.
For example, and index will have a pointer in it that says "acrobatic" occurs in files a, b, c, d, e and f. And the word "wombat" occurs in files c, e, k, l and m. So if you want to find the phrase "acrobatic wombat", which only occurs in file c, you're going to get either too long a list, or possibly no list at all.
Oops, I edited my point away here. In the above example, the index would actually do admirably, because both acrobatic and wombat appear in the index, and the only file that contains both is file c, which happens to contain the phrase "acrobatic wombat."
However, consider a pile of text that contains a lot of very similar phrases. There are seventeen papers on acrobats, fifteen on wombats, and twenty five that talk about both acrobats and wombats, but only one of these papers talkes about wombats who are acrobats. You want to be able to find just the one that talks about wombats who are acrobats. In an indexed search, you're probably going to find either twenty-five or fifty-seven papers in total. In a search that winnows from the index and does a full text search on what remains, you will find a single paper. So the latter is useful, and the former is useless.
Furthermore, what if you don't know the exact phrase? Maybe it's "wombats who are acrobats" and maybe it's "acrobatic wombats." You want the full-text portion of the search to find either. So if your search string is to match "acrobat wombat", you may get zero matches if the phrase in the paper is "wombats who are acrobats."
Now imagine that you are searching an entire library, and there are three books that would make good source material. And the phrase acrobat appears in ten thousand of the books in the library, and the word wombat appears in another ten thousand. Say the library contains a hundred thousand books. Searching a hundred thousand books on a computer takes only a few minutes at most, even if you do a full text search. But if you get five thousand matches, you might as well not have searched, because you're still going to have to go through five thousand synopses looking for the three books that contain what you want (and you may risk missing it, if the book doesn't mention acrobatic wombats in the synopsis).
Adding an index to a search system that can find the three books will speed up the searches. But you want the thing to find the three books before you worry about indexing, because it takes a lot longer to manually search five thousand books for a particular phrase than it does to do a full-text computer search on a hundred thousand books. Indexing before you get the search right is putting optimization before functionality.
Excessive reliance on indexing renders searching virtually useless. If you want to use searching to keep track of your files, you need to search quickly. Generally speaking, an indexed search will either find too many matches, or too few, because you can't do intelligent string matching with an indexed search - you can only search for indexed words, and of necessity the index can't store word relationships.
For example, and index will have a pointer in it that says "acrobatic" occurs in files a, b, c, d, e and f. And the word "wombat" occurs in files c, e, k, l and m. So if you want to find the phrase "acrobatic wombat", which only occurs in file c, you're going to get either too long a list, or possibly no list at all.
If the words you're searching for are rare, you can use an index to speed up the search by winnowing the list of files based on the search. However, if the words are common, chances are that most files will match, and so the time spent winnowing the file list via the index will not make any noticable difference in the search speed.
My point is not that indexing is wrong, but that it can be (and almost always is) abused to produce results that aren't very helpful. Spotlight, for example, while very cool in the abstract, almost always fails to find what I need, or finds so many things that although the thing I needed was on the list, I didn't save time by using spotlight to find it.
Screenshots are up. I realized after posting it that the above comment sounds like stealing thunder from Beagle - sorry about that. The Beagle stuff looks cool; my reason for putting this comment up was (a) to show that there is more that can be done with a search UI than merely what spotlight does, and (b) because the small subset of searchers who need the additional functionality provided in gofer and not beagle might see this and try it out or comment on it.
I'm working on a somewhat more flexible search tool for Qt/KDE right now. I'll put up some screenshots in a few minutes - I'd be interested in some insightful comments about it.
Would that it were so. In the open-source world, as with most places, things come in a variety of forms, some of them helpful source code, some of them dense clumps of impenetrable junk source code, some of them in the form of useful advice, some in the form of meaningless drivel. Caveat emptor...
If you try to push a protocol in the IETF that depends on MD5, they won't let it through, because it's too risky. So this doesn't seem like very good advice. I'd suggest using SHA256 instead.
This past weekend. I haven't tried Qt3, so I don't know if it was a drag or not, but Qt4 was dead easy. I was truly amazed.
The one thing about Qt4 that I didn't like was the widget editor, not because it was completely awful, but just because I don't like widget editors - there's always knowledge embedded in the GUI that you have to learn by guessing wrong a lot or reading more documentation than you'd have to read if you just bypassed it and went straight to coding. But compared to the GUI for MSVC/.NET Forms or Cocoa's Interface Builder, both of which I've had the misfortune to have used, even the widget editor is pretty nice.
Re:From my point of view
on
Demise of C++?
·
· Score: 4, Interesting
You're repeating some classic received knowledge about C++ that happens not to be true. I have to admit that for a long time I bought into the story that C++ was like C, only more complicated. And that C++ is fundamentally about object oriented programming.
I got over my dislike of C++ about two days ago when I decided to use Qt to do some programming, which pretty much forces you into C++. I was really shocked at how unpleasant it *wasn't*. I've had some really bad experiences with Java - a lot of "model" is forced down your throat. Using C++ felt very natural, and I noticed a huge number of really nice touches that are quite cheap, because they're done by the compiler, but that (a) make your coding less error-prone, and (b) are just horribly convenient.
So my point here is that if you've been hearing for years that C++ isn't worth your time because it's object oriented or because it's just C warmed over, neither of these statements is true. I'm embarrassed to have ever repeated them (sad to say, I have done so in the past).
I really don't think C++ is on the way out. My main complaint about it at this point is that g++ is too verbose when I use an overloaded function that doesn't exist - it prints a list of all the possible candidates, which can get quite long. I don't think that's a capital crime, though.:'}
Your argument presumes that the people who are buying HDTVs now are doing it just because they want a big TV. In some cases you will be right. The thing is, there's plenty of HDTV content at 1080i right now, it's just on-the-air content. So people who have these nice new 1080i-capable TVs will notice the difference. DVD content at 1080i can look fairly good, but very clearly it could be better. And the price of entry is a lot lower than the cost of a TV. So it seems like a safe bet that enough people will try out this new HD-DVD device to make a decent beginning of a market. Some will wait for the price to come down, and the content to become more available. And I suspect we should be looking for two-sided discs, like they used to do with regular DVDs. One side will be the DVD side; the other will be the HD-DVD side. Then you release a single disc, and it plays on either player, at the full capacity of the player.
Actually, you're wrong. I don't know of any HDTVs you can buy today that don't have HDMI input. Interest in HDTV is just beginning to materialize, because they're starting to get closer to the sweet spot in the price/performance curve. They aren't there yet, mind you, but they're close enough to there that there is a spike in HDTV purchases going on.
So unfortunately people who bought the component input TVs are SOL, but the new people who are just buying are not, and that's enough of a market to kickstart the format (or so Toshiba hopes, I am sure).
The fact that only protected content is supported is a kick in the pants; at some point it wouldn't surprise me if someone figures out a way to make a box that converts from HDMI to component for a decent price. When that happens, we'll see whether the whole "lock out early adopters" strategy really works, or whether the courts see it as being as lame as we do.
Don't hold your breath, though.:'(
Re:PatentHawk charges $125/hour
on
The Patent Epidemic
·
· Score: 2, Informative
Also, one of the problems with science reporting is that it's largely gee-whiz stuff whose intention is to entertain and alarm, because that's what attracts eyeballs. Rigorous, careful, non-sensational reporting just isn't that exciting. So if we follow science reporting in the popular press (even Science News), we are likely to have a very skewed picture of what's really going on. In particular, we're unlikely to get from the reporting what is really being asserted as the result of any particular study that's being reported on.
...is to smile politely when they say stupid things, and then deal. I would suggest that you call your bug tracking system a "todo list" and keep a copy of the code in CVS. Produce your changes out of the CVS repository. Periodically compare what's in the head of your CVS to what's deployed, and _always_ compare before you overwrite anything that's deployed from your copy. That way you get what you want, and your boss doesn't have to deal with it. Don't tell him you have it under version control - just take advantage of the fact that you do.
It's not that bad. Serve the torrent and the signature from the original site, and then the content from the torrent, and you save most of the bandwidth and have control over whether or not it's torrented. Your incentive for torrenting the content: no slashdot effect!
Not everyone is a geek. Buzzwords backed by valid arguments are at least not untrue. If these buzzwords sway some non-geeks, that's probably a good thing.
Language is mutable, not fixed. If it were fixed, abominations like "my bad" would not have slipped into it. Tragically, we are stuck with some verbed nouns; whether you like it or not, leveraged is certainly here to stay. Where do you think verbs come from, anyway?
Bind 9 isn't crap, so there would be no reason for us to say it was. It's a fine product. Its target market is different than ours, that's all.
Boo-hoo all you want about automated builds and patch distributions. I'm a big fan of keeping things simple. With BIND, I just install the.deb and I'm done. It takes about ten seconds, and it's exactly the same process as the other hundred or so packages I need on my server. A package that requires a special compile and a manual install had better be *hugely* better than any competitor.
Actually the big problem with strong passwords is that they don't do the trick. The big problem that end-users are experiencing with fraud and identity theft has to do with sites that trick them into providing authentication information that can be used elsewhere. It doesn't matter how strong your password is if you give it to someone who's going to use it against you because they were able to fool you.
To the extent that this tech makes it harder for people to install spyware on your computer, it's a help. To the extent that it serves as a piece of "what you have" to go along with your "what you know" - your password - it's going to help. That is, if it makes it hard for someone who is not you to assert that they are you simply by presenting information they have phished from you.
Unfortunately, if the hardware token is valuable enough - that is, if you have enough money to steal to make it worth stealing your computer and your passwords - physical possession of the computer will probably be sufficient to steal what you have. Fortunately, for most people the cost of stealing the computer and using the secrets it holds will be much higher than the amount of money to be made by doing so, at least if the software using the TPM actually works as advertised and makes it impossible for you to circumvent the chip's protections. So this could actually make your privacy more secure, not less secure.
Actually, I am pretty sure the reason Java apps on the desktop haven't been forthcoming is that they're so hard to install. Oh, I have to go to Sun.com and click on a license agreement? Hm, this doesn't run on my architecture? Wow, the version that shipped with my O.S. is incompatible? Oops, I'm running too recent a version? Oh no, my app doesn't integrate properly with my operating system! Gah, what's up with this weird UI that follows none of my operating system's usability guidelines?
Most of these problems are surmountable, but the idea of write once, run anywhere is a pipe dream. I had to do a bit of tweaking to deal with speed-related issues when I tried to deploy a java app, but what finally killed my attempt to use it was that regular end-users simply couldn't install the app and have it run - they had to do three different downloads to make it work, and navigate through a maze of twisty Sun web pages, all different, which changed on a monthly basis, so that I couldn't even document the process. It's a real nightmare. I finally gave up and went back to C.
None of these problems matter when you're deploying on a server; I think that is why Java has seen some success there. But for applications aimed at real end users, Java isn't there yet.
Eclipse is a development system for doing work on Java. Why would anyone waste time learning to use a tool that's so limited? In emacs, I can hack on source code in just about any programming language. Best of all, I don't have to hack Java.
Seriously, we hear all this hype about Java, but how many apps you actually use, today, on a daily basis, are written in Java? If your answer is "I dunno, I'm sure some of these apps must be written in Java," let that be a clue to you. There is no deployment story for Java, so whizzy though it may be, it's pretty much relegated to the back office for now.
I do my development in Emacs, using C, which I freely admit is a language from the Dark Ages that followed the death of Lisp. I'd love it if there really were something nicer than Emacs in which to do my development work - the Emacs UI is more than a little bit outdated, even though I am in fact running the latest CVS version. I'd love it if there were something nicer than C, too. But tragically, Eclipse and Java haven't fulfilled this wish.
Slashdot Mirror
That's what I mean by "winnowing."
Hm. First of all, let me just be clear here in saying that I am not saying that indexing is bad, or that Beagle is bad, or that you should use my search engine instead of Beagle. I just tried a search of a ten gigabyte mail folder. It took eight minutes. This is on a modern laptop with a laptop drive, but still, that's 2.2 megabytes per second, which is pretty pathetic. I would hope to get a bit closer to the drive's native speed with some optimization, of which I have so far done none - not even so basic an optimization as making sure that I'm reading ahead, and that I'm not double-copying data, much less any CPU pipeline-based optimizations.
Once those optimizations are done, some indexing might make sense, as long as it doesn't produce any false negatives. But that's really key - it has to produce no false negatives. Otherwise, a very precise search simply won't find anything. And it's difficult to produce no false negatives from an index. Consider if the search string includes the word "the". The index probably doesn't contain "the", because it's so common that it would appear in _any_ english document. There's no point in indexing "the". But if you don't, you get a false negative during the winnowing process. So you have to notice that "the" is a thing that's not indexed, and not use it to exclude any files. And then, potentially, you're left with the whole list anyway. So your indexing/winnowing has to be smart. Which is precisely why I'm doing it last.
Don't look for gofer as a replacement for spotlight on your kde desktop next week. Do look for it as a textual research tool next week.
I suspect Google does something a bit smarter than the naive indexing scheme I'm talking about. They've historically been very smart about searching. You'll get a better idea of why Google doesn't do well, though, if you try to find something relatively obscure on Google for which all the keywords you can think of are common. Google may return ten thousand matches, and the one you need could be anywhere on the list. If you have a relatively constrained source base, and you're searching for things that you know about (e.g., an email message you can recall, but you don't remember where you filed it), you can construct a good search for that relatively easily, either by restricting the location of the search or by remembering the name of the person who wrote it, for example.
However, if you are searching a domain whose contents you don't actually know, this is much harder.
Oops, I edited my point away here. In the above example, the index would actually do admirably, because both acrobatic and wombat appear in the index, and the only file that contains both is file c, which happens to contain the phrase "acrobatic wombat."
However, consider a pile of text that contains a lot of very similar phrases. There are seventeen papers on acrobats, fifteen on wombats, and twenty five that talk about both acrobats and wombats, but only one of these papers talkes about wombats who are acrobats. You want to be able to find just the one that talks about wombats who are acrobats. In an indexed search, you're probably going to find either twenty-five or fifty-seven papers in total. In a search that winnows from the index and does a full text search on what remains, you will find a single paper. So the latter is useful, and the former is useless.
Furthermore, what if you don't know the exact phrase? Maybe it's "wombats who are acrobats" and maybe it's "acrobatic wombats." You want the full-text portion of the search to find either. So if your search string is to match "acrobat wombat", you may get zero matches if the phrase in the paper is "wombats who are acrobats."
Now imagine that you are searching an entire library, and there are three books that would make good source material. And the phrase acrobat appears in ten thousand of the books in the library, and the word wombat appears in another ten thousand. Say the library contains a hundred thousand books. Searching a hundred thousand books on a computer takes only a few minutes at most, even if you do a full text search. But if you get five thousand matches, you might as well not have searched, because you're still going to have to go through five thousand synopses looking for the three books that contain what you want (and you may risk missing it, if the book doesn't mention acrobatic wombats in the synopsis).
Adding an index to a search system that can find the three books will speed up the searches. But you want the thing to find the three books before you worry about indexing, because it takes a lot longer to manually search five thousand books for a particular phrase than it does to do a full-text computer search on a hundred thousand books. Indexing before you get the search right is putting optimization before functionality.
Excessive reliance on indexing renders searching virtually useless. If you want to use searching to keep track of your files, you need to search quickly. Generally speaking, an indexed search will either find too many matches, or too few, because you can't do intelligent string matching with an indexed search - you can only search for indexed words, and of necessity the index can't store word relationships.
For example, and index will have a pointer in it that says "acrobatic" occurs in files a, b, c, d, e and f. And the word "wombat" occurs in files c, e, k, l and m. So if you want to find the phrase "acrobatic wombat", which only occurs in file c, you're going to get either too long a list, or possibly no list at all.
If the words you're searching for are rare, you can use an index to speed up the search by winnowing the list of files based on the search. However, if the words are common, chances are that most files will match, and so the time spent winnowing the file list via the index will not make any noticable difference in the search speed.
My point is not that indexing is wrong, but that it can be (and almost always is) abused to produce results that aren't very helpful. Spotlight, for example, while very cool in the abstract, almost always fails to find what I need, or finds so many things that although the thing I needed was on the list, I didn't save time by using spotlight to find it.
Screenshots are up. I realized after posting it that the above comment sounds like stealing thunder from Beagle - sorry about that. The Beagle stuff looks cool; my reason for putting this comment up was (a) to show that there is more that can be done with a search UI than merely what spotlight does, and (b) because the small subset of searchers who need the additional functionality provided in gofer and not beagle might see this and try it out or comment on it.
I'm working on a somewhat more flexible search tool for Qt/KDE right now. I'll put up some screenshots in a few minutes - I'd be interested in some insightful comments about it.
Would that it were so. In the open-source world, as with most places, things come in a variety of forms, some of them helpful source code, some of them dense clumps of impenetrable junk source code, some of them in the form of useful advice, some in the form of meaningless drivel. Caveat emptor...
If you try to push a protocol in the IETF that depends on MD5, they won't let it through, because it's too risky. So this doesn't seem like very good advice. I'd suggest using SHA256 instead.
This past weekend. I haven't tried Qt3, so I don't know if it was a drag or not, but Qt4 was dead easy. I was truly amazed.
The one thing about Qt4 that I didn't like was the widget editor, not because it was completely awful, but just because I don't like widget editors - there's always knowledge embedded in the GUI that you have to learn by guessing wrong a lot or reading more documentation than you'd have to read if you just bypassed it and went straight to coding. But compared to the GUI for MSVC/.NET Forms or Cocoa's Interface Builder, both of which I've had the misfortune to have used, even the widget editor is pretty nice.
You're repeating some classic received knowledge about C++ that happens not to be true. I have to admit that for a long time I bought into the story that C++ was like C, only more complicated. And that C++ is fundamentally about object oriented programming.
:'}
I got over my dislike of C++ about two days ago when I decided to use Qt to do some programming, which pretty much forces you into C++. I was really shocked at how unpleasant it *wasn't*. I've had some really bad experiences with Java - a lot of "model" is forced down your throat. Using C++ felt very natural, and I noticed a huge number of really nice touches that are quite cheap, because they're done by the compiler, but that (a) make your coding less error-prone, and (b) are just horribly convenient.
So my point here is that if you've been hearing for years that C++ isn't worth your time because it's object oriented or because it's just C warmed over, neither of these statements is true. I'm embarrassed to have ever repeated them (sad to say, I have done so in the past).
I really don't think C++ is on the way out. My main complaint about it at this point is that g++ is too verbose when I use an overloaded function that doesn't exist - it prints a list of all the possible candidates, which can get quite long. I don't think that's a capital crime, though.
Oh, ouch!
Your argument presumes that the people who are buying HDTVs now are doing it just because they want a big TV. In some cases you will be right. The thing is, there's plenty of HDTV content at 1080i right now, it's just on-the-air content. So people who have these nice new 1080i-capable TVs will notice the difference. DVD content at 1080i can look fairly good, but very clearly it could be better. And the price of entry is a lot lower than the cost of a TV. So it seems like a safe bet that enough people will try out this new HD-DVD device to make a decent beginning of a market. Some will wait for the price to come down, and the content to become more available. And I suspect we should be looking for two-sided discs, like they used to do with regular DVDs. One side will be the DVD side; the other will be the HD-DVD side. Then you release a single disc, and it plays on either player, at the full capacity of the player.
Actually, you're wrong. I don't know of any HDTVs you can buy today that don't have HDMI input. Interest in HDTV is just beginning to materialize, because they're starting to get closer to the sweet spot in the price/performance curve. They aren't there yet, mind you, but they're close enough to there that there is a spike in HDTV purchases going on.
:'(
So unfortunately people who bought the component input TVs are SOL, but the new people who are just buying are not, and that's enough of a market to kickstart the format (or so Toshiba hopes, I am sure).
The fact that only protected content is supported is a kick in the pants; at some point it wouldn't surprise me if someone figures out a way to make a box that converts from HDMI to component for a decent price. When that happens, we'll see whether the whole "lock out early adopters" strategy really works, or whether the courts see it as being as lame as we do.
Don't hold your breath, though.
Apple licensed the GUI concept from Xerox.
Also, one of the problems with science reporting is that it's largely gee-whiz stuff whose intention is to entertain and alarm, because that's what attracts eyeballs. Rigorous, careful, non-sensational reporting just isn't that exciting. So if we follow science reporting in the popular press (even Science News), we are likely to have a very skewed picture of what's really going on. In particular, we're unlikely to get from the reporting what is really being asserted as the result of any particular study that's being reported on.
...is to smile politely when they say stupid things, and then deal. I would suggest that you call your bug tracking system a "todo list" and keep a copy of the code in CVS. Produce your changes out of the CVS repository. Periodically compare what's in the head of your CVS to what's deployed, and _always_ compare before you overwrite anything that's deployed from your copy. That way you get what you want, and your boss doesn't have to deal with it. Don't tell him you have it under version control - just take advantage of the fact that you do.
It's not that bad. Serve the torrent and the signature from the original site, and then the content from the torrent, and you save most of the bandwidth and have control over whether or not it's torrented. Your incentive for torrenting the content: no slashdot effect!
Not everyone is a geek. Buzzwords backed by valid arguments are at least not untrue. If these buzzwords sway some non-geeks, that's probably a good thing.
Language is mutable, not fixed. If it were fixed, abominations like "my bad" would not have slipped into it. Tragically, we are stuck with some verbed nouns; whether you like it or not, leveraged is certainly here to stay. Where do you think verbs come from, anyway?
Bind 9 isn't crap, so there would be no reason for us to say it was. It's a fine product. Its target market is different than ours, that's all.
.deb and I'm done. It takes about ten seconds, and it's exactly the same process as the other hundred or so packages I need on my server. A package that requires a special compile and a manual install had better be *hugely* better than any competitor.
Boo-hoo all you want about automated builds and patch distributions. I'm a big fan of keeping things simple. With BIND, I just install the
Actually the big problem with strong passwords is that they don't do the trick. The big problem that end-users are experiencing with fraud and identity theft has to do with sites that trick them into providing authentication information that can be used elsewhere. It doesn't matter how strong your password is if you give it to someone who's going to use it against you because they were able to fool you.
To the extent that this tech makes it harder for people to install spyware on your computer, it's a help. To the extent that it serves as a piece of "what you have" to go along with your "what you know" - your password - it's going to help. That is, if it makes it hard for someone who is not you to assert that they are you simply by presenting information they have phished from you.
Unfortunately, if the hardware token is valuable enough - that is, if you have enough money to steal to make it worth stealing your computer and your passwords - physical possession of the computer will probably be sufficient to steal what you have. Fortunately, for most people the cost of stealing the computer and using the secrets it holds will be much higher than the amount of money to be made by doing so, at least if the software using the TPM actually works as advertised and makes it impossible for you to circumvent the chip's protections. So this could actually make your privacy more secure, not less secure.
Actually, I am pretty sure the reason Java apps on the desktop haven't been forthcoming is that they're so hard to install. Oh, I have to go to Sun.com and click on a license agreement? Hm, this doesn't run on my architecture? Wow, the version that shipped with my O.S. is incompatible? Oops, I'm running too recent a version? Oh no, my app doesn't integrate properly with my operating system! Gah, what's up with this weird UI that follows none of my operating system's usability guidelines?
Most of these problems are surmountable, but the idea of write once, run anywhere is a pipe dream. I had to do a bit of tweaking to deal with speed-related issues when I tried to deploy a java app, but what finally killed my attempt to use it was that regular end-users simply couldn't install the app and have it run - they had to do three different downloads to make it work, and navigate through a maze of twisty Sun web pages, all different, which changed on a monthly basis, so that I couldn't even document the process. It's a real nightmare. I finally gave up and went back to C.
None of these problems matter when you're deploying on a server; I think that is why Java has seen some success there. But for applications aimed at real end users, Java isn't there yet.
Eclipse is a development system for doing work on Java. Why would anyone waste time learning to use a tool that's so limited? In emacs, I can hack on source code in just about any programming language. Best of all, I don't have to hack Java.
Seriously, we hear all this hype about Java, but how many apps you actually use, today, on a daily basis, are written in Java? If your answer is "I dunno, I'm sure some of these apps must be written in Java," let that be a clue to you. There is no deployment story for Java, so whizzy though it may be, it's pretty much relegated to the back office for now.
I do my development in Emacs, using C, which I freely admit is a language from the Dark Ages that followed the death of Lisp. I'd love it if there really were something nicer than Emacs in which to do my development work - the Emacs UI is more than a little bit outdated, even though I am in fact running the latest CVS version. I'd love it if there were something nicer than C, too. But tragically, Eclipse and Java haven't fulfilled this wish.
Wow, people actually still buy music in stores?