Universities today make a significant sum of money out of licensing and commercializing research innovations, adding millions to university coffers. Remove the ability to protect university IP and that revenue stream dries up, and all that lost money would have to come from somewhere else.
On a related point, I'd spun out some technology from university research a few years back, and last year sold the resulting company. I can tell you that the resulting tax bills produced significantly more revenue for the government than their original expenditures on our project.
The get-anything-out-now mentality alluded to by a number of posters is certainly one of the worst things that came out of the dot-com boom (yeah, it was there before, but not at that level).
Does anyone ever worry about maintenance anymore?
I manage a small development team working on commercial software. Yes, its important for us to get software out quickly. But thats one of the reasons that we insist on good quality, clean and readable code.
We leverage off our existing code base for each new iteration; some of the code has been in use for years (though now used in ways we never expected of course). If we didn't take the time earlier to make that code cleaner, we'd be paying the price everytime we go back and have to work on that code again, whether to just fix bugs, extend it to do something new, integrate it with a new package, etc. This is true both for the original programmers who wrote the stuff, other people on the team who have to wade into it, or new people we bring on board.
I've done things the no-documentation, make-it-work, anything-goes approach before, and I know I'm never going back that way again, for anything more than hacked together demos. I expect everyone on my team (myself definitely included) to write clean, well-documented and understandable code, following our coding conventions. Everyone gets flak from everyone else when this doesn't happen (its quickly corrected). Sure, sometimes it doesn't happen in the very first cut on a tight deadline, but you can bet cleanup is the next thing that happens in the schedule.
That is a bit of a stretch; no methodology suits all situations, and XP certainly does not solve all problems. It does however suggest a number of good practices, many of which can help out a lot of programming teams. As of course do lots of other methodologies.
One of the approaches that XP adopts that may be a big help towards writing readable code is pair programming. You're a lot likely to get away with shortcuts if you've got someone working with you, who will know what shortcuts you take.
This won't always happen of course (take the situation of two hotshot programmers, each trying to out-cool the other), but this, and other techniques, such as code reviews, team leaders who preach (and practice!) good coding standards, can be a big help.
Dr. Sandra Witelson of McMaster University did some of the work on Einstein's brain. I attended a talk by her a few months back, which was quite interesting. There is a review/summary of the talk at:
Her work involves studying the effect of brain morphology on function, and yes, they did in fact find differences in his brain. (And yes, he'd agreed to donate his brain to researchers before he died)
There are MacOS ports of several Unix scripting languages and GUI toolkits, e.g. Tcl/Tk and Python/TkInter.
These efforts tend to rely on far too few volunteers. A few more people being willing to hack on Tk for example would be very much appreciated.
This would help two groups. First, Mac people would have some new alternatives for doing development. Having done both extensively, its a lot easier to build apps with Tcl/Tk than with the Mac toolbox! Cleaning up some of the rough edges would lower the barriers for Mac people to start developing, just as it has on Unix.
The second benefit would be to people who've developed software on Unix versions of Tcl, Python, Perl or whatever. For them, it gives them yet another platform they can deploy their software on. And given the types of feedback they're likely to get from Mac people, probably improve their software in the process.
The range of Linux users is expanding, and many people would like to expand it further. I doubt your statement that Linux is well designed for its current user base (as opposed to the one two years ago) is even close to accurate lately.
Further, even if I'm an open source hacker working on package X, that doesn't imply that I have the faintest care or concern for the internals of package Y, which I'm just trying to use! Even hardcore open source hackers still use large parts of Linux as a tool, as consumers of the technology.
I did part of my undergrad at U of C way back when Theo was hanging around there. He's never been the type that really valued self-promotion, at least not directed at people who he didn't consider smart. To say he often comes off abrupt or arrogant is an understatement.
If the "oil and gas" crowd are willing to spend the time talking with the media and helping them to deliver stories, and the open source hackers aren't out looking for opportunities to talk, at least until the people they're talking to are deemed worthy of talking to, what would you expect the stories to be about?
FYI, Brian Kernighan had a paper at the Tcl/Tk conference a couple of years ago. Among a bunch of other things, he spent a good amount of time talking about how he was using VB on some of the projects he was currently involved with.
Slashdot Mirror
Universities today make a significant sum of money out of licensing and commercializing research innovations, adding millions to university coffers. Remove the ability to protect university IP and that revenue stream dries up, and all that lost money would have to come from somewhere else.
On a related point, I'd spun out some technology from university research a few years back, and last year sold the resulting company. I can tell you that the resulting tax bills produced significantly more revenue for the government than their original expenditures on our project.
The get-anything-out-now mentality alluded to by a number of posters is certainly one of the worst things that came out of the dot-com boom (yeah, it was there before, but not at that level).
Does anyone ever worry about maintenance anymore?
I manage a small development team working on commercial software. Yes, its important for us to get software out quickly. But thats one of the reasons that we insist on good quality, clean and readable code.
We leverage off our existing code base for each new iteration; some of the code has been in use for years (though now used in ways we never expected of course). If we didn't take the time earlier to make that code cleaner, we'd be paying the price everytime we go back and have to work on that code again, whether to just fix bugs, extend it to do something new, integrate it with a new package, etc. This is true both for the original programmers who wrote the stuff, other people on the team who have to wade into it, or new people we bring on board.
I've done things the no-documentation, make-it-work, anything-goes approach before, and I know I'm never going back that way again, for anything more than hacked together demos. I expect everyone on my team (myself definitely included) to write clean, well-documented and understandable code, following our coding conventions. Everyone gets flak from everyone else when this doesn't happen (its quickly corrected). Sure, sometimes it doesn't happen in the very first cut on a tight deadline, but you can bet cleanup is the next thing that happens in the schedule.
That is a bit of a stretch; no methodology suits all situations, and XP certainly does not solve all problems. It does however suggest a number of good practices, many of which can help out a lot of programming teams. As of course do lots of other methodologies.
One of the approaches that XP adopts that may be a big help towards writing readable code is pair programming. You're a lot likely to get away with shortcuts if you've got someone working with you, who will know what shortcuts you take.
This won't always happen of course (take the situation of two hotshot programmers, each trying to out-cool the other), but this, and other techniques, such as code reviews, team leaders who preach (and practice!) good coding standards, can be a big help.
Here's another piece to this (sorry...)
h tml
Dr. Sandra Witelson of McMaster University did some of the work on Einstein's brain. I attended a talk by her a few months back, which was quite interesting. There is a review/summary of the talk at:
http://www-msu.mcmaster.ca/sil/20_01_00/einstein.
Her work involves studying the effect of brain morphology on function, and yes, they did in fact find differences in his brain. (And yes, he'd agreed to donate his brain to researchers before he died)
There are MacOS ports of several Unix scripting languages and GUI toolkits, e.g. Tcl/Tk and Python/TkInter.
These efforts tend to rely on far too few volunteers. A few more people being willing to hack on Tk for example would be very much appreciated.
This would help two groups. First, Mac people would have some new alternatives for doing development. Having done both extensively, its a lot easier to build apps with Tcl/Tk than with the Mac toolbox! Cleaning up some of the rough edges would lower the barriers for Mac people to start developing, just as it has on Unix.
The second benefit would be to people who've developed software on Unix versions of Tcl, Python, Perl or whatever. For them, it gives them yet another platform they can deploy their software on. And given the types of feedback they're likely to get from Mac people, probably improve their software in the process.
The range of Linux users is expanding, and many people would like to expand it further. I doubt your statement that Linux is well designed for its current user base (as opposed to the one two years ago) is even close to accurate lately.
Further, even if I'm an open source hacker working on package X, that doesn't imply that I have the faintest care or concern for the internals of package Y, which I'm just trying to use! Even hardcore open source hackers still use large parts of Linux as a tool, as consumers of the technology.
I did part of my undergrad at U of C way back when Theo was hanging around there. He's never been the type that really valued self-promotion, at least not directed at people who he didn't consider smart. To say he often comes off abrupt or arrogant is an understatement.
If the "oil and gas" crowd are willing to spend the time talking with the media and helping them to deliver stories, and the open source hackers aren't out looking for opportunities to talk, at least until the people they're talking to are deemed worthy of talking to, what would you expect the stories to be about?
FYI, Brian Kernighan had a paper at the Tcl/Tk conference a couple of years ago. Among a bunch of other things, he spent a good amount of time talking about how he was using VB on some of the projects he was currently involved with.