This is quite simply not true, and even a cursory examination of the products on the shelves of your local grocery or department store will disabuse you of this utopian notion pretty quickly. Price and quality are important, but it is arguable whether they are the most important factors in the success of a product, and quality is largely subjective anyway.
I'd say that technical advancement only loses significance when the target market can no longer percieve the advancements. Then marketing takes over.
Take soda, for example. It's water with a little sugar and some bubbles of carbon dioxide in it, and a tiny bit of artificial flavoring and coloring in it. There's no real technical or functional differentiation in the market, nor can there really be. The only thing left to do is to try to influence people -- you can't make a better product.
(Actually, I think you could -- I wish I could get a soda that has about half the carbonation, a lot less sugar, and stronger flavor...but such is life. Some birch beers are okay.)
I've heard the same excuse used to justify the use of email spam. It doesn't hold water. "Oh, we didn't know about *that*! Gosh, our silly little marketing contractors are just running amuck! Well, trust us -- they're the bad eggs, and *we* are the good guys!"
I care because it appeared to me that Google was saying that it did one thing, and was actually doing something else. I don't care if they modify their search results, as long as they don't claim otherwise.
Seems to me that they posted pretty clearly what they were doing.
That's like if Microsoft decided to cut off sales of Windows SDKs to an application software vendor who it decided didn't play by the rules... but of course, they're free to develop desktop applications for other operating systems.
I'm amazed by the hordes of people who like Google-bashing. Nope. Microsoft has constructed a high barrier to entry in their market. You have to overcome application compatibility, user retraining, and lack of Microsoft applications (which means your business documents aren't necessarily compatible).
Google is a search engine. Going to Google is going to a website. If they get even slightly less good than someone else, users can easily go elsewhere -- as evidenced by how quickly Google took over from Yahoo and Altavista.
Google isn't shafting users here. They are working to provide incentive *not* to hire search engine spammers and keep information useful. If the alternative is letting me get shafted by search engine spammers, Google is doing the right thing.
If they provide a clear set of rules, spammers will work up to the very edge of them. If they simply let people know that severe, repeated abuse will result in a penalization in their own database, they reduce spam in their database. I'm all for this move.
Google 's job is to search and report what it finds, not to act as the earth's police!
Google's job is to get me useful information.
This makes Google's interests and my interests very well aligned.
The job of SEOers is to prevent me from getting useful information. Google just sent a severe smack out towards people using SEOers. I'm cheering all the way.
Tell you what. You don't like it, you can go set up a search engine that *advocates* abuse by SEOers, and try and get people to use that. Have fun.
Re:Although this seems "reasonable" in light of th
on
Google Delists BMW-Germany
·
· Score: 4, Insightful
This brings up some thorny issues in my mind. Google is now dictating the way we must design our sites if we want to even hope to get a decent google rank.
And this differs from any other search engine index since the dawn of time how? Any search engine uses some kind of ranking algorithm. It used to be that stuffing keywords in page titles affected it. That was a bad idea.
Google, like any other search engine has a primary customer to keep happy: me. I use their search engine to find useful data. Google does a much better job at solving *my* problems than any of their competitors. Great. I don't care even a little tiny bit about whether or not BMW is irritated about the fact that they hired some slimy SEO bastards and got smacked for it. Google is continuing to deliver useful content to *me*. If Google does a bad job of that, I'll use another search engine...but you know what? Google is still lightyears ahead of the competition. They *still* have a lighter-weight interface than the competition (which apparently still hasn't figured out that portals are not a replacement for search engines). They still do a good job of getting useful data, despite being the Big Dog that all the search engine spammers are gunning for.
More power to Google -- for making *my* life better.
I think that if I were Google, and sufficiently irritated by BMW, I'd just provide a free adword for "BMW" to, say, a BMW competitor saying "Better than BMW".
"The order and contents of Google search results are completely automated. No one hand picks a particular result for a given search query, nor does Google ever insert jokes or send messages by changing the order of results."
Why do you care?
I mean, I think that it's more *efficient* not to involve humans (a la Yahoo), and it certainly scales better, but, hell, if Google needs a stopgap solution or thinks that it will keep a couple of major websites from not trying to spam searchengines, great.
Also, if it keeps a few more slimy assholes from being able to pay rent by spamming search engines, even better.
...and rampant intake of GE food I think I'll give it a miss thanks.
You do realize that the only reason that there's opposition to GE food is because the US biotech industry spent a lot more on developing GE food than anyone else did, and the European agricultural industry spend a great deal of money smearing GE food (out of concern that US biotech would start siphoning off their agricultural industry)?
Opposing GE is simply being a Luddite, because GE is nothing more than a technology. You're hating technology for technology's sake because some marketer wants you to do so. If you've got a problem with something specific, maybe a policy related to GE or some additive to a food, that's reasonable. But simply flat-out disliking GE is silly.
One thing though, I got sick of the constant crap in C++ just spending more time on the stupid COM plumbing and myriad datatypes than actual applications work.
I think that a lot of the reason people like C#/.NET is because COM sucks, not because C++ necessarily sucks...
Oh, yeah. The other thing that really drives me bonkers about Visual Studio is that it doesn't support C99, which has a hell of a lot of useful features. I mean, Christ, the spec has been out forever and Visual Studio *still* doesn't support it. Gah.
The only people who would dispute the superiority of Visual Studio, C# and ASP.NET would be those who've never spent more than 2 hours in any of them.
I dunno. I agree that if you don't have conflicting language requirements, C# would be a superior alternative to VB. However, I've found the Visual Studio IDE to be frusteratingly buggy -- I work in my source tree on a remote CIFS share (which is the only possible unusual thing I can think of), and VS 2003 hangs, crashes, and has a tendency to stop being able to modify its.pdb files inexplicably. I'm running a stock system+ClearCase, and IT's applied all available VS updates. This contrasts sharply with emacs, which just plain doesn't crash on me.
I can only think of a few things that I'd say are really in VS's favor compared to gcc/emacs:
* Intellisense is nicer than emacs's completion system -- it has a lot of language-specific knowledge.
* The source code colorization system in VS is faster. I use lazy font lock under emacs (so colorization happens in the background), but it's still noticeable on large files. I've heard that this is because emacs uses regexes for colorization and VS uses a full parse tree, but I've no idea as to the truth of this.
* I've never used it, but I know a few people who really like the ability to modify running code at the source level.
On the other hand, there are a lot of things that really frusterate me:
* It's sluggish. I use VS locally on my P4, 1GB of RAM machine. I have a P3 Linux box sitting by my desk (used by three people and with only 128MB of RAM). I use both VS on the Windows box and emacs over X11 to the Windows box for editing. VS has these fits where it just sits in "Not Responding" mode for ages, especially when I switch back to VS after working in another window for a while. Emacs doesn't do that.
* It's buggy. I've seen crashes, hangs, and what seems to be problems with file locking of symbol files. This is really frusterating (especially since the symbol file problem manifests itself as silently ignoring breakpoints until the next VS restart).
* VS's editor isn't too great for a serious user. VS has an okay basic code editor, but it has dialog boxes to deal with, makes you use the mouse to get around a fair amount of the time (when I'm developing with screen + gdb + emacs, I never touch the mouse), isn't as easy (for me at least) to automate, and requires you to have multiple instances open to work with multiple solution files. I can use a twin-pane emacs just fine on an eighty-column terminal, but I often feel cramped with the number of panes I have to have open (and can't switch between with the keyboard) in VS on even dual 20" monitors.
* VS isn't portable. If you learn emacs once, you can use it *everywhere*, for every task. I'm currently developing code for WinCE, Win32, and Linux. If you want to use Visual Studio, as best as I can tell, you have to use VS under Win32, VS Embedded under WinCE (which seems to have more resemblance in interface to VS6 than VS.NET), and something totally different under Linux. I've used emacs under Mac OS, Linux, and Windows, and the environment is the same everywhere -- I don't have to throw out knowledge.
* VS seems to keep losing features (or at least have them segregated into higher-priced products). Profiling was apparently in VS6 (according to our local VS6 guru), but seems to have split off into the Enterprise Edition of VS.NET. I do a lot of debugging under Linux because I have the excellent valgrind freely available there, whereas VS lacks anything similar out of box (my experiences with Boundschecker involved two weeks of getting it to intermittently work before I finally gave up in frusteration -- I may have to try Purify).
* Sometimes VS's debugger slows to a *crawl* and takes quite a while when expanding certain complex data structures. I've no idea what it's internally doing. GDB deals with the same data structures fine.
Anyhow, I think.NET suffers from the same mentality. Sure, I've played with it a bit. It was very simple to jump into C# from Java, they had a fairly rich set of core libraries. Microsoft keeps pitching it as 'easy' and I suspect there are too many folks krufting out C# apps rather than crafting them, thus my perception is this new framework does not have a high enough barrier of entry. My assumption is the money will follow the same pattern. That, and the.NET framework is also a bit young. I've worked with a lot of companies, and those few who are making the jump to.NET started in 2005/2004. No 'bleeding edge' bonus money over other platforms/frameworks. Why would I move to it?
I know a lot of people who have the same frusteration over a lowered barrier to entry. Making something outright *easier* is just better (no sense in having to blow lots of time making people learn something unnecessary), but there is a problem when it's easy to enter a field but hard to perform in the field competently.
I've known a few people (who I consider to be overreacting) who actually dislike use of debuggers, because they feel that it makes people less likely to actually properly think through what they are developing. It lowers the barrier to entry a lot, and that the cost of that loss of a filter causes more harm than the overall benefits. One of these people is Linus Torvalds. Another is my current boss. While I think that they both go too far, there is a sizeable kernel of truth.
I think that the single largest irritation I have with some of the newer platforms is that they greatly lower the barrier to entry with threads (see my.sig). Traditionally, it was a pain in the ass to write a simple preemptively-multithreaded program. Java and.NET make it *much* easier to write that hello world thread program.
The problem is that the syntax you must use and some trivial knowledge about what is safe to do and what isn't in a language or on a platform is the tiniest part of what must be known to correctly multithread a program. You *must understand how to correctly do multithreaded design* from the standpoint of designing a program. This is not easy to do correctly, and it's easy to take "shortcuts" that then come back and bite one in the ass. I would say that I have known maybe three or four people that I would trust to correctly write preemptively multithreaded systems that I'd be willing to trust my life to -- and in every single one of their cases, I've found nasty design-level bugs in their threaded or distributed designs that probably would not have cropped up in a simple single-threaded design.
Multithreading a a system has exactly two legitimate uses:
(1) Increasing performance. Unless you have a very specialized system designed for parallel processing, you are probably talking about possibly a factor of two speedup on a typical multiprocessor system. The problem is that a factor of two is *nothing*. You have a limited amount of development time T in which to make your application perform as quickly as possible. It's almost always possible to redesign such a system's higher-level logic (precompute, cache to avoid recomputation, better algorithms, whatever) to get at *least* a factor of two speed improvement on a CPU-bound application, and doing so is almost always cheaper in terms of development time than multithreading an application. Multithreading is damned expensive in terms of development time and debugging time. It makes profiling much more difficult. It is *not* immediately clear to a reader of your code what assumptions you make about the threading model; we developed data hiding for defining how data must be touched, but we have no good way at the language level for defining guarantees about how threads must interact. Result: you waste a lot of time for minimal performance gain.
I have led teams to build both the 30th and the 60th busiest sites on the web for a former client - all.Net/ C#. It works.
Paul Graham wrote Yahoo! Stores in Lisp. Should we all be running back frantically to Lisp books and pulling them out because Lisp is the latest and greatest thing going?
I agree that C#/.NET is solid, feel that it is technically nicer than the other high-level alternatives for Windows-based development. It's certainly not something I'd denigrate. But on the other hand, Java is also fine. Plenty of people are also write software in Perl, Python, what-have-you.
If you know C#/.NET well and happen to live in NYC, hey, great, maybe it's worth doing some salary renegotiation or looking around at other opportunities. But it'd just be silly to drop your expert-level embedded development experience or your knowlege in building JITs for JVMs or whatever, get a C#/.NET book and move to NYC, you know?
who would have taught few years ago that Java programmers be a dying breed?
There are no "dying breeds" in the sense that you can't do work and get recompensed. Hell, if you *want* to build a web application in Fortran77 (it's just that it's probably kind of a pain in the ass), you can run out and do exactly that. Sure, not a very high *percentage* of people developing software anymore are going to be coding in F77, but the market's also expanded an awful lot from back when Fortran was the hottest thing going.
I keep seeing these various articles from the IT press about how "X" is the hot new area. [snort] If that area was the only place to be, developers would be skipping from language to language and technology to technology every two years (and never gain *any* aptitude in the area). In the grand scheme of things, most IT press have about a two out of ten on the cluefulness meter (I remember seeing one once directly rip a guess of mine as to the rate of Linux desktop adoption and slap it into a report, presented it as if it had research backing it), and about a one out of ten on the integrity meter ("Houston is a *great* place to live and work! It's the new hot center for highly-paid developers! -- I don't have *any* incentives being paid me by Houston business interests, no!")
I like developing in C, and I don't seem to have any trouble running work that needs to be done in (or can be done in) C. Unless you are specifically working for someone or a customer that has a precise language requirement and refuse to work anywhere else, you can do work in pretty much any language. Hell, Paul Graham is still out there using Lisp as a website backend...
My take is that the best way for one to make a good salary and have a good job is to learn a particular useful skillset really in-depth, ignore what Bob the Tech Journalist is screaming about being the latest hotness, and trust your own judgement as to what's technically sound.
And Slashdot runs plenty of "the sky is falling" articles about IT and the software development industry. One day, an article will claim that all software development is going to vanish to India. The next day, Microsoft is going to take over with.NET. The next day, only senior developers with experience can get jobs, and the day after, junior coders are taking away all the highly-paid jobs. The day after, something else. After you've gone through twenty or so claimed crises for the IT industry on Slashdot's front page, you kind of mellow out and just grin and go on your way when you see articles of this sort.
Actually, this article isn't even really *negative*. It just implies that we should be dropping everything and checking out.NET.:-)
Can anyone provide a pointer to a page that has a real, informed discussion of what exactly the hell the DRM stuff in the GPLv3 draft translates to?
I've read the license, and I'm not certain enough to the point that I can constructively comment.
My initial understanding was that:
* it simply affected the GPLed software (and thus, "not subject other works to" were derived works), and was an attempt to keep the DMCA from being used as an end-run around distribution and modification of GPL software. The rationale was that DRM devices cannot be circumvented, and that a company could release GPL code but still not allow it to be modified.
This reading I wholeheartedly agree with -- if the DMCA is really a loophole that allows someone to prevent modification and redistribution of GPL software, then I want this clause.
Next, I heard a reading that is something like the following:
* This is an attempt to eliminate DRM. GPLv3 software cannot be used in any device that implements DRM (whether or not the GPLv3 software is involved in DRM).
This, I think, is stupid. Not only do I just not have a fundamental problem with DRM (as long as I can freely produce *non-DRMed works*...which, irritatingly enough, I cannot for game consoles), but I don't think that the GPL is an appropriate place to go after DRM. If the DMCA is stupid, the problem should be to repeal the DMCA. I don't really want Stallman trying to use the work of many, many people who agreed to use the GPL with the understanding that it would remain ideologically the same from version to version to attack something else that he doesn't like. I don't oppose use of my GPLed software in weapons, DRM-using devices, or anything else like that.
The difference between the first and second reading is that the first just states that it is not permissible to use DMCA's anticircumvention clause to prevent modification of GPLed software. The second actively prevents GPLed software from being used to implement a device that contains DRM.
I would also argue that the second is far, far too broad. PCs have TCPA. There is nothing inherently *broken* about TCPA, as long as I can still run Linux and free works on my system. Does this mean that now the GPLed BIOSes out there that people are working on cannot be used on TCPA systems? This is, I think, unacceptable.
Basically, here's my take. I think that a lot of techies with Windows are pissy over the fact that non-techies used to subsidize their game habit (non-techies didn't know how to pirate games, techies did), and now DRM threatens to eliminate their free, subsidized product. I think that a lot of these folks size onto DRM as "freedom-limiting" because it allows them to eliminate dissonance with their unhappiness with the introduction of DRM, and the lack of another justification. Frankly, while I can understand that it might be frusterating for a teen who used to be able to play every game on the market to suddenly be limited to a fraction, it just isn't worthy tainting something as important as the GPL to fight DRM:
(a) It's a good thing for said teen. The only assets a teen has is time. Blowing it on games screws him over than anyone else. Games are damn addictive today.
(b) It just isn't a "freedom" that I'm worried about. It's not political free speech. DRM does not violate any of the fundamental rights put in place to allow government and society to continue functioning without breaking down. It *does* mean that maybe some new works cannot be manipulated for a certain period of time (I *do* think that copyright time lengths last *far* too long, and that much of the frusteration over this fact and our inability to get them shortened is translating into the irritation over DRM -- people felt that they could just *ignore* copyright if they couldn't properly adjust the rules to something sane. This is not, IMHO, a good fix.)
I've cracked an awful lot of software in my time, and pirated plenty of movies and music, and been a co
Unless this product gets a lot more concrete and directed, I don't know who is going to buy it.
I can see use for an "automated services" system like this -- patching problems, looking for malware, updating software, providing a link to toll tech support for your computer, etc.
Currently, you can cobble together something for your Windows-using relatives with AdAware, some sort of virus scanner, occasionally (maybe once a year) dropping by to update software and having them call you when things break. But that's a pain, and very wasteful of time, since a lot of these issues are common to a lot of people.
The answer is to get experts in the field involved in examining patents before they are "rubber stamped". If people that knew what they were talking about technically (and preferablly leaglly too) were involved in deciding if a patent was valid or not, we wouldnt see so many crappy patents.
Too expensive. What would it cost to get good computer scientists doing something not-so-fun as examining patent applications?
Maybe make it part of a deal -- "get your PhD on a government scholarship, but spend part of your time for the next couple years doing patent review"?
Also, introduce a clause in the rules that says that if a patent is found invalid (either in the initial investigation or later on by a court), the patent holder has to pay up to the PTO.
I'd like that, but I'm not under any illusions as to this working. First, patent filers would protest -- they're being subjected to risk for an impossible search (I agree that the search for conflicting work is impossible, which is part of the reason that I dislike the existing legal minefield where anyone might accidentally infringe on a patent for doing perfectly straightforward work). Second, how much does the patent holder pay? Microsoft doesn't care if it has to pay $10K. It paid more in fees to its in-house lawyers to get the patent pushed through in the first place. On the other hand, Joe the Independent Inventor working out of a garage may see $5K as a harsh blow to his finances.
The idea of "you have to demonstrate your patent somehow" (e.g. for a patent on something like an encryption algorithim, you have to demonstrate working code for it) would also help.
Yes. There is very little reason that I can think of for this not to be a requirement. I don't think that it solves much, though -- my concern is not people filing impossible patents or patents that are very difficult for those people to implement, but simply taking areas of ideas and holding monopolies over them without then returning advances in technology that would not have otherwise been made.
I'm just waiting for someone who knows networks well enough to put out a $300-400 box with a wireless adapter that does all the configuration and routing necessary to automatically hook me up to any *other* boxes in range. If anyone else gets another machine hooked up to the network, that router gets pulled in too. If a hard line is present, that line is used in preference to wireless.
Now, there are problems. This is a *hard* security problem -- there are lots of ways that someone could attack or DoS a system like this. You're talking about peer-to-peer routing, which could be asking for problems -- but peer-to-peer file transfer would have seem pretty farfetched and abusable just a couple of years ago too.
If Average Joe can get on his citywide network by just buying a box and plugging it in (and then see his city webpage and stream video and transfer data at high speed with anyone else in town), then life is good. Every person has incentive to become a node, and every person on the network increases the value of the network. Point is, what Average Joe needs is network expertise packaged, not the running of some cables. It's not hard to plug in and turn on a wireless router, and not much harder to run a cable or two. It *is* hard to have enough network administration knowledge to set up and maintain something like this -- it has to be zero-maintence and configuration.
The problems that have to be solved with this are almost entirely network-security related. It's not hard to make a zero-configuration Linux router, and lots of people already do so. It's a little more difficult to make a system that can't be DoSed by any jackass that connects to the system.
Slashdot Mirror
This is quite simply not true, and even a cursory examination of the products on the shelves of your local grocery or department store will disabuse you of this utopian notion pretty quickly. Price and quality are important, but it is arguable whether they are the most important factors in the success of a product, and quality is largely subjective anyway.
I'd say that technical advancement only loses significance when the target market can no longer percieve the advancements. Then marketing takes over.
Take soda, for example. It's water with a little sugar and some bubbles of carbon dioxide in it, and a tiny bit of artificial flavoring and coloring in it. There's no real technical or functional differentiation in the market, nor can there really be. The only thing left to do is to try to influence people -- you can't make a better product.
(Actually, I think you could -- I wish I could get a soda that has about half the carbonation, a lot less sugar, and stronger flavor...but such is life. Some birch beers are okay.)
I've heard the same excuse used to justify the use of email spam. It doesn't hold water. "Oh, we didn't know about *that*! Gosh, our silly little marketing contractors are just running amuck! Well, trust us -- they're the bad eggs, and *we* are the good guys!"
I care because it appeared to me that Google was saying that it did one thing, and was actually doing something else. I don't care if they modify their search results, as long as they don't claim otherwise.
Seems to me that they posted pretty clearly what they were doing.
That's like if Microsoft decided to cut off sales of Windows SDKs to an application software vendor who it decided didn't play by the rules... but of course, they're free to develop desktop applications for other operating systems.
I'm amazed by the hordes of people who like Google-bashing. Nope. Microsoft has constructed a high barrier to entry in their market. You have to overcome application compatibility, user retraining, and lack of Microsoft applications (which means your business documents aren't necessarily compatible).
Google is a search engine. Going to Google is going to a website. If they get even slightly less good than someone else, users can easily go elsewhere -- as evidenced by how quickly Google took over from Yahoo and Altavista.
Google isn't shafting users here. They are working to provide incentive *not* to hire search engine spammers and keep information useful. If the alternative is letting me get shafted by search engine spammers, Google is doing the right thing.
If they provide a clear set of rules, spammers will work up to the very edge of them. If they simply let people know that severe, repeated abuse will result in a penalization in their own database, they reduce spam in their database. I'm all for this move.
Google 's job is to search and report what it finds, not to act as the earth's police!
Google's job is to get me useful information.
This makes Google's interests and my interests very well aligned.
The job of SEOers is to prevent me from getting useful information. Google just sent a severe smack out towards people using SEOers. I'm cheering all the way.
Tell you what. You don't like it, you can go set up a search engine that *advocates* abuse by SEOers, and try and get people to use that. Have fun.
This brings up some thorny issues in my mind. Google is now dictating the way we must design our sites if we want to even hope to get a decent google rank.
And this differs from any other search engine index since the dawn of time how? Any search engine uses some kind of ranking algorithm. It used to be that stuffing keywords in page titles affected it. That was a bad idea.
Google, like any other search engine has a primary customer to keep happy: me. I use their search engine to find useful data. Google does a much better job at solving *my* problems than any of their competitors. Great. I don't care even a little tiny bit about whether or not BMW is irritated about the fact that they hired some slimy SEO bastards and got smacked for it. Google is continuing to deliver useful content to *me*. If Google does a bad job of that, I'll use another search engine...but you know what? Google is still lightyears ahead of the competition. They *still* have a lighter-weight interface than the competition (which apparently still hasn't figured out that portals are not a replacement for search engines). They still do a good job of getting useful data, despite being the Big Dog that all the search engine spammers are gunning for.
More power to Google -- for making *my* life better.
I think that if I were Google, and sufficiently irritated by BMW, I'd just provide a free adword for "BMW" to, say, a BMW competitor saying "Better than BMW".
"The order and contents of Google search results are completely automated. No one hand picks a particular result for a given search query, nor does Google ever insert jokes or send messages by changing the order of results."
Why do you care?
I mean, I think that it's more *efficient* not to involve humans (a la Yahoo), and it certainly scales better, but, hell, if Google needs a stopgap solution or thinks that it will keep a couple of major websites from not trying to spam searchengines, great.
Also, if it keeps a few more slimy assholes from being able to pay rent by spamming search engines, even better.
Why do people even bother to call it "SEO" instead of "spam"?
...and rampant intake of GE food I think I'll give it a miss thanks.
You do realize that the only reason that there's opposition to GE food is because the US biotech industry spent a lot more on developing GE food than anyone else did, and the European agricultural industry spend a great deal of money smearing GE food (out of concern that US biotech would start siphoning off their agricultural industry)?
Opposing GE is simply being a Luddite, because GE is nothing more than a technology. You're hating technology for technology's sake because some marketer wants you to do so. If you've got a problem with something specific, maybe a policy related to GE or some additive to a food, that's reasonable. But simply flat-out disliking GE is silly.
...and we wrote everything else ourselves.
:-)
A sure sign of quality.
One thing though, I got sick of the constant crap in C++ just spending more time on the stupid COM plumbing and myriad datatypes than actual applications work.
I think that a lot of the reason people like C#/.NET is because COM sucks, not because C++ necessarily sucks...
Oh, yeah. The other thing that really drives me bonkers about Visual Studio is that it doesn't support C99, which has a hell of a lot of useful features. I mean, Christ, the spec has been out forever and Visual Studio *still* doesn't support it. Gah.
The only people who would dispute the superiority of Visual Studio, C# and ASP.NET would be those who've never spent more than 2 hours in any of them.
.pdb files inexplicably. I'm running a stock system+ClearCase, and IT's applied all available VS updates. This contrasts sharply with emacs, which just plain doesn't crash on me.
.NET), and something totally different under Linux. I've used emacs under Mac OS, Linux, and Windows, and the environment is the same everywhere -- I don't have to throw out knowledge.
.NET. I do a lot of debugging under Linux because I have the excellent valgrind freely available there, whereas VS lacks anything similar out of box (my experiences with Boundschecker involved two weeks of getting it to intermittently work before I finally gave up in frusteration -- I may have to try Purify).
I dunno. I agree that if you don't have conflicting language requirements, C# would be a superior alternative to VB. However, I've found the Visual Studio IDE to be frusteratingly buggy -- I work in my source tree on a remote CIFS share (which is the only possible unusual thing I can think of), and VS 2003 hangs, crashes, and has a tendency to stop being able to modify its
I can only think of a few things that I'd say are really in VS's favor compared to gcc/emacs:
* Intellisense is nicer than emacs's completion system -- it has a lot of language-specific knowledge.
* The source code colorization system in VS is faster. I use lazy font lock under emacs (so colorization happens in the background), but it's still noticeable on large files. I've heard that this is because emacs uses regexes for colorization and VS uses a full parse tree, but I've no idea as to the truth of this.
* I've never used it, but I know a few people who really like the ability to modify running code at the source level.
On the other hand, there are a lot of things that really frusterate me:
* It's sluggish. I use VS locally on my P4, 1GB of RAM machine. I have a P3 Linux box sitting by my desk (used by three people and with only 128MB of RAM). I use both VS on the Windows box and emacs over X11 to the Windows box for editing. VS has these fits where it just sits in "Not Responding" mode for ages, especially when I switch back to VS after working in another window for a while. Emacs doesn't do that.
* It's buggy. I've seen crashes, hangs, and what seems to be problems with file locking of symbol files. This is really frusterating (especially since the symbol file problem manifests itself as silently ignoring breakpoints until the next VS restart).
* VS's editor isn't too great for a serious user. VS has an okay basic code editor, but it has dialog boxes to deal with, makes you use the mouse to get around a fair amount of the time (when I'm developing with screen + gdb + emacs, I never touch the mouse), isn't as easy (for me at least) to automate, and requires you to have multiple instances open to work with multiple solution files. I can use a twin-pane emacs just fine on an eighty-column terminal, but I often feel cramped with the number of panes I have to have open (and can't switch between with the keyboard) in VS on even dual 20" monitors.
* VS isn't portable. If you learn emacs once, you can use it *everywhere*, for every task. I'm currently developing code for WinCE, Win32, and Linux. If you want to use Visual Studio, as best as I can tell, you have to use VS under Win32, VS Embedded under WinCE (which seems to have more resemblance in interface to VS6 than VS
* VS seems to keep losing features (or at least have them segregated into higher-priced products). Profiling was apparently in VS6 (according to our local VS6 guru), but seems to have split off into the Enterprise Edition of VS
* Sometimes VS's debugger slows to a *crawl* and takes quite a while when expanding certain complex data structures. I've no idea what it's internally doing. GDB deals with the same data structures fine.
Anyhow, I think .NET suffers from the same mentality. Sure, I've played with it a bit. It was very simple to jump into C# from Java, they had a fairly rich set of core libraries. Microsoft keeps pitching it as 'easy' and I suspect there are too many folks krufting out C# apps rather than crafting them, thus my perception is this new framework does not have a high enough barrier of entry. My assumption is the money will follow the same pattern. That, and the .NET framework is also a bit young. I've worked with a lot of companies, and those few who are making the jump to .NET started in 2005/2004. No 'bleeding edge' bonus money over other platforms/frameworks. Why would I move to it?
.sig). Traditionally, it was a pain in the ass to write a simple preemptively-multithreaded program. Java and .NET make it *much* easier to write that hello world thread program.
I know a lot of people who have the same frusteration over a lowered barrier to entry. Making something outright *easier* is just better (no sense in having to blow lots of time making people learn something unnecessary), but there is a problem when it's easy to enter a field but hard to perform in the field competently.
I've known a few people (who I consider to be overreacting) who actually dislike use of debuggers, because they feel that it makes people less likely to actually properly think through what they are developing. It lowers the barrier to entry a lot, and that the cost of that loss of a filter causes more harm than the overall benefits. One of these people is Linus Torvalds. Another is my current boss. While I think that they both go too far, there is a sizeable kernel of truth.
I think that the single largest irritation I have with some of the newer platforms is that they greatly lower the barrier to entry with threads (see my
The problem is that the syntax you must use and some trivial knowledge about what is safe to do and what isn't in a language or on a platform is the tiniest part of what must be known to correctly multithread a program. You *must understand how to correctly do multithreaded design* from the standpoint of designing a program. This is not easy to do correctly, and it's easy to take "shortcuts" that then come back and bite one in the ass. I would say that I have known maybe three or four people that I would trust to correctly write preemptively multithreaded systems that I'd be willing to trust my life to -- and in every single one of their cases, I've found nasty design-level bugs in their threaded or distributed designs that probably would not have cropped up in a simple single-threaded design.
Multithreading a a system has exactly two legitimate uses:
(1) Increasing performance. Unless you have a very specialized system designed for parallel processing, you are probably talking about possibly a factor of two speedup on a typical multiprocessor system. The problem is that a factor of two is *nothing*. You have a limited amount of development time T in which to make your application perform as quickly as possible. It's almost always possible to redesign such a system's higher-level logic (precompute, cache to avoid recomputation, better algorithms, whatever) to get at *least* a factor of two speed improvement on a CPU-bound application, and doing so is almost always cheaper in terms of development time than multithreading an application. Multithreading is damned expensive in terms of development time and debugging time. It makes profiling much more difficult. It is *not* immediately clear to a reader of your code what assumptions you make about the threading model; we developed data hiding for defining how data must be touched, but we have no good way at the language level for defining guarantees about how threads must interact. Result: you waste a lot of time for minimal performance gain.
(2) Ea
I have led teams to build both the 30th and the 60th busiest sites on the web for a former client - all .Net/ C#. It works.
Paul Graham wrote Yahoo! Stores in Lisp. Should we all be running back frantically to Lisp books and pulling them out because Lisp is the latest and greatest thing going?
I agree that C#/.NET is solid, feel that it is technically nicer than the other high-level alternatives for Windows-based development. It's certainly not something I'd denigrate. But on the other hand, Java is also fine. Plenty of people are also write software in Perl, Python, what-have-you.
If you know C#/.NET well and happen to live in NYC, hey, great, maybe it's worth doing some salary renegotiation or looking around at other opportunities. But it'd just be silly to drop your expert-level embedded development experience or your knowlege in building JITs for JVMs or whatever, get a C#/.NET book and move to NYC, you know?
who would have taught few years ago that Java programmers be a dying breed?
.NET. The next day, only senior developers with experience can get jobs, and the day after, junior coders are taking away all the highly-paid jobs. The day after, something else. After you've gone through twenty or so claimed crises for the IT industry on Slashdot's front page, you kind of mellow out and just grin and go on your way when you see articles of this sort.
.NET. :-)
There are no "dying breeds" in the sense that you can't do work and get recompensed. Hell, if you *want* to build a web application in Fortran77 (it's just that it's probably kind of a pain in the ass), you can run out and do exactly that. Sure, not a very high *percentage* of people developing software anymore are going to be coding in F77, but the market's also expanded an awful lot from back when Fortran was the hottest thing going.
I keep seeing these various articles from the IT press about how "X" is the hot new area. [snort] If that area was the only place to be, developers would be skipping from language to language and technology to technology every two years (and never gain *any* aptitude in the area). In the grand scheme of things, most IT press have about a two out of ten on the cluefulness meter (I remember seeing one once directly rip a guess of mine as to the rate of Linux desktop adoption and slap it into a report, presented it as if it had research backing it), and about a one out of ten on the integrity meter ("Houston is a *great* place to live and work! It's the new hot center for highly-paid developers! -- I don't have *any* incentives being paid me by Houston business interests, no!")
I like developing in C, and I don't seem to have any trouble running work that needs to be done in (or can be done in) C. Unless you are specifically working for someone or a customer that has a precise language requirement and refuse to work anywhere else, you can do work in pretty much any language. Hell, Paul Graham is still out there using Lisp as a website backend...
My take is that the best way for one to make a good salary and have a good job is to learn a particular useful skillset really in-depth, ignore what Bob the Tech Journalist is screaming about being the latest hotness, and trust your own judgement as to what's technically sound.
And Slashdot runs plenty of "the sky is falling" articles about IT and the software development industry. One day, an article will claim that all software development is going to vanish to India. The next day, Microsoft is going to take over with
Actually, this article isn't even really *negative*. It just implies that we should be dropping everything and checking out
...and what Congress is doing with regards to the issue.
That would be *other* than seizing our search data to try to prove that porn should be banned on the Internet, I assume.
Yes, because spreading across the Internet is a great way to ensure the integrity and unchanging nature of something.
Say what you want about it being Blizzard's game and they can set the rules blah blah, but they damn well better set the rules for everyone.
Because, as we all know, segregating people and suppressing competing ideas is the *best possible* way to breed a tolerant community.
Can anyone provide a pointer to a page that has a real, informed discussion of what exactly the hell the DRM stuff in the GPLv3 draft translates to?
I've read the license, and I'm not certain enough to the point that I can constructively comment.
My initial understanding was that:
* it simply affected the GPLed software (and thus, "not subject other works to" were derived works), and was an attempt to keep the DMCA from being used as an end-run around distribution and modification of GPL software. The rationale was that DRM devices cannot be circumvented, and that a company could release GPL code but still not allow it to be modified.
This reading I wholeheartedly agree with -- if the DMCA is really a loophole that allows someone to prevent modification and redistribution of GPL software, then I want this clause.
Next, I heard a reading that is something like the following:
* This is an attempt to eliminate DRM. GPLv3 software cannot be used in any device that implements DRM (whether or not the GPLv3 software is involved in DRM).
This, I think, is stupid. Not only do I just not have a fundamental problem with DRM (as long as I can freely produce *non-DRMed works*...which, irritatingly enough, I cannot for game consoles), but I don't think that the GPL is an appropriate place to go after DRM. If the DMCA is stupid, the problem should be to repeal the DMCA. I don't really want Stallman trying to use the work of many, many people who agreed to use the GPL with the understanding that it would remain ideologically the same from version to version to attack something else that he doesn't like. I don't oppose use of my GPLed software in weapons, DRM-using devices, or anything else like that.
The difference between the first and second reading is that the first just states that it is not permissible to use DMCA's anticircumvention clause to prevent modification of GPLed software. The second actively prevents GPLed software from being used to implement a device that contains DRM.
I would also argue that the second is far, far too broad. PCs have TCPA. There is nothing inherently *broken* about TCPA, as long as I can still run Linux and free works on my system. Does this mean that now the GPLed BIOSes out there that people are working on cannot be used on TCPA systems? This is, I think, unacceptable.
Basically, here's my take. I think that a lot of techies with Windows are pissy over the fact that non-techies used to subsidize their game habit (non-techies didn't know how to pirate games, techies did), and now DRM threatens to eliminate their free, subsidized product. I think that a lot of these folks size onto DRM as "freedom-limiting" because it allows them to eliminate dissonance with their unhappiness with the introduction of DRM, and the lack of another justification. Frankly, while I can understand that it might be frusterating for a teen who used to be able to play every game on the market to suddenly be limited to a fraction, it just isn't worthy tainting something as important as the GPL to fight DRM:
(a) It's a good thing for said teen. The only assets a teen has is time. Blowing it on games screws him over than anyone else. Games are damn addictive today.
(b) It just isn't a "freedom" that I'm worried about. It's not political free speech. DRM does not violate any of the fundamental rights put in place to allow government and society to continue functioning without breaking down. It *does* mean that maybe some new works cannot be manipulated for a certain period of time (I *do* think that copyright time lengths last *far* too long, and that much of the frusteration over this fact and our inability to get them shortened is translating into the irritation over DRM -- people felt that they could just *ignore* copyright if they couldn't properly adjust the rules to something sane. This is not, IMHO, a good fix.)
I've cracked an awful lot of software in my time, and pirated plenty of movies and music, and been a co
Unless this product gets a lot more concrete and directed, I don't know who is going to buy it.
I can see use for an "automated services" system like this -- patching problems, looking for malware, updating software, providing a link to toll tech support for your computer, etc.
Currently, you can cobble together something for your Windows-using relatives with AdAware, some sort of virus scanner, occasionally (maybe once a year) dropping by to update software and having them call you when things break. But that's a pain, and very wasteful of time, since a lot of these issues are common to a lot of people.
Where does this form come from? It's well-written, effectively-used, and I see it all the time. Does someone maintain a master somewhere?
The answer is to get experts in the field involved in examining patents before they are "rubber stamped".
If people that knew what they were talking about technically (and preferablly leaglly too) were involved in deciding if a patent was valid or not, we wouldnt see so many crappy patents.
Too expensive. What would it cost to get good computer scientists doing something not-so-fun as examining patent applications?
Maybe make it part of a deal -- "get your PhD on a government scholarship, but spend part of your time for the next couple years doing patent review"?
Also, introduce a clause in the rules that says that if a patent is found invalid (either in the initial investigation or later on by a court), the patent holder has to pay up to the PTO.
I'd like that, but I'm not under any illusions as to this working. First, patent filers would protest -- they're being subjected to risk for an impossible search (I agree that the search for conflicting work is impossible, which is part of the reason that I dislike the existing legal minefield where anyone might accidentally infringe on a patent for doing perfectly straightforward work). Second, how much does the patent holder pay? Microsoft doesn't care if it has to pay $10K. It paid more in fees to its in-house lawyers to get the patent pushed through in the first place. On the other hand, Joe the Independent Inventor working out of a garage may see $5K as a harsh blow to his finances.
The idea of "you have to demonstrate your patent somehow" (e.g. for a patent on something like an encryption algorithim, you have to demonstrate working code for it) would also help.
Yes. There is very little reason that I can think of for this not to be a requirement. I don't think that it solves much, though -- my concern is not people filing impossible patents or patents that are very difficult for those people to implement, but simply taking areas of ideas and holding monopolies over them without then returning advances in technology that would not have otherwise been made.
I'm just waiting for someone who knows networks well enough to put out a $300-400 box with a wireless adapter that does all the configuration and routing necessary to automatically hook me up to any *other* boxes in range. If anyone else gets another machine hooked up to the network, that router gets pulled in too. If a hard line is present, that line is used in preference to wireless.
Now, there are problems. This is a *hard* security problem -- there are lots of ways that someone could attack or DoS a system like this. You're talking about peer-to-peer routing, which could be asking for problems -- but peer-to-peer file transfer would have seem pretty farfetched and abusable just a couple of years ago too.
If Average Joe can get on his citywide network by just buying a box and plugging it in (and then see his city webpage and stream video and transfer data at high speed with anyone else in town), then life is good. Every person has incentive to become a node, and every person on the network increases the value of the network. Point is, what Average Joe needs is network expertise packaged, not the running of some cables. It's not hard to plug in and turn on a wireless router, and not much harder to run a cable or two. It *is* hard to have enough network administration knowledge to set up and maintain something like this -- it has to be zero-maintence and configuration.
The problems that have to be solved with this are almost entirely network-security related. It's not hard to make a zero-configuration Linux router, and lots of people already do so. It's a little more difficult to make a system that can't be DoSed by any jackass that connects to the system.