Once again, it's important to check for potential forseeable conditions beforehand, not process them as exceptions afterwards. This is just good programming practice. GetFileAttributes can return false for any number of reasons (actually I think it returns -1 or something like that).
That said, yes, I am guilty of some hyperbole. It only took me probably 10 minutes to write the code I mentioned, and 6 lines of code to do it cleanly (and 2 of those lines contain braces and nothing else). For the record:
CFileFind oFind;
if (!oFind.FindFile(sPath))
{
if (!::CreateDirectory(sPath, NULL)) ...NOW throw the exception...
}
(Sorry about the formatting. Is it me or does/. not support <pre>?) As you can see, I consider a failure by CreateDirectory to be a real application failure since I've already checked for the one "error condition" that I can foresee. Most of the 10 minutes I spent on this was trying to convince myself that there isn't an easier way to do it cleanly than creating a CFileFind object...
So yes, I exaggerated somewhat (to be frank I didn't expect this thread to elicit so much activity!) but I do think that my original point remains valid.
I am probably awfully stodgy but I prefer to know why an operation failed. Just telling the user "An IOException occurred" (or, even better, just assuming that it was due to the fact that the directory existed and ignoring it) isn't good programming practice where I come from.
I'll type those 20 odd extra characters any day...
We appear to be agreeing. I'd be ecstatic if there were only ONE platform, ONE language, ONE windowing system, ONE messaging protocol, etc. This would a) make it easier and smoother to do development projects without having to get back up to speed on Yet Another Language every time and b) make it easier to create packaged products without having to tear your hair out constantly over whether it will run on the XYZ operating system.
Unfortunately the world is an imperfect place, and at the risk of sounding overly philosophical I think one of the keys to happiness is accepting this. There's no point in banging our heads against the wall because Sun and Microsoft won't just kiss and be friends. I'm just glad that subsequent to their obvious strategic move of rejecting Java, MS at least released something comparable instead of sticking their heads in the ground and pretending that C++ isn't an outdated C hack.
Repeat after me: C# is a MSFT version of Java. C# is a MSFT version of Java.
Total agreement. But why is this a bad thing? I would have been just as happy (in fact even happier) to see MS embrace Java and foster a great implementation on the Windows platform. But they didn't, so in the long-term it is going to be hard to ignore C#. The reality, like it or not, is that a lot of our customers want us to use MS technologies for their projects. I don't argue with the customers' technological choices, I just take their money. That being the case, I'm very pleased to be using C# instead of C++ for the reasons given in my previous post.
Java is a huge step forward compared to C++, so your point (that C# is really just a MS proprietary version of Java) is a huge plus as far as I'm concerned.
I don't have any problem with inflammatory comments, but I am curious to know what exactly motivated the author's statement besides sheer bloodymindedness vis-a-vis Microsoft.
I currently have two machines sitting in front of me, one of which runs my "Microsoft" development environment (Visual Studio.NET, C++, C#) and the other my Java development environment (Eclipse). I use all three languages more or less on a daily basis, and I don't think I have any latent bias other than what actually works for me. From this perspective (pun intended) I would make the following observations:
Eclipse is totally awesome. No other Java IDE comes close (and I've used a bunch). Not only is it a pleasure to use, but it has had a major influence on my view of software architectures in general by virtue of its elegant plugin architecture.
C++ sucks. I've been a C++ programmer for 10 odd years, but after using Java and C# there's no turning back. I understand memory management, pointers and the like, but they are a major cramp on productivity and I'd rather do without them.
C# and.NET look very cool as a replacement for venerable C++. C# has all of the obvious advantages of Java, and equally important, the.NET libraries are finally a worthy equivalent to all the J2SE foundation class that should have been in C++ but aren't (and don't get me started about STL). Ever try to, say, check whether a directory exists in C++ and, if not, to create it? I spent at least 20 minutes surfing through MSDN and ended up with 10-15 lines of code. I'm very much still learning C#, but I wrote:
if (!Directory.Exists(str)) Directory.CreateDirectory(str);
...and it worked first time.
So what exactly is wrong with.NET? If you need to work on the Windows platform it's a godsend!
It is ashame that the author should lay out what is an intriguing vision and the spoil it by infusing it with such a gloomy Malthusian spirit.
The author's assertions about progress in robotics and artificial intelligence are bold, but seem defensible. On the one hand, intelligent people have vastly exaggerated the speed of progress in AI for decades (Arthur C. Clarke's 2001: A Space Odyssey was meant to be an accurate portrayal of the state of technology at that time). On the other hand, the inexorable progress of Moore's Law does point to the kinds of changes postulated in about the proposed timeframe.
Which is ridiculous is the assumption, not even questioned in the piece, that workers displaced from one industry will remain jobless. At most 300 years ago 90% of all workers in today's developed economies were employed in agriculture. Today it is more like 2-3%. It would have been easy to argue at the time that most of the world's workers would be unemployed in a matter of decades (and plenty of people did argue that -- remember the Luddites?).
The reality is that the working week shortened from 80 hours/week to 40 (ok, maybe not for software developers) and the type of work performed by humans has become vastly more intellectual, on average. The author is right that driving a cab or cleaning a hotel room is not fascinating work, and in the future no one will do it.
If robots end up doing half of the work we do now, which seems plausible, chances are we will work only 75% as much as today and have 1.5x the economic output, and unemployment won't change a whit.
When the technology existed to fit n minutes of music onto a record, musicians started to produce works that were n minutes long.
This is totally off-topic but I can't resist sharing this little factoid: apparently the length of an audio CD (i.e. approximately 74 minutes) was chosen so that a full recording of Beethoven's 9th Symphony would fit on a single CD. So by your logic (which seems credible to me), those here-today-gone-tomorrow girl and boy bands are still tailoring their production around a format pioneered by old Ludwig Van in the early 19th century.
I agree with all the previous comments: price, speed, choice of quality, etc. are all important. I would add in this context that having an online account would be a big plus, so that I can pay in a certain amount (say $10-20) and then buy tracks out of that account, rather than having to bill my credit card every time for $.79 or $.99 or whatever.
Most importantly, the user experience needs to be attractive since this is a very competitive space (and a lot of your competition has a compelling price point: free). Take a long, hard look at Amazon.com, which is the best e-commerce website I know. Notice how they have striven to make the purchasing process fun and informative. Notice also how the information-rich experience they provide helps to cross- and upsell customers ("People who bought X also bought Y"). If you can include ratings, recommendations, user comments, etc. in your site in a way that is slick and easy to use, that will definitely help to attract and retain customers.
Actually the RIAA has been quite upfront regarding their plans to sue the pants off offenders. They have stated repeatedly that they plan to go after users who are sharing tons of files, not the zillions of normal users, which makes sense since supposedly a small minority of big sharers supplies the vast majority of files on the networks.
From this perspective something like a proxy for file transfers is not so important (not to mention fairly impractical). If other users can't see your full library and can't see your IP address in their search results (the latter might enable smart bots to "guess" what your library contains), the only way they can determine that you are sharing massively is to download tons of files and see which IP addresses crop up. This is because they will only see your IP when they actually start downloading.
All this to say that with the latest changes in K++ and Kazaa Lite, even big time file sharers can probably rest easy.
I can't say enough about how wrongheaded this article is. First of all, it is impossible to tell whether the author's ire has been raised by the existence of some obscure CSS bugs in IE or by standard unfocused anti-Microsoft rage (but the latter seems more plausible). At very least the author should be clear about his motives.
More seriously, the article completely misses the reasons why the browser wars were so important in the mid 90s and so irrelevant now. At the time, the impact of the web was still unclear (and open to influence), and Netscape proclaimed from the rooftops that by controlling the browser they effectively controlled a new operating system capable of challenging the Windows monopoly on the desktop. What's more, they were right. Microsoft took this hubris seriously enough to throw major-league resource behind the IE development effort. This, coupled with Netscape's inability to handle its hypergrowth, led to the status quo, where IE is the only browser that matters for 95% of all PC users.
If someone were to exploit the nefarious CSS bugs that lurk in the bowels of IE and somehow achieve dominance in the PC browser market, it still wouldn't matter. The browser no longer represents a threat to Windows' hegemony. HTML rendering is now a commodity, a feature in an array of widgets that people are accustomed to using on their PC desktop. In other words, MS was right: the browser is part of the operating system.
As a software developer I can affirm that it is a joy and pleasure to have widgets like CHtmlView and CHtmlEditView (sorry, I am a - gasp! - MFC developer) available for easy integration into apps. Personally I don't give a hoot whether IE or something else is powering that widget, and nor do my users. Value is now being added by building sophisticated structures around the HTML renderer: support for XML web services and RSS feeds, drag and drop with other apps, external navigators (like tree views) that customize the browsing experience to a particular use case. This is today's competitive landscape, and the good news is that there's still plenty of scope to complement and compete with Microsoft.
One important distinction is between development of a "packaged" product or of a custom project for a customer. In many cases, a customer project will be most successful if you get something out the door and delivered to the customer as quickly as possible. Since they probably didn't know what they wanted in the first place, this will give them a chance to play around with what is, in essence, a prototype before you sit down and craft a masterpiece that no one will actually use.
For product development the picture is very different. Here the temptation is to throw quick-and-dirty hacks into your product for every potential customer to land a sale. The result is a bloated, spaghetti-code-ridden product that takes longer and longer to extend because its design does not lead to easy code reuse and specialization. This is a death spiral for any software development company and must be avoid at all costs. With products it is indispensable to make orderly releases based on requirements driven by a synthesis of customer needs, not the "urgent" requirements of one customer.
This article is certainly thought-provoking, and it is always worthwhile to challenge conventional wisdom once in a while. Nonetheless, I can't shake the feeling that this is a lot of sound and fury about nothing. As many others have the pointed out, Google's case may not be typical, and in my long career in the computer industry I seem to remember countless similar statements that ended up as more of an embarrassment to the speaker than anything remotely prescient (anyone remember Bill Gates's claim that no one would EVER need more than 640K of RAM?).
I use a PC of what would have been unimaginable power a few short years ago, and it is still woefully inadequate for many of my purposes. I still spend a lot of my programming time optimizing code that I could leave in its original, elegant but inefficient state if computers were faster. And in the field of artificial intelligence, computers are finally starting to do useful things, but are sorely hampered by insufficient processing power (try a few huge matrix decompositions -- or a backgammon rollout! -- and you'll see what I mean).
Perhaps the most insightful comment in the article is the observation that no one has ever won betting against Moore's Law. I'm betting it'll be around another 10 years with change. Email me if you're taking...
Slashdot Mirror
That said, yes, I am guilty of some hyperbole. It only took me probably 10 minutes to write the code I mentioned, and 6 lines of code to do it cleanly (and 2 of those lines contain braces and nothing else). For the record:
CFileFind oFind;
...NOW throw the exception...
if (!oFind.FindFile(sPath))
{
if (!::CreateDirectory(sPath, NULL))
}
(Sorry about the formatting. Is it me or does /. not support <pre>?) As you can see, I consider a failure by CreateDirectory to be a real application failure since I've already checked for the one "error condition" that I can foresee. Most of the 10 minutes I spent on this was trying to convince myself that there isn't an easier way to do it cleanly than creating a CFileFind object...
So yes, I exaggerated somewhat (to be frank I didn't expect this thread to elicit so much activity!) but I do think that my original point remains valid.
I'll type those 20 odd extra characters any day...
Unfortunately the world is an imperfect place, and at the risk of sounding overly philosophical I think one of the keys to happiness is accepting this. There's no point in banging our heads against the wall because Sun and Microsoft won't just kiss and be friends. I'm just glad that subsequent to their obvious strategic move of rejecting Java, MS at least released something comparable instead of sticking their heads in the ground and pretending that C++ isn't an outdated C hack.
Yes.
Repeat after me: C# is a MSFT version of Java. C# is a MSFT version of Java.
Total agreement. But why is this a bad thing? I would have been just as happy (in fact even happier) to see MS embrace Java and foster a great implementation on the Windows platform. But they didn't, so in the long-term it is going to be hard to ignore C#. The reality, like it or not, is that a lot of our customers want us to use MS technologies for their projects. I don't argue with the customers' technological choices, I just take their money. That being the case, I'm very pleased to be using C# instead of C++ for the reasons given in my previous post.
Java is a huge step forward compared to C++, so your point (that C# is really just a MS proprietary version of Java) is a huge plus as far as I'm concerned.
I currently have two machines sitting in front of me, one of which runs my "Microsoft" development environment (Visual Studio.NET, C++, C#) and the other my Java development environment (Eclipse). I use all three languages more or less on a daily basis, and I don't think I have any latent bias other than what actually works for me. From this perspective (pun intended) I would make the following observations:
if (!Directory.Exists(str)) Directory.CreateDirectory(str);
So what exactly is wrong with .NET? If you need to work on the Windows platform it's a godsend!
The author's assertions about progress in robotics and artificial intelligence are bold, but seem defensible. On the one hand, intelligent people have vastly exaggerated the speed of progress in AI for decades (Arthur C. Clarke's 2001: A Space Odyssey was meant to be an accurate portrayal of the state of technology at that time). On the other hand, the inexorable progress of Moore's Law does point to the kinds of changes postulated in about the proposed timeframe.
Which is ridiculous is the assumption, not even questioned in the piece, that workers displaced from one industry will remain jobless. At most 300 years ago 90% of all workers in today's developed economies were employed in agriculture. Today it is more like 2-3%. It would have been easy to argue at the time that most of the world's workers would be unemployed in a matter of decades (and plenty of people did argue that -- remember the Luddites?).
The reality is that the working week shortened from 80 hours/week to 40 (ok, maybe not for software developers) and the type of work performed by humans has become vastly more intellectual, on average. The author is right that driving a cab or cleaning a hotel room is not fascinating work, and in the future no one will do it.
If robots end up doing half of the work we do now, which seems plausible, chances are we will work only 75% as much as today and have 1.5x the economic output, and unemployment won't change a whit.
This is totally off-topic but I can't resist sharing this little factoid: apparently the length of an audio CD (i.e. approximately 74 minutes) was chosen so that a full recording of Beethoven's 9th Symphony would fit on a single CD. So by your logic (which seems credible to me), those here-today-gone-tomorrow girl and boy bands are still tailoring their production around a format pioneered by old Ludwig Van in the early 19th century.
Most importantly, the user experience needs to be attractive since this is a very competitive space (and a lot of your competition has a compelling price point: free). Take a long, hard look at Amazon.com, which is the best e-commerce website I know. Notice how they have striven to make the purchasing process fun and informative. Notice also how the information-rich experience they provide helps to cross- and upsell customers ("People who bought X also bought Y"). If you can include ratings, recommendations, user comments, etc. in your site in a way that is slick and easy to use, that will definitely help to attract and retain customers.
From this perspective something like a proxy for file transfers is not so important (not to mention fairly impractical). If other users can't see your full library and can't see your IP address in their search results (the latter might enable smart bots to "guess" what your library contains), the only way they can determine that you are sharing massively is to download tons of files and see which IP addresses crop up. This is because they will only see your IP when they actually start downloading.
All this to say that with the latest changes in K++ and Kazaa Lite, even big time file sharers can probably rest easy.
More seriously, the article completely misses the reasons why the browser wars were so important in the mid 90s and so irrelevant now. At the time, the impact of the web was still unclear (and open to influence), and Netscape proclaimed from the rooftops that by controlling the browser they effectively controlled a new operating system capable of challenging the Windows monopoly on the desktop. What's more, they were right. Microsoft took this hubris seriously enough to throw major-league resource behind the IE development effort. This, coupled with Netscape's inability to handle its hypergrowth, led to the status quo, where IE is the only browser that matters for 95% of all PC users.
If someone were to exploit the nefarious CSS bugs that lurk in the bowels of IE and somehow achieve dominance in the PC browser market, it still wouldn't matter. The browser no longer represents a threat to Windows' hegemony. HTML rendering is now a commodity, a feature in an array of widgets that people are accustomed to using on their PC desktop. In other words, MS was right: the browser is part of the operating system.
As a software developer I can affirm that it is a joy and pleasure to have widgets like CHtmlView and CHtmlEditView (sorry, I am a - gasp! - MFC developer) available for easy integration into apps. Personally I don't give a hoot whether IE or something else is powering that widget, and nor do my users. Value is now being added by building sophisticated structures around the HTML renderer: support for XML web services and RSS feeds, drag and drop with other apps, external navigators (like tree views) that customize the browsing experience to a particular use case. This is today's competitive landscape, and the good news is that there's still plenty of scope to complement and compete with Microsoft.
One important distinction is between development of a "packaged" product or of a custom project for a customer. In many cases, a customer project will be most successful if you get something out the door and delivered to the customer as quickly as possible. Since they probably didn't know what they wanted in the first place, this will give them a chance to play around with what is, in essence, a prototype before you sit down and craft a masterpiece that no one will actually use. For product development the picture is very different. Here the temptation is to throw quick-and-dirty hacks into your product for every potential customer to land a sale. The result is a bloated, spaghetti-code-ridden product that takes longer and longer to extend because its design does not lead to easy code reuse and specialization. This is a death spiral for any software development company and must be avoid at all costs. With products it is indispensable to make orderly releases based on requirements driven by a synthesis of customer needs, not the "urgent" requirements of one customer.
I use a PC of what would have been unimaginable power a few short years ago, and it is still woefully inadequate for many of my purposes. I still spend a lot of my programming time optimizing code that I could leave in its original, elegant but inefficient state if computers were faster. And in the field of artificial intelligence, computers are finally starting to do useful things, but are sorely hampered by insufficient processing power (try a few huge matrix decompositions -- or a backgammon rollout! -- and you'll see what I mean).
Perhaps the most insightful comment in the article is the observation that no one has ever won betting against Moore's Law. I'm betting it'll be around another 10 years with change. Email me if you're taking...