If QT fell off the map the underlying technology that lets QT draw the pretty pictures will continue to work fine. Qt and GTK+ are pretty much all we have at the moment. If Qt goes stagnant, GTK+ will pull ahead in glitz, users will start looking at Qt applications the way they look at Motif applications now, and Qt will die. Then we'll be stuck with one GUI toolkit. I think it's important that we have two.
One reason is that many developers who use one toolkit think the other is an abomination. I happen to think that there have been a couple of somewhat successful attempts to graft object-orientation onto C, and they are called C++ and Objective C. I think the macro-based object system of GTK+ is an obscenity. (Yeah, I should try Gtkmm, whatever.)
Many developers prefer GTK+ because they feel that C is the only true language, and any amount of obscure macro hackery is better than dealing with C++. They're obviously insane, but they write a lot of cool applications, and I would hate for them to stop. Linux (as well as other open source platforms) needs as many GUI application developers as it can get, and that means Linux needs to cater to as many different types of programmers as possible. Losing Qt to stagnation would mean some developers losing interest or leaving the platform, which would mean fewer good open-source applications.
I disagree with your implication that the url is the important thing to remember about a website. Remembering tags, words, context is much more natural Tags, words, and context are helpful when groping for a hazily-remembered website, but is anything easier or more human than using names? If you see an actor on TV and ask somebody what his name is, what would you rather hear: "That's Ricardo Montalban," or, "He's that guy, who was in that Star Trek movie, and his name was Khan, and Kirk was like, 'KHAAAAAAAAAAN!' and he's been in a bunch of TV stuff too."
Arguably the second description tells you more about the man (what's in a name?), but as a human being you're more satisfied by the first answer. That's just the way we work. A name gives us something around which to crystallize our knowledge and our memories. Analog information fades and blurs. Without a name, similar people blur together. Is there one cute divorced brunette with glasses in the professional services department, or two? Once you have names for them, you can start sorting out their characteristics into two individuals.
Usually when people refer to a site's URL, they mean its domain name. A domain name is even better than a human name, because they are unique and are usually carefully picked to be memorable and easy to spell. It took a while for people to figure out how to choose good domain names, but they do a good job these days. Often, when a website has a long official name that doesn't match its domain name, people find it more natural to use the domain name as the name they use in casual conversation.
Domain names are also absolutely essential to disambiguate between sites with similar content. If you give somebody ridiculous directions to a web site (like "gis kitten star trek indiana third row second column" or "delicious my tags linux radius second listed") then there's a good chance they'll end up on a different site, despite the apparent precision of the directions. You'd better give them part of the URL so they can distinguish between the really cool site you're trying to send them to and all the really lame sites with similar content.
Better yet, give them a name. Giving someone a long context-sensitive algorithm for finding a site, instead of giving them a URL, is like saying, "You should really watch this movie, that has Tom Hanks in it, but he's not the main character, and it's set in Miami, and there are all these drug dealers and a pastry chef...." Don't you just want to punch people like that? Don't be like that. Just say you'll send a link when you get a chance.
All in all, tags and search terms are essential fallbacks when you don't know the name of something, but everything is easier and more certain when you remember the name. Plus, names are essential when communicating with other people (who don't have the same context and memories as you) and when you aren't sure you can recognize what you're looking for or distinguish it from similar content.
There are plenty of other consulting religions that are able to spin such an idealistic view of what other businesses are achieving that the customer is too ashamed to say, "Hey, none of this works for me. You were supposed to build something that works for my business and my employees, not something that works for the idealized business you want us to be."
However, there aren't many other consulting religions in which most of the consultants themselves are devout believers who retain their faith no matter what kind of destruction they cause. Even Rails and J2EE developers eventually come to realize that those technologies only are good in certain contexts. Microsoft guys just blame the customer for not reaching far enough for the helping hand Microsoft offered them.
Microsoft is out to make you an all Microsoft shop which can be fairly pleasant but expensive. Microsoft has educated an entire generation of developers and consultants who do nothing but push Microsoft technologies in mixed shops, where they are unwanted, technically and socially isolated, and not very useful.
But once you've installed an expensive Microsoft product that is a failure because most people hate it and only a few people use it, there's a cure: just replace a little bit more of your working infrastructure with Microsoft products, and suddenly the unused Microsoft products will become vital, useful parts of your business instead of embarrassing mistakes.
So the whole project tanked in the end? Well, you can't blame the Microsoft technologies. They're all "Best of Breed" products with all the right buzzwords and bullet points. Just think of how efficient and unstoppable you would be if you had just managed to convince your employees to use it. I guess you weren't ready to be a Best of Breed business.
This is the eternally recurring story of Microsoft developers, consultants, and "process experts" who just push Microsoft instead of actually doing their jobs.
Doing their jobs, by the way, means studying the businesses they work for, finding out what features would be beneficial and which would actually be used, and figuring out how the available technologies will fit into current practices and current infrastructure. Oh, and figuring out how software can help you simplify process. More often than not, behemoth kitchen sink software does not allow you to create a customized, lightweight process for a unique business.
Most Microsoft consultants who read that last sentence will say, "Ah, here's where it becomes obvious that this guy is on drugs/inexperienced/trolling." Because their Microsoft marketing brochures -- sorry, "educational publications for developers" -- tell them that the only way to create a customized, lightweight solution is to buy the BIGGEST and most featureful product available. You wouldn't want to adopt (or, gasp, develop!) a product and find out it's missing that one vital feature that's necessary to make it lightweight.
So, instead of doing their job, they compare products on a bullet-point basis, using Microsoft "educational" materials to guide them, and work towards a vision of the future in which the more processes and supporting software features people use, the more efficient they are. It's no accident that project plans for adopting Microsoft technologies usually involve adopting tons of practices and processes at the same time -- it helps justify the expense and complexity of the software, and it helps construct a utopian fantasy in which the business will run in perfect synchrony because of the awesome power of process, in defiance of human nature and in defiance of the finite number of hours in the day.
There's no justification for blasting old-school text editors. IDEs with modern GUIs universally suck as text editors. At the moment I'm developing an application on the Eclipse platform, so it's an obvious win for me to use the Eclipse IDE. Mostly I just grit my teeth and use the built-in editor, but a few times a week I end up pasting a block of code into emacs, editing it, and then pasting the code back into the IDE. (Yes, I use Eclipse's emacs mode. It's just a keyboard mapping, nothing more.)
Emacs used to be a decent IDE (maybe the first IDE) but standards have gone up. Modern IDEs kick its ass in a major way. That wouldn't be a problem, except that modern IDEs have text editors that would have been considered crap a quarter-century ago. Why the hell have standards for text editors gone down? Why is the Eclipse text editor a worthless piece of shit?
Eclipse is a huge and sophisticated IDE, but in terms of usability (for programmers -- that's who it's for) its editor is basically an extremely featureful version of Notepad. You can't do jack shit without popping up a dialog box, which forces you to take your eyes off the text you're working on and navigate to the appropriate boxes to fill in the parameters of whatever command you're running.
And since all the commands have to be represented somewhere in the already overcrowed GUI, commands that should be distinct are combined together into ridiculously vague meta-commands that force you to set a bunch of radio buttons and check boxes to specify the command you actually want to execute. And all those radio buttons and check boxes get popped up every time you run the command, so unless you remember what settings you used last, you have to at least glance over them all to make sure they're set correctly. I basically gave up on all of the commands except cut, copy, paste, and incremental search.
A text editor is to a programmer what a chef's knife is to a cook, what a brush is to a painter. The typical IDE editor is like a butter knife or a can of spray paint. It's really sad, because it's completely unnecessary. There's no reason a sophisticated editor can't be built into an IDE. The large number of programmers who forgo the benefits modern IDEs just so they can use emacs and vi is compelling evidence that there needs to be a dramatic revolution in the way IDEs are constructed. The belief that IDE technology obviates the need for sophisticated text editing tools is not justified by current IDE technology, and it probably never will be.
Sometimes the number of "evildoers" is more important than their competence or the seriousness of their intentions. For example, if I stick a can of Coke down my pants when I go watch Ironman, my little transgression will cost the theater a couple of bucks. If I go crazy and decide that I absolutely hate the movie theater and will do anything to bring them down, I can still only cost them... a couple of bucks. Maybe ten bucks if I bring my own popcorn. It's not like I can smuggle a 20 mega-Coke neutron beverage in my pants and detonate it in the theater, thereby costing the theater tens of millions of dollars in soda sales and bankrupting the entire company.
The same thing applies to other limited-harm events like shoplifting and disruption of public events. Every person you deter saves you a few bucks, no matter how casual they are. Even if they were bound to get caught anyway, it saves you the trouble of dealing with them.
For more serious folks like the TSA, I'm sure that deterring casual mischief improves their signal-to-noise ratio, since they can look for one imaginary terrorist per ten thousand violators instead of one imaginary terrorist per one hundred thousand violators. (Erm, wait, 0/10000 = 0 = 0/1000000, so maybe not. Should I be using infinitesimals here? Yeah, that's probably it; I remember the Bush administration had problems with people who didn't understand nonstandard analysis.)
It has nothing to do with security against violence, but I couldn't help noticing at the Lihu'e airport that the guy manning the agriculture inspection machine was just staring off into space as travelers' bags went through his machine. Wondering what he was supposed to be doing, I watched the display he was sitting at. It showed a colorful image of two bags. A static image. An image that did not change at all as bag after bag went through the machine. In fact, I watched him for at least five minutes as my line at the ticket counter inched along, and nothing on the display or any other part of the machine changed at all as the bags went through. He just sat there staring at the wall.
The only "security" was provided by the workers who asked each traveler whether they were carrying any fresh fruits or vegetables. I guess flowers, seeds, and cuttings were okay -- they only only asked about fresh fruits and vegetables.
To top it off, the agents who questioned travelers were not like the evil-eyed Border Patrol checkpoint guys who are ready to call for backup and a dog if your cheek twitches. They were dull, shrinking teenage girls who probably made minimum wage and would rather lose their job than make a tourist angry. If I had said, "Yeah, I've got a papaya in here, so what?" they probably would have laughed and pretended I was kidding.
Thankfully, the agricultural inspection only took about thirty seconds, or I would have been pissed about the waste of time.
What you are trying to say is that the compiler will automatically treat non-overwritten 'virtual' functions as non-virtual. I agree. This has to do with how the compiler works, not whether you can make virtual functions inline. This involves more than just the compiler, since new classes may be loaded at any time. The JIT compiler might speculatively inline a method call only to have that method overridden by a newly loaded class. It requires runtime support to detect and correct this.
Hence, if it is virtual, you need either a) a giant block of code with switches or b) an if that jumps to a non-inlined version of the function. Optimizing the most common case can be a big win, so option b) is not to be sniffed at. Odds are one implementation will get called most of the time. If you guess wrong, you can detect the mistake and recompile. You don't have to generate code that efficiently handles all possibilities unless it turns out that all possibilities happen often enough to matter. This is a big difference between dynamically compiled (and recompiled) code and statically compiled code. With statically compiled code, you have to make your best guess at compile time and then stick with it forever.
And lastly, variables passed to functions are always declared on the stack. I know what you're getting at here -- Java variables are all references and method parameters are all reference values allocated on the stack. However, the parent said objects, not variables, and he is correct that stack allocation is a nice optimization that cannot be done if you pass a reference to the object to a method that you know nothing about.
So don't go back to C++. If you aren't writing little programs that need to start up and shut down quickly, use one of the many languages available for the JVM.
For nice-looking cross-platform apps based on native GUI elements, use the Eclipse RCP (Rich Client Platform) and get a ton of other functionality for free.
Java is a bit inferior to C#, but Java and C# are just the least-common-denominator systems programming languages on their platforms. There are better languages you can use -- popular alternatives for the JVM are Scala, JRuby, and Jython. Scala has had in the past, and may have in the future, a CLR implementation, though at the moment it is JVM-only.
The method containing the call is speculatively compiled with the callee inlined, just like an inline method in C++, except that the inlined code is preceded by a check that the inlining is valid. If the inlining is not valid, I'm not sure exactly what happens, but the end result is that the calling method is recompiled on the fly with the callee no longer inlined.
The payoff is that many virtual method calls run just as fast as nonvirtual method calls. This is a case where Java beats C++ (or rather, the JVM beats a statically compiled language with no runtime optimizations) because C++ cannot recompile at runtime and therefore must restrict itself to whatever optimizations can be validated at compile time.
(Of course, C++ code has other advantages, and C++ code running on a dynamically recompiling platform such as LLVM or.NET might benefit from this kind of optimization -- though it's news to me if any platform can speculatively inline virtual C++ method calls.)
A nice side effect is that developers are encouraged to write simple, clear code, and the JVM takes responsibility for providing the performance.
Actually, I considered the possibility that English wasn't your native language, and based on everything else you wrote, I decided you were a native English speaker. Otherwise, I wouldn't have been so picky. So, congratulations on fooling me, and armed with this new knowledge you will fool even more people:-)
I am a long time Mac user and, as most people like me, I have some particular problems with Microsoft technologies.
Do you realize how this parses? "Because most people like me, I have problems with Microsoft technologies." Possible conclusions:
A) Problems with your native language portend problems with any complicated subject. B) It was a serendipitously insightful comment. B) It was a Freudian slip from a Mac snob. D) Anyone who tries to read something into it has too much time on his hands.
Spinrite costs a whole lot less and uses the science builtin the disks to get the data back Dammit, I thought the "science" option was just a rip-off. I insisted on buying all non-science drives, and if anything fails now I guess I'm screwed.
I don't think the distinction between centralized and decentralized is all that important when comparing systems for use in a centralized manner. Of all the SCM tools in common use, the one that does the most to encourage "disconnected" behavior is CVS, because branching is a horror. Nobody wants to manage private branches, so they only check in working code. A large change is checked in when it's (approximately) done, even if it takes a month to complete.
On the other hand, Subversion is pretty good at encouraging "connected" behavior. When you consider that CVS and Subversion are two implementations of the same idea, it seems that the usability of a given implementation is more important than the abstract idea behind it.
You can't make them check in their changes no matter what SCM they use. CVS users are notorious for going weeks at a time without checking in, because branching is an enormous hassle. If you have some policy or mechanism that effectively forces them to check their work into CVS, why can't you apply that policy or mechanism to a distributed SCM system?
I seriously do mind if you write it on your laptop on the beach, check it in to your local repository and then get your laptop stolen (or covered in margeritas). And the Subversion user would presumably have... teleported himself to a wifi hotspot to check in his work?
Of course a CVS user only updates once a week and checks in once a month, so being on the beach for a few days wouldn't make any difference at all.
I have used Subversion, git, and most recently CVS, and the only big risks I've taken have been with CVS, where everything is so constrictive and painful that I tend to check in as little as possible. The bottom line is that whatever makes for the easiest, most natural development process will result in more frequent check-ins and less lost work.
(I've just stopped asking my colleagues, "How do I ___ in CVS?" because the answer is always slack-jawed silence, followed by, "Why would you want to do that?" accompanied with a suspicious squint-eyed stare that makes me feel like I'm in Deliverance, right there in a cube farm full of college-educated yuppies. CVS warps your brain to the point where you don't think there is ever any good reason to, say, rename a directory, and anyone who wants to rename a directory must be some kind of alien, possibly a marketer or a salesman who wandered into the wrong department, because a Real Programmer would never think up such a bizarre idea as renaming a directory to reflect its current contents. I mean, you pick a name, and it stays forever, right, like a street name! You don't go to Market Street and expect to find a market, so why are you surprised to find the networking code in the tpe_bckp directory? Gary Graybeard can tell you all about how it got that way, and it's a fascinating story. Think of all the rich history that would disappear if you renamed it the "net" or "networking" directory. So depressingly literal. And speaking of depressingly literal, the history would *literally disappear*, and the whole reason we have a SCM system is so we don't lose history. So don't go making changes that it doesn't know how to track, you hear?)
He states several problems with the UI capabilities of.NET. Before I even get into the technical components of his argument, if he's trying to say that Java is better in this area He's not. He said that Java provides a better-designed API based on simpler, cleaner concepts that are easier to learn, whereas there's a bunch of.NET functionality that has funny exceptions because of Win32. Swing isn't pretty to look at, but he is correct that it has a clean conceptual foundation, even despite being built on top of an earlier, abortive attempt at a GUI API, AWT. As a Swing programmer, you don't have to deal with redundant Swing and AWT functionality. (It's there, but you can ignore it at no cost to your understanding.) The parts of AWT that are required for Swing are simple, easy to understand, and not redundant with Swing functionality.
not happy with with the windows UI standards? Everyone else seems to be. "Happy with" and "stuck with" are two different things. Microsoft is screwing itself with the lack of uniformity in Windows. Microsoft's second-best asset (after developers, developers, developers) is the tendency of first-generation computer users to shit their pants when presented with minor look and feel variations. After Microsoft conditions users to expect a different look and feel for every new application they learn, normal users will be capable of switching between platforms without any problem. Then it will be a lot easier for businesses to use open-source operating systems to save money or to take advantage of an application that isn't available on Windows.
The taser IS the less lethal alternative. Note that I said less lethal, not non-lethal. Funny how the police insist on calling tasers "less lethal" but will kick and scream (figuratively, of course, or we'ed just tase them) and go to court at public expense to avoid ever admitting that any particular death was caused by tasing.
"So it's 'less lethal?' Not entirely nonlethal?"
"Yep."
"So has it ever killed anyone?"
"I could conceive of it happening. Scientifically speaking, it could happen. Maybe in some other country, or in an alternative universe, it already has. However, in any jurisdiction where my words could be considered authoritative, or used in court, to my knowledge it has never ever ever killed a single person, or even harmed them or caused any pain. In every case about which I have personal or professional knowledge, tased suspects have reacted with a chuckle and a big peaceful smile, and then died as a result of of previously ingesting the crack that we were trying to plant on... er... the crack that we were trying to stop them from selling to children."
I for one don't want to arm high school quarterbacks who somehow managed graduate from the American public school system with torture devices and set them loose on the public. Don't worry. The quarterback is tall, has good hair, and good "leadership" skills, so he will be your boss and will be torturing you with completely different devices.
Sure you can wrap up the c handlers in c++ objects which then have automagic destructors, but that is a lot of extra layers and code just to get around using a goto. An RAII (destructor-based solution) would save your can if an unexpected exception is thrown from your code or from library code, but most importantly, it would be idiomatic for the language you're writing in. It might require a few more lines of code, but a typical C++ programmer will immediately and correctly grasp what the code does. Whereas, if you do something unexpected like using goto, a typical C++ programmer will assume there was a reason you couldn't use the idiomatic construct, and they will get distracted trying to figure out why you used goto instead.
You don't find the fact that his wife had dated a confessed serial killer at all odd? If Sturgeon is a "confessed serial killer" then let's just call Reiser a "convicted murderer." After all, Sturgeon confessed and Hans was convicted.
What's more likely, that Hans killed Nina or that Sturgeon killed eight people?
Have you ever considered that Hans and Sturgeon used to be buddies, and that Sturgeon might have some sympathy for his old pal? It makes special sense because Sturgeon also had to deal with Nina Reiser, who probably is/was quite a pile of broken glass herself, considering she was involved with both of these nut jobs. (If it was just Hans, you might call it a mistake, but going from Hans to Sturgeon....) If Sturgeon sympathized with Hans for going crazy over Nina, and he felt guilty about betraying Hans in the past, he would have a very strong motive to help his old friend out.
Personally, I think Sturgeon made the story up for Hans' sake, hoping it would influence the press coverage and the jury. It wouldn't have been a huge risk for Sturgeon, since he was already a bizarro-wacko attention whore and his story wouldn't hold up under investigation. His weirdness and apparent enmity for Hans would shield him from accusations that he was obstructing justice or manipulating the trial.
Of course, Sturgeon might actually be a psycho killer, and Hans might be innocent. I don't think anyone knows enough about what happened to convict anybody of anything.
I reckon I've spent a good 10-20 hours dicking around with my most recent PC workstation that I built myself, if you include the initial build+install and a few hardware issues I sorted out over the past year or two. How long would you have spent dicking around with customer support if you had had the same problems with your Mac Pro? It's an honest question; I don't actually know how good support for a Mac Pro would be. In my experience, support for high-end business-oriented systems has been very good and support for consumer systems has been just a waste of a lot of my precious time. When buying a $2500 HP workstation, I would consider the value of the technical support I was getting, but when buying a consumer desktop or laptop, I would assume the support is worthless -- just based on my limited experienced.
The difference that most of you "home-built" fanatics overlook is that Apple/Dell/HP/whoever are in business to sell and support complete, operating computers, and you are not. We don't miss it. We're keenly aware of it, and we don't think it's worth the money. "Support" isn't very supportive; it isn't any better, faster, or more friendly than Google. Even worse, it's a hoop you have to jump through before you can send back defective parts.
Installing an OS isn't a headache at all these days -- it's almost entirely automated and takes half an hour. The headache is in installing and configuring all of the software you use on a daily basis, copying data onto the computer, and configuring the environment the way you want it. Dell and Apple are absolutely no help in that way. Buying a computer with Windows pre-installed is actually worse than installing Windows yourself, since you typically get an install cluttered up with unnecessary junk, including a bunch of proprietary configuration programs that aren't any better than the ones included with Windows.
And if you aren't going to run Windows or OSX, then Dell and Apple obviously don't offer anything at all except a hardware warranty, which is a rip-off. It's cheaper to just buy hardware with a good reputation for reliability and immediately return anything that's DOA.
The only situations where I see it being worthwhile to buy rather than build are:
If you want a level of hardware integration that isn't available with off-the-shelf components;
If you want unusual or bleeding-edge hardware that you (along with your friend Google) aren't knowledgeable enough support yourself;
If you absolutely positively must have a computer in a week and need to know that someone will replace your new computer in 48 hours if it arrives DOA;
If you want the computer, monitor, keyboard, and mouse to match cosmetically;
If you want a high-end computer sold to businesses, such as a server or workstation, since the support provided for those products isn't a painful, humiliating joke like the support provided for consumer systems; or,
If $1000 just isn't very much money to you (and no resentment if that's the case; I'm aiming to be in your shoes some day.)
Personally, I go exclusively low-end, and at that end of the market Dell doesn't seem to offer anything decent. I've bought a couple of $400-$500 computers (monitor not included) from Dell and found them to be inexplicably anemic, given their specs. I can build a pretty nice computer out of $400 worth of components, but a $400 Dell runs like a cheap POS.
The only plausible explanation I can come up with is that Dell assumes anyone paying less than $500 for a computer won't know or care how it performs. That's just a guess. I really have no clue why it is, but as long as I am using fairly low-end PCs, I will stick with building.
Slashdot Mirror
One reason is that many developers who use one toolkit think the other is an abomination. I happen to think that there have been a couple of somewhat successful attempts to graft object-orientation onto C, and they are called C++ and Objective C. I think the macro-based object system of GTK+ is an obscenity. (Yeah, I should try Gtkmm, whatever.)
Many developers prefer GTK+ because they feel that C is the only true language, and any amount of obscure macro hackery is better than dealing with C++. They're obviously insane, but they write a lot of cool applications, and I would hate for them to stop. Linux (as well as other open source platforms) needs as many GUI application developers as it can get, and that means Linux needs to cater to as many different types of programmers as possible. Losing Qt to stagnation would mean some developers losing interest or leaving the platform, which would mean fewer good open-source applications.
Arguably the second description tells you more about the man (what's in a name?), but as a human being you're more satisfied by the first answer. That's just the way we work. A name gives us something around which to crystallize our knowledge and our memories. Analog information fades and blurs. Without a name, similar people blur together. Is there one cute divorced brunette with glasses in the professional services department, or two? Once you have names for them, you can start sorting out their characteristics into two individuals.
Usually when people refer to a site's URL, they mean its domain name. A domain name is even better than a human name, because they are unique and are usually carefully picked to be memorable and easy to spell. It took a while for people to figure out how to choose good domain names, but they do a good job these days. Often, when a website has a long official name that doesn't match its domain name, people find it more natural to use the domain name as the name they use in casual conversation.
Domain names are also absolutely essential to disambiguate between sites with similar content. If you give somebody ridiculous directions to a web site (like "gis kitten star trek indiana third row second column" or "delicious my tags linux radius second listed") then there's a good chance they'll end up on a different site, despite the apparent precision of the directions. You'd better give them part of the URL so they can distinguish between the really cool site you're trying to send them to and all the really lame sites with similar content.
Better yet, give them a name. Giving someone a long context-sensitive algorithm for finding a site, instead of giving them a URL, is like saying, "You should really watch this movie, that has Tom Hanks in it, but he's not the main character, and it's set in Miami, and there are all these drug dealers and a pastry chef...." Don't you just want to punch people like that? Don't be like that. Just say you'll send a link when you get a chance.
All in all, tags and search terms are essential fallbacks when you don't know the name of something, but everything is easier and more certain when you remember the name. Plus, names are essential when communicating with other people (who don't have the same context and memories as you) and when you aren't sure you can recognize what you're looking for or distinguish it from similar content.
There are plenty of other consulting religions that are able to spin such an idealistic view of what other businesses are achieving that the customer is too ashamed to say, "Hey, none of this works for me. You were supposed to build something that works for my business and my employees, not something that works for the idealized business you want us to be."
However, there aren't many other consulting religions in which most of the consultants themselves are devout believers who retain their faith no matter what kind of destruction they cause. Even Rails and J2EE developers eventually come to realize that those technologies only are good in certain contexts. Microsoft guys just blame the customer for not reaching far enough for the helping hand Microsoft offered them.
But once you've installed an expensive Microsoft product that is a failure because most people hate it and only a few people use it, there's a cure: just replace a little bit more of your working infrastructure with Microsoft products, and suddenly the unused Microsoft products will become vital, useful parts of your business instead of embarrassing mistakes.
So the whole project tanked in the end? Well, you can't blame the Microsoft technologies. They're all "Best of Breed" products with all the right buzzwords and bullet points. Just think of how efficient and unstoppable you would be if you had just managed to convince your employees to use it. I guess you weren't ready to be a Best of Breed business.
This is the eternally recurring story of Microsoft developers, consultants, and "process experts" who just push Microsoft instead of actually doing their jobs.
Doing their jobs, by the way, means studying the businesses they work for, finding out what features would be beneficial and which would actually be used, and figuring out how the available technologies will fit into current practices and current infrastructure. Oh, and figuring out how software can help you simplify process. More often than not, behemoth kitchen sink software does not allow you to create a customized, lightweight process for a unique business.
Most Microsoft consultants who read that last sentence will say, "Ah, here's where it becomes obvious that this guy is on drugs/inexperienced/trolling." Because their Microsoft marketing brochures -- sorry, "educational publications for developers" -- tell them that the only way to create a customized, lightweight solution is to buy the BIGGEST and most featureful product available. You wouldn't want to adopt (or, gasp, develop!) a product and find out it's missing that one vital feature that's necessary to make it lightweight.
So, instead of doing their job, they compare products on a bullet-point basis, using Microsoft "educational" materials to guide them, and work towards a vision of the future in which the more processes and supporting software features people use, the more efficient they are. It's no accident that project plans for adopting Microsoft technologies usually involve adopting tons of practices and processes at the same time -- it helps justify the expense and complexity of the software, and it helps construct a utopian fantasy in which the business will run in perfect synchrony because of the awesome power of process, in defiance of human nature and in defiance of the finite number of hours in the day.
There's no justification for blasting old-school text editors. IDEs with modern GUIs universally suck as text editors. At the moment I'm developing an application on the Eclipse platform, so it's an obvious win for me to use the Eclipse IDE. Mostly I just grit my teeth and use the built-in editor, but a few times a week I end up pasting a block of code into emacs, editing it, and then pasting the code back into the IDE. (Yes, I use Eclipse's emacs mode. It's just a keyboard mapping, nothing more.)
Emacs used to be a decent IDE (maybe the first IDE) but standards have gone up. Modern IDEs kick its ass in a major way. That wouldn't be a problem, except that modern IDEs have text editors that would have been considered crap a quarter-century ago. Why the hell have standards for text editors gone down? Why is the Eclipse text editor a worthless piece of shit?
Eclipse is a huge and sophisticated IDE, but in terms of usability (for programmers -- that's who it's for) its editor is basically an extremely featureful version of Notepad. You can't do jack shit without popping up a dialog box, which forces you to take your eyes off the text you're working on and navigate to the appropriate boxes to fill in the parameters of whatever command you're running.
And since all the commands have to be represented somewhere in the already overcrowed GUI, commands that should be distinct are combined together into ridiculously vague meta-commands that force you to set a bunch of radio buttons and check boxes to specify the command you actually want to execute. And all those radio buttons and check boxes get popped up every time you run the command, so unless you remember what settings you used last, you have to at least glance over them all to make sure they're set correctly. I basically gave up on all of the commands except cut, copy, paste, and incremental search.
A text editor is to a programmer what a chef's knife is to a cook, what a brush is to a painter. The typical IDE editor is like a butter knife or a can of spray paint. It's really sad, because it's completely unnecessary. There's no reason a sophisticated editor can't be built into an IDE. The large number of programmers who forgo the benefits modern IDEs just so they can use emacs and vi is compelling evidence that there needs to be a dramatic revolution in the way IDEs are constructed. The belief that IDE technology obviates the need for sophisticated text editing tools is not justified by current IDE technology, and it probably never will be.
The lever is a blatant rip-off of the stick.
Sometimes the number of "evildoers" is more important than their competence or the seriousness of their intentions. For example, if I stick a can of Coke down my pants when I go watch Ironman, my little transgression will cost the theater a couple of bucks. If I go crazy and decide that I absolutely hate the movie theater and will do anything to bring them down, I can still only cost them... a couple of bucks. Maybe ten bucks if I bring my own popcorn. It's not like I can smuggle a 20 mega-Coke neutron beverage in my pants and detonate it in the theater, thereby costing the theater tens of millions of dollars in soda sales and bankrupting the entire company.
The same thing applies to other limited-harm events like shoplifting and disruption of public events. Every person you deter saves you a few bucks, no matter how casual they are. Even if they were bound to get caught anyway, it saves you the trouble of dealing with them.
For more serious folks like the TSA, I'm sure that deterring casual mischief improves their signal-to-noise ratio, since they can look for one imaginary terrorist per ten thousand violators instead of one imaginary terrorist per one hundred thousand violators. (Erm, wait, 0/10000 = 0 = 0/1000000, so maybe not. Should I be using infinitesimals here? Yeah, that's probably it; I remember the Bush administration had problems with people who didn't understand nonstandard analysis.)
It has nothing to do with security against violence, but I couldn't help noticing at the Lihu'e airport that the guy manning the agriculture inspection machine was just staring off into space as travelers' bags went through his machine. Wondering what he was supposed to be doing, I watched the display he was sitting at. It showed a colorful image of two bags. A static image. An image that did not change at all as bag after bag went through the machine. In fact, I watched him for at least five minutes as my line at the ticket counter inched along, and nothing on the display or any other part of the machine changed at all as the bags went through. He just sat there staring at the wall.
The only "security" was provided by the workers who asked each traveler whether they were carrying any fresh fruits or vegetables. I guess flowers, seeds, and cuttings were okay -- they only only asked about fresh fruits and vegetables.
To top it off, the agents who questioned travelers were not like the evil-eyed Border Patrol checkpoint guys who are ready to call for backup and a dog if your cheek twitches. They were dull, shrinking teenage girls who probably made minimum wage and would rather lose their job than make a tourist angry. If I had said, "Yeah, I've got a papaya in here, so what?" they probably would have laughed and pretended I was kidding.
Thankfully, the agricultural inspection only took about thirty seconds, or I would have been pissed about the waste of time.
So don't go back to C++. If you aren't writing little programs that need to start up and shut down quickly, use one of the many languages available for the JVM.
For nice-looking cross-platform apps based on native GUI elements, use the Eclipse RCP (Rich Client Platform) and get a ton of other functionality for free.
Java is a bit inferior to C#, but Java and C# are just the least-common-denominator systems programming languages on their platforms. There are better languages you can use -- popular alternatives for the JVM are Scala, JRuby, and Jython. Scala has had in the past, and may have in the future, a CLR implementation, though at the moment it is JVM-only.
The method containing the call is speculatively compiled with the callee inlined, just like an inline method in C++, except that the inlined code is preceded by a check that the inlining is valid. If the inlining is not valid, I'm not sure exactly what happens, but the end result is that the calling method is recompiled on the fly with the callee no longer inlined.
.NET might benefit from this kind of optimization -- though it's news to me if any platform can speculatively inline virtual C++ method calls.)
The payoff is that many virtual method calls run just as fast as nonvirtual method calls. This is a case where Java beats C++ (or rather, the JVM beats a statically compiled language with no runtime optimizations) because C++ cannot recompile at runtime and therefore must restrict itself to whatever optimizations can be validated at compile time.
(Of course, C++ code has other advantages, and C++ code running on a dynamically recompiling platform such as LLVM or
A nice side effect is that developers are encouraged to write simple, clear code, and the JVM takes responsibility for providing the performance.
Actually, I considered the possibility that English wasn't your native language, and based on everything else you wrote, I decided you were a native English speaker. Otherwise, I wouldn't have been so picky. So, congratulations on fooling me, and armed with this new knowledge you will fool even more people
Do you realize how this parses? "Because most people like me, I have problems with Microsoft technologies." Possible conclusions:
A) Problems with your native language portend problems with any complicated subject.
B) It was a serendipitously insightful comment.
B) It was a Freudian slip from a Mac snob.
D) Anyone who tries to read something into it has too much time on his hands.
I don't think the distinction between centralized and decentralized is all that important when comparing systems for use in a centralized manner. Of all the SCM tools in common use, the one that does the most to encourage "disconnected" behavior is CVS, because branching is a horror. Nobody wants to manage private branches, so they only check in working code. A large change is checked in when it's (approximately) done, even if it takes a month to complete.
On the other hand, Subversion is pretty good at encouraging "connected" behavior. When you consider that CVS and Subversion are two implementations of the same idea, it seems that the usability of a given implementation is more important than the abstract idea behind it.
You can't make them check in their changes no matter what SCM they use. CVS users are notorious for going weeks at a time without checking in, because branching is an enormous hassle. If you have some policy or mechanism that effectively forces them to check their work into CVS, why can't you apply that policy or mechanism to a distributed SCM system?
Of course a CVS user only updates once a week and checks in once a month, so being on the beach for a few days wouldn't make any difference at all.
I have used Subversion, git, and most recently CVS, and the only big risks I've taken have been with CVS, where everything is so constrictive and painful that I tend to check in as little as possible. The bottom line is that whatever makes for the easiest, most natural development process will result in more frequent check-ins and less lost work.
(I've just stopped asking my colleagues, "How do I ___ in CVS?" because the answer is always slack-jawed silence, followed by, "Why would you want to do that?" accompanied with a suspicious squint-eyed stare that makes me feel like I'm in Deliverance, right there in a cube farm full of college-educated yuppies. CVS warps your brain to the point where you don't think there is ever any good reason to, say, rename a directory, and anyone who wants to rename a directory must be some kind of alien, possibly a marketer or a salesman who wandered into the wrong department, because a Real Programmer would never think up such a bizarre idea as renaming a directory to reflect its current contents. I mean, you pick a name, and it stays forever, right, like a street name! You don't go to Market Street and expect to find a market, so why are you surprised to find the networking code in the tpe_bckp directory? Gary Graybeard can tell you all about how it got that way, and it's a fascinating story. Think of all the rich history that would disappear if you renamed it the "net" or "networking" directory. So depressingly literal. And speaking of depressingly literal, the history would *literally disappear*, and the whole reason we have a SCM system is so we don't lose history. So don't go making changes that it doesn't know how to track, you hear?)
"So it's 'less lethal?' Not entirely nonlethal?"
"Yep."
"So has it ever killed anyone?"
"I could conceive of it happening. Scientifically speaking, it could happen. Maybe in some other country, or in an alternative universe, it already has. However, in any jurisdiction where my words could be considered authoritative, or used in court, to my knowledge it has never ever ever killed a single person, or even harmed them or caused any pain. In every case about which I have personal or professional knowledge, tased suspects have reacted with a chuckle and a big peaceful smile, and then died as a result of of previously ingesting the crack that we were trying to plant on... er... the crack that we were trying to stop them from selling to children."
What's more likely, that Hans killed Nina or that Sturgeon killed eight people?
Have you ever considered that Hans and Sturgeon used to be buddies, and that Sturgeon might have some sympathy for his old pal? It makes special sense because Sturgeon also had to deal with Nina Reiser, who probably is/was quite a pile of broken glass herself, considering she was involved with both of these nut jobs. (If it was just Hans, you might call it a mistake, but going from Hans to Sturgeon....) If Sturgeon sympathized with Hans for going crazy over Nina, and he felt guilty about betraying Hans in the past, he would have a very strong motive to help his old friend out.
Personally, I think Sturgeon made the story up for Hans' sake, hoping it would influence the press coverage and the jury. It wouldn't have been a huge risk for Sturgeon, since he was already a bizarro-wacko attention whore and his story wouldn't hold up under investigation. His weirdness and apparent enmity for Hans would shield him from accusations that he was obstructing justice or manipulating the trial.
Of course, Sturgeon might actually be a psycho killer, and Hans might be innocent. I don't think anyone knows enough about what happened to convict anybody of anything.
Installing an OS isn't a headache at all these days -- it's almost entirely automated and takes half an hour. The headache is in installing and configuring all of the software you use on a daily basis, copying data onto the computer, and configuring the environment the way you want it. Dell and Apple are absolutely no help in that way. Buying a computer with Windows pre-installed is actually worse than installing Windows yourself, since you typically get an install cluttered up with unnecessary junk, including a bunch of proprietary configuration programs that aren't any better than the ones included with Windows.
And if you aren't going to run Windows or OSX, then Dell and Apple obviously don't offer anything at all except a hardware warranty, which is a rip-off. It's cheaper to just buy hardware with a good reputation for reliability and immediately return anything that's DOA.
The only situations where I see it being worthwhile to buy rather than build are:
Personally, I go exclusively low-end, and at that end of the market Dell doesn't seem to offer anything decent. I've bought a couple of $400-$500 computers (monitor not included) from Dell and found them to be inexplicably anemic, given their specs. I can build a pretty nice computer out of $400 worth of components, but a $400 Dell runs like a cheap POS.
The only plausible explanation I can come up with is that Dell assumes anyone paying less than $500 for a computer won't know or care how it performs. That's just a guess. I really have no clue why it is, but as long as I am using fairly low-end PCs, I will stick with building.