Although your idea is intriguing, I think in such cases the simplest explanation is probably the one closest to the truth. Yahoo had just announced lackluster results and their stock price was considerably lower than even a couple of months ago. It was great timing from Microsoft that allowed them to offer a significant premium to the price the stock was trading at. Anyway, as others mentioned before, a merger between Google and Yahoo would probably be blocked on anti-trust grounds.
I don't really disagree with what you are saying. My point is basically that the easier a commenting convention is to follow and the least overhead it places to development, the greater the likelihood of it being observed. And it's better to have adequate commenting that everyone follows than great commenting that is only there half the time.
I'm sure this works for a lot of people, and I would definitely be grateful if I did find such well commented code. But on the other hand it adds a lot of overhead, especially when changing the code structure significantly (e.g. refactoring). Which means that unless everybody in your team is very disciplined, after a while comments don't get written or don't match the code anymore.
The other approach is to write clean code, use good naming conventions, write unit tests, and comment only when things are not clear (and after trying to rewrite it in a better way). Of course, this can also go wrong as it depends a lot on the judgement of the individual developers.
I'm sure this is only part of the answer, but how about showing that they are still around (not just a 1.0 firework) and that people are still working on it, adding features and trying to make it even better (not abandoned like IE after winning the 'browser battle' with NS).
Nice! I'm sure most people there thought they were "this close" to solving it:)
The problem of course has a brute force solution (trying all permutations) but this quickly becomes impractical as the number of possible paths for n cities is n! or something.
It is also a case of an NP-complete problem, which if/when solved efficiently (i.e. by an algorithm of polynomial complexity) will lead to the solution of all other similarly hard NP problems.
It doesn't look like an Apple product. Especially compared to the "ridiculously slick" iPod nano, its design is pretty lame. Maybe that's not the way they though about it, but for me it makes sense: it doesn't look good enough to stand next to the iPods, Minis, PowerBooks.
I'm not sure who the "official" (if you can call it that) winner will be, but so far it seems that Hibernate is the no1 choice for new projects. Now of course Sun appears keen on improving Entity Beans after realising just how awful people found them in practice, so it is possible that there might be in the future a change in the status quo. But right now, Hibernate is the most recommended solution.
The main use of Java today is in large scale enterprise applications, usually meaning J2EE, although the current trend is the use of lighter alternatives, namely JSPs/servlets coupled with frameworks like Spring and Hibernate.
This development itself proves the big advantage Java has over C#/.Net in the enterprise arena: a far wider array of supporting libraries and frameworks, not to mention a selection of mature application servers. For this reason it will be quite hard for C# to catch up, especially since it does not bring anything remarkably new or unique to the game; it is just too similar to Java for a switch to be justified.
As to whether "traditional" enterprise systems built in Java are "done fast"... Let's just say that its biggest drawback (always in the enterprise context) according to its opponents is the sheer complexity of developing, configuring and deploying any application of reasonable size. Hence the appeal of frameworks like Hibernate.
The problem is finding the intelligent, capable people, and convincing them to stay at the job. At least in a big organisation I used to work just after uni, where grads would get rotated to different functions across IT, the best people would opt for development roles and quit really fast if put in operations/support.
Of course this is not meant to degrade ops people or the work they do. It's just that the work doesn't have the glamour associated with coding, at least in the eyes of recent compsci grads.
It's good to see enumerators formally supported, but you were not really _forced_ to use plain ints up to now. It is just some sort of an anti-pattern, which everybody seems to be using happily.
The type-safe enum pattern shows the correct way of handling enumerations. And you can the Jakarta Commons Lang library to make it a bit easier.
AFAIK they will not be breaking existing code... If anything, they had to go out of their way (e.g. the ugly foreach statement) to ensure backward compatibility. In 1.4, the assert keyword might have caused problems, but now I don't think that's the case.
You might find Pair Programming, 40-hour week and continuous integration a little more exciting. I'm not saying that it works or even that you should have heard of it, but a "quick look" is definitely not a good reason for rejecting it.
Personally I find that some of its suggested methods are right on the spot while others a bit on the idealistic side. Still, I would like to try it and see first-hand how it works in a proper business environment.
Sun certification does not have any effect on JBoss's functionality. As I see it, it is just a marketing matter, being able to say "This is a Sun certified J2EE App Server", so that whoever makes the decision on using it (and mainly commercial organisations) can be confident that it really does what it is supposed to do.
btw, as it is a server, it does not run on the client.
Slashdot Mirror
Although your idea is intriguing, I think in such cases the simplest explanation is probably the one closest to the truth. Yahoo had just announced lackluster results and their stock price was considerably lower than even a couple of months ago. It was great timing from Microsoft that allowed them to offer a significant premium to the price the stock was trading at. Anyway, as others mentioned before, a merger between Google and Yahoo would probably be blocked on anti-trust grounds.
I don't really disagree with what you are saying. My point is basically that the easier a commenting convention is to follow and the least overhead it places to development, the greater the likelihood of it being observed. And it's better to have adequate commenting that everyone follows than great commenting that is only there half the time.
I'm sure this works for a lot of people, and I would definitely be grateful if I did find such well commented code. But on the other hand it adds a lot of overhead, especially when changing the code structure significantly (e.g. refactoring). Which means that unless everybody in your team is very disciplined, after a while comments don't get written or don't match the code anymore.
The other approach is to write clean code, use good naming conventions, write unit tests, and comment only when things are not clear (and after trying to rewrite it in a better way). Of course, this can also go wrong as it depends a lot on the judgement of the individual developers.
I'm sure this is only part of the answer, but how about showing that they are still around (not just a 1.0 firework) and that people are still working on it, adding features and trying to make it even better (not abandoned like IE after winning the 'browser battle' with NS).
ID is not a theory, it's a hypothesis that is not supported by any evidence.
Why wait for this then and not use the Mozilla suite instead?
Nice! I'm sure most people there thought they were "this close" to solving it :)
The problem of course has a brute force solution (trying all permutations) but this quickly becomes impractical as the number of possible paths for n cities is n! or something.
It is also a case of an NP-complete problem, which if/when solved efficiently (i.e. by an algorithm of polynomial complexity) will lead to the solution of all other similarly hard NP problems.
It doesn't look like an Apple product. Especially compared to the "ridiculously slick" iPod nano, its design is pretty lame. Maybe that's not the way they though about it, but for me it makes sense: it doesn't look good enough to stand next to the iPods, Minis, PowerBooks.
Not to mention getting a new watch...
I'm not sure who the "official" (if you can call it that) winner will be, but so far it seems that Hibernate is the no1 choice for new projects. Now of course Sun appears keen on improving Entity Beans after realising just how awful people found them in practice, so it is possible that there might be in the future a change in the status quo. But right now, Hibernate is the most recommended solution.
The main use of Java today is in large scale enterprise applications, usually meaning J2EE, although the current trend is the use of lighter alternatives, namely JSPs/servlets coupled with frameworks like Spring and Hibernate.
This development itself proves the big advantage Java has over C#/.Net in the enterprise arena: a far wider array of supporting libraries and frameworks, not to mention a selection of mature application servers. For this reason it will be quite hard for C# to catch up, especially since it does not bring anything remarkably new or unique to the game; it is just too similar to Java for a switch to be justified.
As to whether "traditional" enterprise systems built in Java are "done fast"... Let's just say that its biggest drawback (always in the enterprise context) according to its opponents is the sheer complexity of developing, configuring and deploying any application of reasonable size. Hence the appeal of frameworks like Hibernate.
I'm afraid it's true... The front page now reads:
Welcome to Wikipædia Britannica, the free-content encyclopædia that anyone can edit.
Where is the web-as-we-know-it heading? I sure hope that someone (maybe RMS and/or Lawrence Lessig?) can save us...
The problem is finding the intelligent, capable people, and convincing them to stay at the job. At least in a big organisation I used to work just after uni, where grads would get rotated to different functions across IT, the best people would opt for development roles and quit really fast if put in operations/support.
Of course this is not meant to degrade ops people or the work they do. It's just that the work doesn't have the glamour associated with coding, at least in the eyes of recent compsci grads.
Yup, totally agree with the above, with the addition of Quintessential Player (which made me ditch winamp)
The Search feature is right at the bottom of the page, isn't it?
Isn't "Vetican City" really a country, with its own currency (version of euro anyway) and flag
?
Depending on the refeernce point for that 30% figure, it could also be 3.8461538461538461538461538461538 objects :) How do you track *that*?
It's good to see enumerators formally supported, but you were not really _forced_ to use plain ints up to now. It is just some sort of an anti-pattern, which everybody seems to be using happily.
The type-safe enum pattern shows the correct way of handling enumerations. And you can the Jakarta Commons Lang library to make it a bit easier.
AFAIK they will not be breaking existing code... If anything, they had to go out of their way (e.g. the ugly foreach statement) to ensure backward compatibility. In 1.4, the assert keyword might have caused problems, but now I don't think that's the case.
We are getting off of topic, but actually on Java I'd rather break the first rule :)
"Thinking In Java" is not too slim (not massive either though), but it's a really great book.
>We all want 'big books'
No we don't. Personally, since reading Kernighan & Ritchie, I've been convinced that good books have to be slim.
(another precondition is that it doesn't have a "Learn X in x minutes/hours/days" title)
You might find Pair Programming, 40-hour week and continuous integration a little more exciting. I'm not saying that it works or even that you should have heard of it, but a "quick look" is definitely not a good reason for rejecting it.
Personally I find that some of its suggested methods are right on the spot while others a bit on the idealistic side. Still, I would like to try it and see first-hand how it works in a proper business environment.
Sun certification does not have any effect on JBoss's functionality. As I see it, it is just a marketing matter, being able to say "This is a Sun certified J2EE App Server", so that whoever makes the decision on using it (and mainly commercial organisations) can be confident that it really does what it is supposed to do.
btw, as it is a server, it does not run on the client.