So? Many people bought an XBOX to play videos and nothing else. Doesn't necessarily mean that they ever even bought Halo (I didn't buy a single game for my XBOX.)
There are plenty of good reasons for using C++ for small parts of a program which is otherwise entirely Java. For instance, many libraries you will want to use simply aren't available as pure Java, and you're forced to write JNI wrappers (this happened with our commercial code.)
There are good reasons to put a scripting language as an option as well: if you want customers to have complete configurability, then it's better not to force them to write in an inflexible language like Java.
I'd say three is the limit though, and the reasons have to be good to get that far.
This attitude may work well in small throw-away projects, but from experience I can tell you, maintaining a mixed language product is hell. Just think about the awful mess you're going to have 5 years down, when you need to do an upgrade. If the whole project is written in one language, you're going to have to find only one replacement compiler/library/development environment - which can be hard enough. If you have a mix of exotic languages, you basically can forget it, just rewrite the whole mess.
Who ever said that new languages were automatically approved? I sure didn't.
If you will read what I wrote once more, you might notice the part where I say: "if they can demonstrate a reason for using a different one."
To put that into an example, someone is going to have a very hard time convincing me that a fourth language is required, if a system were already using C++, Java and Ruby. What could a fourth language possibly bring that the others can't already do between them?
Agreed. If an underling wrote bad Java code, I would reject the code review. If they wrote bad Ruby code, I would reject the code review. There is really no difference what language they wrote, if they can demonstrate a reason for using a different one and there are no strings attached (e.g. as there are for anything attached to.NET) then no problem.
Better yet, a keyboard made out of it, so that we don't have to put up with lame-ass stories about how there are so many bacteria on our keyboards compared to a toilet seat.
Java is generally reasonably CPU efficient but harsh on memory. I think the real conclusion to be drawn is that Azureus is simply wasteful of resources. Another example of a wasteful app is Firefox, and note that Firefox does it without Java's help at all.
If your only concern is the traffic being noticeable as BitTorrent, then perhaps you only need to scramble the content. Encryption is going altogether too far, and FFS, Azureus already eats way too much CPU time without performing crypto at 50kB/s.
IMO, you're supposed to use the right tool for the job. If Java is taking up too much world for your time-critical Hello World app (if there even is such a thing as a time-critical Hello World app) then use something lighter.
When you're using the copula "desu", you generally use the topic marker "wa" instead of the subject marker "ga". If you wanted to use "ga", you could possibly say "rootkit ga doko ni arimasu ka", which would roughly mean "in what place does the rootkit exist."
You're not serious about Japanese not having many pronouns, right? It has dozens of them for different occasions. It's the only language I can think of which has about a dozen ways to say "you".
I can't exactly on-sell my only IP address, because then I wouldn't have one. Hell, one is already too few (I want about four, but for some reason the cost of four addresses is more than four times the cost of one.)
The main benefit of significantly inflating the address space is that you can allocate enormous blocks for each subscriber, and remove most of the need for NAT.
As far as the XHTML side, the main fix I see is that it will make it practically impossible for someone to write tag soup and call it XHTML2. First, serving as application/xhtml+xml is mandatory, and as Google published in their statistics, most so-called XHTML1 authors couldn't even manage that much. And second, the namespace is different from XHTML1, and a whole lot of elements have been completely changed, a whole lot were removed and a whole lot were added. This should mean that browsers, from the start, can say that invalid XHTML2 will not render.
And of course, once browsers simply refuse to render invalid content, you start getting improvements. People who want to write invalid content can use old HTML, and people who want the improved semantics can move onto XHTML2 without worrying that it will be polluted with invalid content which will eventually require them to write workarounds.
The CSS side is completely screwed still, though. In part because there is no real validation for the correctness of rendering beyond the Acid2 test.
That's exactly it. Even placing significance on the racial makeup of a business is an act of racism in itself. So what if your company is all white males? Maybe it ended up that way due to the way the people interact with each other, and not due to the fact that they all get together and shoot cars at the end of the day.
Slashdot Mirror
...which is why you see so many chess grandmasters under the age of 18.
So? Many people bought an XBOX to play videos and nothing else. Doesn't necessarily mean that they ever even bought Halo (I didn't buy a single game for my XBOX.)
"Unreal or CounterStrike never achieved the success Halo did"
Of course. That's why you can walk around a net cafe and see dozens of people playing Halo instead of Counter-Strike.
Of course I have nothing against ASM, but if you're using ASM then do you really need C++ anymore? :-)
There are plenty of good reasons for using C++ for small parts of a program which is otherwise entirely Java. For instance, many libraries you will want to use simply aren't available as pure Java, and you're forced to write JNI wrappers (this happened with our commercial code.)
There are good reasons to put a scripting language as an option as well: if you want customers to have complete configurability, then it's better not to force them to write in an inflexible language like Java.
I'd say three is the limit though, and the reasons have to be good to get that far.
This attitude may work well in small throw-away projects, but from experience I can tell you, maintaining a mixed language product is hell. Just think about the awful mess you're going to have 5 years down, when you need to do an upgrade. If the whole project is written in one language, you're going to have to find only one replacement compiler/library/development environment - which can be hard enough. If you have a mix of exotic languages, you basically can forget it, just rewrite the whole mess.
Who ever said that new languages were automatically approved? I sure didn't.
If you will read what I wrote once more, you might notice the part where I say: "if they can demonstrate a reason for using a different one."
To put that into an example, someone is going to have a very hard time convincing me that a fourth language is required, if a system were already using C++, Java and Ruby. What could a fourth language possibly bring that the others can't already do between them?
Agreed. If an underling wrote bad Java code, I would reject the code review. If they wrote bad Ruby code, I would reject the code review. There is really no difference what language they wrote, if they can demonstrate a reason for using a different one and there are no strings attached (e.g. as there are for anything attached to .NET) then no problem.
Better yet, a keyboard made out of it, so that we don't have to put up with lame-ass stories about how there are so many bacteria on our keyboards compared to a toilet seat.
Java is generally reasonably CPU efficient but harsh on memory. I think the real conclusion to be drawn is that Azureus is simply wasteful of resources. Another example of a wasteful app is Firefox, and note that Firefox does it without Java's help at all.
Actually I've just moved to KTorrent instead.
Nope, an Athlon XP 2500+. And trust me, Azureus already eats way too much CPU.
If your only concern is the traffic being noticeable as BitTorrent, then perhaps you only need to scramble the content. Encryption is going altogether too far, and FFS, Azureus already eats way too much CPU time without performing crypto at 50kB/s.
IMO, you're supposed to use the right tool for the job. If Java is taking up too much world for your time-critical Hello World app (if there even is such a thing as a time-critical Hello World app) then use something lighter.
Thing is, the very same app written in Python or Ruby would still be bigger, and yet you never hear anyone complain about that.
When you're using the copula "desu", you generally use the topic marker "wa" instead of the subject marker "ga". If you wanted to use "ga", you could possibly say "rootkit ga doko ni arimasu ka", which would roughly mean "in what place does the rootkit exist."
You're not serious about Japanese not having many pronouns, right? It has dozens of them for different occasions. It's the only language I can think of which has about a dozen ways to say "you".
I can't exactly on-sell my only IP address, because then I wouldn't have one. Hell, one is already too few (I want about four, but for some reason the cost of four addresses is more than four times the cost of one.)
The main benefit of significantly inflating the address space is that you can allocate enormous blocks for each subscriber, and remove most of the need for NAT.
They should attack it with a boomerang, or a bow and arrow...
As far as the XHTML side, the main fix I see is that it will make it practically impossible for someone to write tag soup and call it XHTML2. First, serving as application/xhtml+xml is mandatory, and as Google published in their statistics, most so-called XHTML1 authors couldn't even manage that much. And second, the namespace is different from XHTML1, and a whole lot of elements have been completely changed, a whole lot were removed and a whole lot were added. This should mean that browsers, from the start, can say that invalid XHTML2 will not render.
And of course, once browsers simply refuse to render invalid content, you start getting improvements. People who want to write invalid content can use old HTML, and people who want the improved semantics can move onto XHTML2 without worrying that it will be polluted with invalid content which will eventually require them to write workarounds.
The CSS side is completely screwed still, though. In part because there is no real validation for the correctness of rendering beyond the Acid2 test.
We all knew that. Google told us.
SMIL is actually a W3C standard.
Sounds like someone is walking the wrong way in the crowd.
Nah, that was last year. You missed it. :-)
Wasn't that something the dinosaurs used?
That's exactly it. Even placing significance on the racial makeup of a business is an act of racism in itself. So what if your company is all white males? Maybe it ended up that way due to the way the people interact with each other, and not due to the fact that they all get together and shoot cars at the end of the day.