I'd recommend looking into StarTeam from StarBase. And this is even despite having been a developer there a while back:-)
As a developer, I usually prefer CVS, but StarTeam works quite well for a whole office, Word docs and all. For the Windows-based world you mention, it seems quite appropriate. They have many different clients, and I've seen it used in mixed Windows & Solaris & Linux environments.
In general, if a shop can't use CVS, and especially if they're using SourceSafe, I can in good conscience recommend it. And remember, friends don't let friends use SourceSafe:-)
IANAL, YMMV, etc. I'm not sure if it will work for you, but it's definitely worth investigating
And besides, when was the last time you read email on an 80 column terminal?
Oh, a little while back. However... when was the last time you read a magazine with wider lines than that? Most publishers know that long lines of text makes it harder for the average person to read. It's one of the big reasons that most newspapers and magazines break stories up into columns instead of splaying them accross the whole width of a page. (and one of the big failings of a large number of websites)
You don't have to take that flexibility away, since it's been given. However, there are proper ways to do it. RFC 2046 clearly states regarding text/plain:
Plain text is intended to be displayed "as-is"
However, RFC 1896 defined text/enriched to achieve that auto-wrapping that you desire. Or your mail program could just use text/html.
One really good example of this is the HTML standard that was totally overrun by the industry instead of leading it.
That's actually a good example, but not the way you seem to imply. Those working on HTML 3.0 took great pains to work with the industry (Netscape, Spyglass, et al). The industry kept contributing and promising that they would support it. Then once it was finallized, they said "Yes, that's nice. But we've decided to do our own thing"
In that case the standard was kept up and even made to give the boost needed by the industry. But the industry did a 180 and turned their backs. So, it's not that the standard lagging was the problem, but rather that the companies choosing to flout them was.
E-commerce times are tough, and the $1 billion online adult site industry is no exception.
...have combined to cause tectonic changes in the industry...
One early one was Galaxy Quest
on
AI Movie Promo
·
· Score: 2
They had done it quite well, with a professionally designed site that aped the worst of old tv-show fan sites. In and of itself, Travis Latke's Galaxy Quest Vaults made for quite an intertaining read. As fun a sendup of fan sites as the movie was of Star Trek.
unit test first... I would say this could be a good idea, but I suspect that it's impossible more often than not. And when there's scope creep and the deadline's tomorrow, do we update the test plan first? yeah, right.
No, there's no "test plan" per se. You have a set of tests that you run whenever anything is changed, and especially before checking in any code. If you use makefiles, all you need to do is type "make test" or "make check" and voila! you've verified your changes. Especially when you've got changes needed and deadlines looming, it give tremendous payoff to be able to run the unit tests and be sure that you've not broken anything in your mad dash to update. After a while, you can't afford not to test.
Years ago I'd been in companies where we did this sort of testing, and it was always found to help productivity and quality quite a lot. Then later when I was at a company where we tried actual "XP", we saw the same quality and productivity benefits. Have you done so, or are you just dismissing a technique without checking it?
pair programming... this *may* work for *some* programmers. Writing code takes man-hours. If you put two people on one task, unless that task is done at least twice as fast, you lose.
It's true that writing code takes man-hours. But some of the best code is that which is thought about and not just blindly "monkey-typed" at the keyboard. As they say in the carpentry field "Measure twice, cut once". Now if you put two people on just key-entry, then yes you loose. However, it's not just that. You have two people combining coding, design review, code review and project discussion all into the same block of time. That's where the payoff really starts to come in. The same reasoning that reactively says you can't put two people working on the same machine and keep productivity is similar to the reasoning of doubling the bodies on a project in trouble near the end to gain productivity...
You've mention scenarios that you "see", but that seems to be purely conjecture. On the other hand I've seen these principals put into practice and have seen them work. When you start to combine the programmers in the way espoused by XP, you end up with a gestalt effect where the sum of the whole is more than the sum of the parts.
Collective code ownership = chaos.
Not at all. Balkanization is.
I once wrote a TCP/IP layer for a big blue 800lbs gorilla. The code was complete, it entered testing, and was half way through (two weeks worth of testing!) when one of the other programmers decided to rewrite a section of my code suposedly to improve performance. So let's see, someone else's code with my name on it. Great!
And that is balkanization at it's best (or worst). That "my code" "my name" mentality is the whole point. Or rather, avoiding it is. If instead of "my code" you think of it as "the teams code", then you get more away from the warring little fiefdoms and more into better code. Use source control every morning to see what everybody else did the day before. Whenever you find a problem, just fix it. Of course, try to bounce it off the last people to touch that area. And count on them watching everything you do also. There should be no more of the blame-game, and "well, my code is fine, it's Jim's that broke everything". Instead, it should be "our code is broken, let me see what I can do to help".
And also often just keeping in mind the thought that others will be looking over everything you write will help keep you from doing those 'dirty' little shortcuts that we are all tempted to take.
BTW, in the case you mention, part of what you checked in should have been your unit tests. So during testing when that person started to re-write what you did, it would be quite easy to get flagged the minute he broke anything. And better yet, you'd have had a complete audit trail of the performance (since that should have been some of your unit testing) and whether performance improved, degraded or stayed about the same.
Why should we want to migrate from windows development to Linux when we doesn't get paid for our work?
Well, right off the top of my head, here are a few items:
Speak for yourself. A large number of people get paid for doing development using GNU tools. (I was getting paid to develop applications on Linux back before 1997)
Who said he was migrating from Windows?
And a little more to the point:
Ever hear of a football player taking up ballet? Needlepoint? Learning more skills can help with existing fields of work.
Perhaps he enjoys learning and programming. [And does not enjoy endless rebooting;-) ].
Perhaps he might want to get a job doing Windows and Unix programming, but can't afford a nice HP or Solaris box.
Perhaps he wants to impress his managers, and maybe even get a raise.
Cambodians might prefer to learn in their own cultural environment, not be taught safely and remotely from Amerika?
That is actually what I was thinking would more likely happen. However, I was responding to a post where rebelcool stated "we should instead ship them PEOPLE". I was just pointing out to him that if there were people in the US he wanted to do teaching, they could reach more by using technology. For teachers, the cost would be much higher to send them over and support them than with enabling those same teachers to remotely advise local Cambodians to actually perform the work.
Books have caused more and bloodier wars than any other invention in the history of creation. (Ex: Mein Kampf, Communist Manifesto.)
I'd might agree with that in principle, but not with those two you cite. I'd say that those had correlation but not causation. Definitely in the first case it was the man behind that book and his charismatic presence that were the real cause. Without him (or someone very similar) driving it, I'm sure that we never would have seen what we did in with Germany in WW II.
However, as someone already pointed out, The Bible has been the cause of some quite large conflicts.
If they do manage to achieve this, the question will be what is the impact? Will it be similar to the liberating effects of the printing press, or to that of Dynamite and other high explosives turned to war?
Or perhaps it will have more of the impact of Martin Luther's Ninety-Five Theses?
These people don't need computers, they need food and access to clean water. Nobody NEEDS computers, and emphasizing silicon over basic human needs is a sure way to create a new class of slaves.
No, they don't need computers, but what they really need is information. Information and education traditionally lead to an improvement of living conditions. And wired computers gives them the freedom to access a lot of that needed information.
It has been said "Give a man a fish, he eats for a day. Teach a man to fish, and he eats for a lifetime". That is the point here. Not to give chunks of sillicon, but to give information and learning.
Since they have none of this, it does them absolutely NO GOOD to have a computer and an internet connection. Instead of shipping these people computers, we should instead ship them PEOPLE to teach and heal them.
Actually, it might do them quite a lot of good. They are getting local people who understand computers (among them the orphans mentioned in the article) to get them setup. Then once you have them wired, in theory one person sitting in the US could teach to several schools at once. And newsgroup access in their local language (even if local servers) could greatly facilitate their learning and exchange of knowledge. Instead of having the expense of flying in individuals to each and every school, you now have the expense of wiring each school.
Basically, as far as the educating part goes, this helps to move the solution from a many-to-many problem over to being a one-to-many problem. It can help in this way by also allowing a teacher of a given subject who is just an expert in one field to 'teach' at all of those schools at once. Much easier than trying to round up a sufficient number of experts for each individual school.
Oh, and as far as needing to learn English to be able to benefit from the Internet (which I would question)... you'd be suprised how quickly those outside of the US can actually learn a new language when sufficient benefit is to be gained. Again, if you pay attention to the article you'd note that "They seemed to be able to chatter in most of the tourist languages...". All it would take is one local student at each school to learn English and that entire school could then access the "English Internet".
I think what they added was native USB support, not serial-via-USB like Handspring and Palm had previously used.
My friend recently bought a color Handspring, and it seems to be using true USB, not the slow serial-via-USB like his Palm. His impression is that it is a major gain, and very usefull.
Remember, that most programmers are not the ones that are comming up with the requirements....
No, not coming up with, but they should be reviewing and planning for changes. You don't need to over-engineer, but if a programmer knows that things can change, and then keeps that in mind and looks for ways to minimize the impact of changes, then things will run better. Also, any programmer who doesn't think about the "why" of his task and only the low-level "how" to implement it is probably not working at the 'should' level that was mentioned.
I believe what should happen is that good programmers will be able to recognize poor design requirements. Then they should know to take this to management. Management then should be able to take things back and get things clarified.
Unfortunately, since you didnt plan for the new reqs, there will be unforseen problems.
And there I think you hit the nail on the head. The projects I've seen that have had the most trouble have been those where the programmers did not get enough time up-front and/or did not follow up on getting good requirements. An experienced architech will be able to recognize those poor or rigid requirements and get to something better. That is, he should be able to from experience notice when something is wrong and then know to wade through what the client says he wants to go to what the client actually needs.
Notice again that I'm talking all about 'should' and not just blindly stating that it has to be so. I'm quite aware that in many situations it's not. Often the problem is that there's never time enough to do the job right, but always time to do it over.
. . . or mabye you're writing on a broken API like MFC, and due to project constraints, doing otherwise isn't an option.
Then in that case there would be more debugging, but if there was soo much as to take the majority of the project time, then it probably was a situation where rolling your own to begin with would have been a better solution.
Of course, hitting on the right balance is the key, but the 'should' needs to be more on doing it right to begin with, not with doing it over. Things like unit tests and code reviews working together should minimize the impact of any API bugs. And of course, the programmers should also have a good suite of regression tests in place to make things more and more solid.
A good set of tests by the programmers is one way to tip the balance away from chasing bugs and back to designing and writing code.
It is perfectly valid and is in fact a major component of any programmers job (and it SHOULD be as well).
I'd have to disagree with that. If a programmer is doing his job right, then he should spend time at the begining setting up tests but that's mainly it. Spending a lot of time after the fact trying to ensure the job was actually done correctly, or trying to track down why it wasn't should not be a major part of his job.
I know XP takes this to the extreme, but the basic principle holds true. If you're spending too much time debugging, then you might not be spending enough time on solid design and correct coding or even just determing requirements before working.
In other industries this is known as "measure twice, cut once" and the like.
A police officer in general is given a high level of initial trust. As long as the officer does nothing to harm that level of trust, their word has a large impact on another person, especially a juror. Once they harm that level of trust though, they tend to fall MUCH farther than another, non-officer would.
Well, at least according to California law, they are not supposed to be given that. The are supposed to be given no extra consideration as to trustworthyness just for being an officer of the law. And they are not even to be given extra consideration for training in observation, etc. The few times I have been called in for jury duty, this was made quite clear by the lawyers and the court.
Now, if Pennsylvania law is similar, and if the jury did give extra consideration for the witness being an officer of the law, then it sounds like at least grounds for a retrial.
A few things worry me a bit. First there's the part of the RACE working draft where they mention that if you don't follow all the MUST and MUST NOT statements "exactly", otherwise it's "likely to cause damage to the Internet"
I've found that having the source is excellent for knowing how the foundation classes are implemented,
True, for a specific VM. But then again, the foundation classes might be implemented differently in a different VM, and then your insight becomes misleading instead of enlightening. It's often not a good idea to break encapsulation. Probably going through the JLS will be more helpfull.
and for learning more advanced Java.
And also for learning bad, 'kludgy' programming. I remember back around 1.1.3 days I had a co-worker walking up and down the halls for about a week cussing out Gosling for some of the code in the JDK (and this was a guy who usually didn't swear). He was trying to use something in a more advanced way (subclassing & all), but ended up having to redo everything from scratch himself.
Now, I'm not saying that you can't learn anything from the sources, but there are much better places to look and learn clean advanced programming
Also, the source isn't included with the JDK that you download. It's a seperate download (at least that's how I did it).
For JDK 1.1.x and JFC 1.1 there is an included src.zip that has them. For later VM's you can get it from the 'community license' VM. But the bottom line (and bringing things more on-topic) is that Sun has made most of their sources available from pretty much the begining anyway. Open-sourcing their VM really doesn't help with that.
You may want to contact Sorenson or a Linux developer to look into the possibilty of licensing Sorenson Video 2 for a Linux player.
Last I heard It was Apple that needed talking to, not Sorenson. I've read often that Sorenson has told open source developers that they'd be fine with it, except that their contracts with Apple prevent them from doing so without Apple's permission.
I think this is a great idea if they do it. Javadocs are cool, but sometimes, you have to go find the source to figure out how ther *^&$ thing *really* works.
I'd have to disagree with you on that one there.
Sun already includes the public source for the class library with the JDK
Depending on one vendor's internals is a bad thing
Far too often I've seen bad coding implemented for the sake of 'optimization' and 'work-arounds'. While I'm not dismissing knowing what's going on, it's far more important to do things cleanly and to test things. A good test case run against multiple VM's is far better than a stroll through the code. Especialy if in that stroll you pick up some assumptions on how things work and missapply them later.
Also, I've seen 'fixes' people have put in that later break things worse when stepping up the VM. Just switching to IBM's VM, or from 1.1.x to 1.3.x should not cause any problems.
For an example of vendor-specific class sources, compare java.lang.String.valueOf( int ) in Sun's 1.1.x and IBM's 1.1.x. Some would recommend going with Integer.toString( int ) instead as an 'optimization'. However, it makes the code less clear and less reuseable, and, more importantly, in IBM's VM doing that is actually slower. And even in Sun's VM doing the 'optimized' thing is not significantly faster. So why then do some recommend that 'optimization'??? Because they looked into the Sun 1.1.x sources and decided to change their application's code based on their examination of the Sun sources.
the faster the heart of a certain animal beats the shorter they live
I've read things that indicate that the specific connection you mention is not causation. It's that the slower animals had less to deal with, and had more chance to develop life-prolonging mutations that payed off.
Take, for example, the rabbit and the tortoise. It may very well not be that the tortoise was slower and thus lived longer due to a slower metabolism. It could very well be that the tortoise is just slower because it has superior protection. And since it has superior protection, it does not have to get fast to get away. (This is unlike the rabbit who has to either not be seen or run really really fast in order to survive in the short-term). And then since the tortoise does not have to worry about as much, the mutations that contribute to longer-life pay off more in evolution
Otherwise, how would you explain that a pigeon has an maximum lifespan of 69 years, while a bear only has a maximum of 31?? The pigeon has a much higher metabolism. However, I'd point out that a pigeon might have a much higher chance of 'not having to worry about things' so much since it can fly away from problems easier than a bear.
So, you could say the better defense leads to longer life. The tortoise has a shell, the pigeon can fly, but the poor bear can only fight it out.
Slashdot Mirror
As a developer, I usually prefer CVS, but StarTeam works quite well for a whole office, Word docs and all. For the Windows-based world you mention, it seems quite appropriate. They have many different clients, and I've seen it used in mixed Windows & Solaris & Linux environments.
In general, if a shop can't use CVS, and especially if they're using SourceSafe, I can in good conscience recommend it. And remember, friends don't let friends use SourceSafe :-)
IANAL, YMMV, etc. I'm not sure if it will work for you, but it's definitely worth investigating
Oh, a little while back. However... when was the last time you read a magazine with wider lines than that? Most publishers know that long lines of text makes it harder for the average person to read. It's one of the big reasons that most newspapers and magazines break stories up into columns instead of splaying them accross the whole width of a page. (and one of the big failings of a large number of websites)
You don't have to take that flexibility away, since it's been given. However, there are proper ways to do it. RFC 2046 clearly states regarding text/plain:
However, RFC 1896 defined text/enriched to achieve that auto-wrapping that you desire. Or your mail program could just use text/html.
That's actually a good example, but not the way you seem to imply. Those working on HTML 3.0 took great pains to work with the industry (Netscape, Spyglass, et al). The industry kept contributing and promising that they would support it. Then once it was finallized, they said "Yes, that's nice. But we've decided to do our own thing"
In that case the standard was kept up and even made to give the boost needed by the industry. But the industry did a 180 and turned their backs. So, it's not that the standard lagging was the problem, but rather that the companies choosing to flout them was.
They had done it quite well, with a professionally designed site that aped the worst of old tv-show fan sites. In and of itself, Travis Latke's Galaxy Quest Vaults made for quite an intertaining read. As fun a sendup of fan sites as the movie was of Star Trek.
No, there's no "test plan" per se. You have a set of tests that you run whenever anything is changed, and especially before checking in any code. If you use makefiles, all you need to do is type "make test" or "make check" and voila! you've verified your changes. Especially when you've got changes needed and deadlines looming, it give tremendous payoff to be able to run the unit tests and be sure that you've not broken anything in your mad dash to update. After a while, you can't afford not to test.
Years ago I'd been in companies where we did this sort of testing, and it was always found to help productivity and quality quite a lot. Then later when I was at a company where we tried actual "XP", we saw the same quality and productivity benefits. Have you done so, or are you just dismissing a technique without checking it?
It's true that writing code takes man-hours. But some of the best code is that which is thought about and not just blindly "monkey-typed" at the keyboard. As they say in the carpentry field "Measure twice, cut once". Now if you put two people on just key-entry, then yes you loose. However, it's not just that. You have two people combining coding, design review, code review and project discussion all into the same block of time. That's where the payoff really starts to come in. The same reasoning that reactively says you can't put two people working on the same machine and keep productivity is similar to the reasoning of doubling the bodies on a project in trouble near the end to gain productivity...
You've mention scenarios that you "see", but that seems to be purely conjecture. On the other hand I've seen these principals put into practice and have seen them work. When you start to combine the programmers in the way espoused by XP, you end up with a gestalt effect where the sum of the whole is more than the sum of the parts.
Not at all. Balkanization is.
And that is balkanization at it's best (or worst). That "my code" "my name" mentality is the whole point. Or rather, avoiding it is. If instead of "my code" you think of it as "the teams code", then you get more away from the warring little fiefdoms and more into better code. Use source control every morning to see what everybody else did the day before. Whenever you find a problem, just fix it. Of course, try to bounce it off the last people to touch that area. And count on them watching everything you do also. There should be no more of the blame-game, and "well, my code is fine, it's Jim's that broke everything". Instead, it should be "our code is broken, let me see what I can do to help".
And also often just keeping in mind the thought that others will be looking over everything you write will help keep you from doing those 'dirty' little shortcuts that we are all tempted to take.
BTW, in the case you mention, part of what you checked in should have been your unit tests. So during testing when that person started to re-write what you did, it would be quite easy to get flagged the minute he broke anything. And better yet, you'd have had a complete audit trail of the performance (since that should have been some of your unit testing) and whether performance improved, degraded or stayed about the same.
Bah! Any true artist knows that the one true way to do POV-Ray is with Emacs and pov-mode. ;-)
Well, right off the top of my head, here are a few items:
And a little more to the point:
That is actually what I was thinking would more likely happen. However, I was responding to a post where rebelcool stated "we should instead ship them PEOPLE". I was just pointing out to him that if there were people in the US he wanted to do teaching, they could reach more by using technology. For teachers, the cost would be much higher to send them over and support them than with enabling those same teachers to remotely advise local Cambodians to actually perform the work.
I'd might agree with that in principle, but not with those two you cite. I'd say that those had correlation but not causation. Definitely in the first case it was the man behind that book and his charismatic presence that were the real cause. Without him (or someone very similar) driving it, I'm sure that we never would have seen what we did in with Germany in WW II.
However, as someone already pointed out, The Bible has been the cause of some quite large conflicts.
If they do manage to achieve this, the question will be what is the impact? Will it be similar to the liberating effects of the printing press, or to that of Dynamite and other high explosives turned to war?
Or perhaps it will have more of the impact of Martin Luther's Ninety-Five Theses?
No, they don't need computers, but what they really need is information. Information and education traditionally lead to an improvement of living conditions. And wired computers gives them the freedom to access a lot of that needed information.
It has been said "Give a man a fish, he eats for a day. Teach a man to fish, and he eats for a lifetime". That is the point here. Not to give chunks of sillicon, but to give information and learning.
Actually, it might do them quite a lot of good. They are getting local people who understand computers (among them the orphans mentioned in the article) to get them setup. Then once you have them wired, in theory one person sitting in the US could teach to several schools at once. And newsgroup access in their local language (even if local servers) could greatly facilitate their learning and exchange of knowledge. Instead of having the expense of flying in individuals to each and every school, you now have the expense of wiring each school.
Basically, as far as the educating part goes, this helps to move the solution from a many-to-many problem over to being a one-to-many problem. It can help in this way by also allowing a teacher of a given subject who is just an expert in one field to 'teach' at all of those schools at once. Much easier than trying to round up a sufficient number of experts for each individual school.
Oh, and as far as needing to learn English to be able to benefit from the Internet (which I would question)... you'd be suprised how quickly those outside of the US can actually learn a new language when sufficient benefit is to be gained. Again, if you pay attention to the article you'd note that "They seemed to be able to chatter in most of the tourist languages...". All it would take is one local student at each school to learn English and that entire school could then access the "English Internet".
My friend recently bought a color Handspring, and it seems to be using true USB, not the slow serial-via-USB like his Palm. His impression is that it is a major gain, and very usefull.
No, not coming up with, but they should be reviewing and planning for changes. You don't need to over-engineer, but if a programmer knows that things can change, and then keeps that in mind and looks for ways to minimize the impact of changes, then things will run better. Also, any programmer who doesn't think about the "why" of his task and only the low-level "how" to implement it is probably not working at the 'should' level that was mentioned.
I believe what should happen is that good programmers will be able to recognize poor design requirements. Then they should know to take this to management. Management then should be able to take things back and get things clarified.
And there I think you hit the nail on the head. The projects I've seen that have had the most trouble have been those where the programmers did not get enough time up-front and/or did not follow up on getting good requirements. An experienced architech will be able to recognize those poor or rigid requirements and get to something better. That is, he should be able to from experience notice when something is wrong and then know to wade through what the client says he wants to go to what the client actually needs.
Notice again that I'm talking all about 'should' and not just blindly stating that it has to be so. I'm quite aware that in many situations it's not. Often the problem is that there's never time enough to do the job right, but always time to do it over.
Then in that case there would be more debugging, but if there was soo much as to take the majority of the project time, then it probably was a situation where rolling your own to begin with would have been a better solution.
Of course, hitting on the right balance is the key, but the 'should' needs to be more on doing it right to begin with, not with doing it over. Things like unit tests and code reviews working together should minimize the impact of any API bugs. And of course, the programmers should also have a good suite of regression tests in place to make things more and more solid.
A good set of tests by the programmers is one way to tip the balance away from chasing bugs and back to designing and writing code.
I'd have to disagree with that. If a programmer is doing his job right, then he should spend time at the begining setting up tests but that's mainly it. Spending a lot of time after the fact trying to ensure the job was actually done correctly, or trying to track down why it wasn't should not be a major part of his job.
I know XP takes this to the extreme, but the basic principle holds true. If you're spending too much time debugging, then you might not be spending enough time on solid design and correct coding or even just determing requirements before working.
In other industries this is known as "measure twice, cut once" and the like.
Well, at least according to California law, they are not supposed to be given that. The are supposed to be given no extra consideration as to trustworthyness just for being an officer of the law. And they are not even to be given extra consideration for training in observation, etc. The few times I have been called in for jury duty, this was made quite clear by the lawyers and the court.
Now, if Pennsylvania law is similar, and if the jury did give extra consideration for the witness being an officer of the law, then it sounds like at least grounds for a retrial.
A few things worry me a bit. First there's the part of the RACE working draft where they mention that if you don't follow all the MUST and MUST NOT statements "exactly", otherwise it's "likely to cause damage to the Internet"
Then there's the issue of the chairman of the IETF basically calling this premature...
True, for a specific VM. But then again, the foundation classes might be implemented differently in a different VM, and then your insight becomes misleading instead of enlightening. It's often not a good idea to break encapsulation. Probably going through the JLS will be more helpfull.
And also for learning bad, 'kludgy' programming. I remember back around 1.1.3 days I had a co-worker walking up and down the halls for about a week cussing out Gosling for some of the code in the JDK (and this was a guy who usually didn't swear). He was trying to use something in a more advanced way (subclassing & all), but ended up having to redo everything from scratch himself.
Now, I'm not saying that you can't learn anything from the sources, but there are much better places to look and learn clean advanced programming
For JDK 1.1.x and JFC 1.1 there is an included src.zip that has them. For later VM's you can get it from the 'community license' VM. But the bottom line (and bringing things more on-topic) is that Sun has made most of their sources available from pretty much the begining anyway. Open-sourcing their VM really doesn't help with that.
Last I heard It was Apple that needed talking to, not Sorenson. I've read often that Sorenson has told open source developers that they'd be fine with it, except that their contracts with Apple prevent them from doing so without Apple's permission.
Here's a mention
I'd have to disagree with you on that one there.
Far too often I've seen bad coding implemented for the sake of 'optimization' and 'work-arounds'. While I'm not dismissing knowing what's going on, it's far more important to do things cleanly and to test things. A good test case run against multiple VM's is far better than a stroll through the code. Especialy if in that stroll you pick up some assumptions on how things work and missapply them later.
Also, I've seen 'fixes' people have put in that later break things worse when stepping up the VM. Just switching to IBM's VM, or from 1.1.x to 1.3.x should not cause any problems.
For an example of vendor-specific class sources, compare java.lang.String.valueOf( int ) in Sun's 1.1.x and IBM's 1.1.x. Some would recommend going with Integer.toString( int ) instead as an 'optimization'. However, it makes the code less clear and less reuseable, and, more importantly, in IBM's VM doing that is actually slower. And even in Sun's VM doing the 'optimized' thing is not significantly faster. So why then do some recommend that 'optimization'??? Because they looked into the Sun 1.1.x sources and decided to change their application's code based on their examination of the Sun sources.
Well... that's why emacs has the handy little alt-/ completion. To do the typing for you
Of course, I did work with one guy who did all his Java typing in Python. Very fast, productive and low-bug guy.
I've read things that indicate that the specific connection you mention is not causation. It's that the slower animals had less to deal with, and had more chance to develop life-prolonging mutations that payed off.
Take, for example, the rabbit and the tortoise. It may very well not be that the tortoise was slower and thus lived longer due to a slower metabolism. It could very well be that the tortoise is just slower because it has superior protection. And since it has superior protection, it does not have to get fast to get away. (This is unlike the rabbit who has to either not be seen or run really really fast in order to survive in the short-term). And then since the tortoise does not have to worry about as much, the mutations that contribute to longer-life pay off more in evolution
Otherwise, how would you explain that a pigeon has an maximum lifespan of 69 years, while a bear only has a maximum of 31?? The pigeon has a much higher metabolism. However, I'd point out that a pigeon might have a much higher chance of 'not having to worry about things' so much since it can fly away from problems easier than a bear.
So, you could say the better defense leads to longer life. The tortoise has a shell, the pigeon can fly, but the poor bear can only fight it out.