I think open source is driving the value of software down, but I think there's a limit to how far it can go.
So far closed source has been indirectly enabling open source by keeping college educated programmers gainfully employed so that they can work on open source projects without having to make money on them.
As software development becomes less viable as a business model, fewer young people will be interested in going into it. Even those who have a natural aptitude for programming may avoid it because they are not interested in the service model.
In the old days everyone would say "we're professionals so we get the job done no matter what it takes". Of course, recognized professionals like Doctors and Lawyers, don't work this way. So we were paying for our ego.
The only thing with more wrong predictions of death than Star Trek is Microsoft.
Star Trek was supposed to die because Star Trek II killed off Spock.
TNG was not going to make it because their was no vulcan in the regular crew.
The TNG movies weren't going to make it because they didn't have Kirk and Spock (even Paramount believed that so we ended up with the silly plot of Generations).
The fact that Symbian C++ developers have a bit of a learning curve to climb before they can produce android apps should be a source of encouragement for anyone who is starting from scratch to develop one. Let one of the kids on the bench have a turn at bat.
Actually, one of the smartest things MS does is to usually ignore what people think of them as long as the money keeps coming in. Sun and now Yahoo are reaping the result of being more concerned with hurting MS than making good business decisions.
While I respect Kernighan and Plauger, I don't accept a definition of Programming IQ as a standard just because some smart and famous guys propose one. Plauger has forgotten more about C libraries than I will ever know, but he's been known to express opinions on aspects of programming that he knows little or nothing about. For example, claiming that there's nothing unique about real-time programming.
It's not really about process but about power. Management reserves the right to change requirements, ignore agreed upon limitations, expect quality code without providing time for testing etc.
Strangely enough, sometimes these behaviors are appropriate. You may be working at a start-up that just lost some of its funding and it's a do or die situation.
"Actually, the trick is knowing that you _aren't_ a great programmer (honestly what are the odds that you are a great programmer?), and thus choosing to reuse code from better (and hopefully great) programmers."
This is a similiar flaw to believing that ISO certification means that a company will always create great products. Just as each product should be evaluated on its own (the UL approach), so software should be evaluated on its merits, not on the reputation of the programmer.
There's no such thing as a "great programmer" in the sense that one individual excels in every aspect of software development. Average programmers (whatever that means) are quite capable of producing quality code. Quality code depends more on the dedication of the developers on the project than it does on programming IQ (again, whatever that means).
Well, I think the GP has a point. These days there seems to be more focus on worrying about the future than producing a high-quality product today (where quality means the least buggy product). Often you spend a lot of time creating sophisticated abstractions to ease future extensions only to find that the future is so different than you expect that your elegant architecture is just code bloat.
"Approximately 5000 soldiers died defending us and our freedom."
Yes, they did, but unfortunately despite their good intentions and their great sacrifices there never was any threat to the US. Iraq neither had WMDs nor any way to deliver them to the US if they did have them. So, in the end they died for nothing but Bush's ego.
Are unix domain sockets the fastest IPC method? Is the content of each X packet highly efficient? Are the number of packets required for an operation optomized for speed? Is there minimal parsing invovled. In other words, there's a lot more to efficiency than just the IPC method.
Networks really aren't fundamental to windowing environments. X was designed around the limitations of most Unix configurations of the time (a single server with clients running on fairly dumb terminals). When real workstations became available, network transparency became a nice feature that wasn't really needed in most cases. The question is whether the added complexity is justified by the importance of the feature.
You said "LINQ to SQL is no different in concept than Hibernate's HQL, or any of the other dozen self-designed query languages."
I was pointing out a difference. Whether that difference changes the "concept" depends on one's point of view. There are certainly developers who prefer to find their errors at compile-time rather than run-time. I find the difference significant. YMMV.
Slashdot Mirror
I think open source is driving the value of software down, but I think there's a limit to how far it can go.
So far closed source has been indirectly enabling open source by keeping college educated programmers gainfully employed so that they can work on open source projects without having to make money on them.
As software development becomes less viable as a business model, fewer young people will be interested in going into it. Even those who have a natural aptitude for programming may avoid it because they are not interested in the service model.
Actually, I'm a Baby Boomer. I'm not a big fan of generalizing by generation, although your theory is plausible.
In the old days everyone would say "we're professionals so we get the job done no matter what it takes". Of course, recognized professionals like Doctors and Lawyers, don't work this way. So we were paying for our ego.
"Our biggest problem in process improvement is that we can't easily measure productivity."
Perhaps the difficulty in evaluating processes' efficacy should lead to the conclusion that process improvement is not a worthwhile endeavor.
Ironically, if a test-first approach were used to develop an agile methodology, you'd have to stop because
you can't write the test.
Ever notice that you never see Al Gore and Vint Cerf in the same place.
"Sounds to me like you're a windows admin at heart, and are tying to do everything from the gui."
Yeah, it's not like this a Mac or anything. It's more DOS-like.
The only thing with more wrong predictions of death than Star Trek is Microsoft.
Star Trek was supposed to die because Star Trek II killed off Spock.
TNG was not going to make it because their was no vulcan in the regular crew.
The TNG movies weren't going to make it because they didn't have Kirk and Spock (even Paramount believed that so we ended up with the silly plot of Generations).
This new movie isn't going to kill it either.
The fact that Symbian C++ developers have a bit of a learning curve to climb before they can produce android apps should be a source of encouragement for anyone who is starting from scratch to develop one. Let one of the kids on the bench have a turn at bat.
"Squatting on the spectrum is just as bad as squatting domains or houses."
Actually, it's much worse. The unallocated spectrum for communications is much more limited.
Don't worry. Bill Joy won't actually create any new technology laws or policies, he'll just write white papers and leave the implementation to others.
Actually, one of the smartest things MS does is to usually ignore what people think of them as long as the money keeps coming in. Sun and now Yahoo are reaping the result of being more concerned with hurting MS than making good business decisions.
"On Linux and Mac, printer drivers are tiny, userspace programs that translate postscript into the right printer commands."
If your description is correct, Linux and Mac users must SOL when they want to print ASCII text.
"Free software has replaced both Windows and M$'s business model."
I do not think it means what you think it means.
Underwriters Laboratories http://www.ul.com/ulprodcert.html
The comments on real-time that I was referring to Plauger made in Computer Language magazine, not in the book.
While I respect Kernighan and Plauger, I don't accept a definition of Programming IQ as a standard just because some smart and famous guys propose one. Plauger has forgotten more about C libraries than I will ever know, but he's been known to express opinions on aspects of programming that he knows little or nothing about. For example, claiming that there's nothing unique about real-time programming.
It's not really about process but about power. Management reserves the right to change requirements, ignore agreed upon limitations, expect quality code without providing time for testing etc.
Strangely enough, sometimes these behaviors are appropriate. You may be working at a start-up that just lost some of its funding and it's a do or die situation.
"Actually, the trick is knowing that you _aren't_ a great programmer (honestly what are the odds that you are a great programmer?), and thus choosing to reuse code from better (and hopefully great) programmers."
This is a similiar flaw to believing that ISO certification means that a company will always create great products. Just as each product should be evaluated on its own (the UL approach), so software should be evaluated on its merits, not on the reputation of the programmer.
There's no such thing as a "great programmer" in the sense that one individual excels in every aspect of software development. Average programmers (whatever that means) are quite capable of producing quality code. Quality code depends more on the dedication of the developers on the project than it does on programming IQ (again, whatever that means).
Well, I think the GP has a point. These days there seems to be more focus on worrying about the future than producing a high-quality product today (where quality means the least buggy product). Often you spend a lot of time creating sophisticated abstractions to ease future extensions only to find that the future is so different than you expect that your elegant architecture is just code bloat.
I guess I keep forgetting that some people treat Israel as the 51st state.
"Approximately 5000 soldiers died defending us and our freedom."
Yes, they did, but unfortunately despite their good intentions and their great sacrifices there never was any threat to the US. Iraq neither had WMDs nor any way to deliver them to the US if they did have them. So, in the end they died for nothing but Bush's ego.
Are unix domain sockets the fastest IPC method? Is the content of each X packet highly efficient? Are the number of packets required for an operation optomized for speed? Is there minimal parsing invovled. In other words, there's a lot more to efficiency than just the IPC method.
Networks really aren't fundamental to windowing environments. X was designed around the limitations of most Unix configurations of the time (a single server with clients running on fairly dumb terminals). When real workstations became available, network transparency became a nice feature that wasn't really needed in most cases. The question is whether the added complexity is justified by the importance of the feature.
You said "LINQ to SQL is no different in concept than Hibernate's HQL, or any of the other dozen self-designed query languages."
I was pointing out a difference. Whether that difference changes the "concept" depends on one's point of view. There are certainly developers who prefer to find their errors at compile-time rather than run-time. I find the difference significant. YMMV.
Is HQL statically typed?