It is more and more important for programmers to be able to, when they reach a difficult problem, find out how it has already been solved. People who have worked in the online open source world would be much better at that, and at finding the right tools.
You are right, and perhaps I was unclear. I responding to your statement that starting XML as a text format to begin with was a poor choice. Whereas, I think it was an excellent choice. What we do now is another matter, but I still think ease of development is the most important issue: it is by far the most expensive part of a project.
The obvious advantage of a text format, and the reason XML became popular, is that we had tons and tons of text processing tools already available. All you needed were parsers, and your dev tools already worked. Starting with a binary protocol would have been too steep. Same reason HTML succeeded.
The problem is that XML is being used for web services which are unlike HTML: the requesting machine will not like waiting 2-3 seconds for the response to the method call. These are interoperating applications, not people downloading text to read, so the response time is much more critical.
I agree that gzip compression is a simple solution to the network problem. It does not address the parsing time problem, and in fact exacerbates it, but in my opinion the network issue is the big one. Time works in favor of faster parsing (faster processors), but works against network issues (more congestion). I would go with compression, test the results, and only then look into a binary solution.
Look, I'm not saying water is unimportant. Scarce resources are a cause in any war. However, take a look at the ground, and talk to the people. They really believe this religion shit. Religion is not just a paper mask in front of "material" causes. It is a real motivator. Marx is wrong. For instance, why did Israel get founded in the first place? For water?
However, if you remove the desperation from people's lives, their attachment to extreme religiosity will diminish. People just want to have happy, meaningful lives, however they can get it. But that doesn't mean water is everything, any more than that gold is everything. Politics is complex, and your thesis too simple.
However, the UN inspectors found (correctly) that there were no WMD prior to the war. The threat of war was essential in getting the inspectors back in, but the rush to war after they found no evidence of WMD was dishonest. The administration made fun of the inspectors, but the fact is they were right. If everyone believed Bush then, we know better now.
That is an excellent point (which I think I also made), but not the one I was refuting. The parent claimed Sun was doing all this to keep Solaris the best Java platform. I simply think that idea had no merit.
Apple distributes their own, with features that have only now made it into the Sun JVM for other OSes (shared memory, etc). It is most definately first tier, and has been done with Sun's full support.
The FreeBSD issue was a licensing mistake, and is now cleared up. It shows the weakness of non-free Java for the community, but it is not evidence of a vast conspiracy to make Java slow. Could you provide such evidence for your argument?
However, in the most common case YOU are the developer using the library. Only use commons logging if you plan to redistribute your work as a library for others. If you are building an app, _do not use it_. The dev who designed it said so himself.
Re:How does it compare to OReillys book?
on
How Tomcat Works
·
· Score: 2, Informative
Well, since you asked: SessionFactory is not well serialized so when you reload the context, Hibernate creates a new one. This is because (I believe) you can't put it in JNDI in Tomcat. Thus, each time you reload you get an extra (and big) SessionFactory, and eventually run out of memory. However, if you use the Eclipse plugin (hot-code replace instead of context reloading for class changes), you will not need this so often. And certainly you shouldn't be reloading contexts in production: restart Tomcat instead.
Re:How does it compare to OReillys book?
on
How Tomcat Works
·
· Score: 2, Informative
I have used Tomcat in production many times, and for the most part it is excellent. The only trouble has been with commons.logging (grr..), the default connection pool (use c3p0 instead), and context reloading with Hibernate (only a dev problem). Resin gives it quite a run for performance, but its not free. As for plugins, Sysdeo has a great one that lets you run it in the debugger, with hot-code replace and everything
I agree. I am also unimpressed by the following analysis:
In the case of.Net, this is especially impressive, given the relatively short time the platform has been in existance. It is likely that a significant portion of the hits are in some way the result of Microsoft's marketing dollars.
Given that Google ignores punctuation, it seems most likely that they got a listing about "net language" rather than ".net language". More a result of poor methodology then marketing dollars.
Your garbage collection point is good, but I don't quite understand what you mean by "I don't believe java can be as fast as native code". Java has for some time compiled byte code to native.
Our allies are simply those who interests align with ours. Stop asking companies to do more than act in their own interests: it will never happen. The advance of open source in the corporate world has been because it offers real value, not because of ideals. Ideals may drive the creation, but not the adoption.
Well, but you are still not making your point: what is your proof that it is more complex? There are actually tools for testing code complexity, and they would give the answer. You may be right, but lines of code (or size of bzipped file) is not proof. You are just stating over and over it must be true. Code density is not easily compressed out. Perl, for instance, can be very dense, but quite obscure. Java forces explicit coding practices (sometimes quite annoyingly) like catching all exceptions. Its not just whitespaces.
Well, inside a single language that may be true. Between languages, I think it is a meaningless measure. Languages have different densities. Java, for instance, is intended to be sparse for legibility. And legibility does lead to fewer bugs.
I do stupid things all of the time in Java, but usually they are pretty easy to find because it is highly readable. So, in the case of Java, the inverse of your measure could be true.
Totally true, but Java does a better job of enforcing readable coding, so you never get into that (pretty common) obscure Perl programming. Lots of Perl code is one-off quick fixes, prototyping, glue, etc, so does not get the attention it deserves. Its not Perl's fault: its just so quick to code up.
Perl can be very beautiful. However, that's it problem: its so expressive that the code can be very individual and unique. Not good for the next guy who has to maintain the "poem" you wrote 3 years ago.
Let's not pretend Perl code is easy to read because it would be in an ideal circumstance. In the real world, I would hate to get handed a 5 year old, 1000 line Perl program to update.
That's one way to do it, but in my years of J2EE programming I have never done it that way. There are plenty of startup companies founded on 4 smart people in a room, using whatever language they feel meets the need (and interests them).
Some recent benchmarks show it is as fast as C++ (not C).
As for the startup time, you are right. However, I think you underestimate the amount of programming done for servers, and the ubiquity of server-based programs. Counting the websites and web applications you use every day, I would suspect that you use many more Java programs than you think.
Slashdot Mirror
It is more and more important for programmers to be able to, when they reach a difficult problem, find out how it has already been solved. People who have worked in the online open source world would be much better at that, and at finding the right tools.
You are right, and perhaps I was unclear. I responding to your statement that starting XML as a text format to begin with was a poor choice. Whereas, I think it was an excellent choice. What we do now is another matter, but I still think ease of development is the most important issue: it is by far the most expensive part of a project.
The obvious advantage of a text format, and the reason XML became popular, is that we had tons and tons of text processing tools already available. All you needed were parsers, and your dev tools already worked. Starting with a binary protocol would have been too steep. Same reason HTML succeeded.
The problem is that XML is being used for web services which are unlike HTML: the requesting machine will not like waiting 2-3 seconds for the response to the method call. These are interoperating applications, not people downloading text to read, so the response time is much more critical.
I agree that gzip compression is a simple solution to the network problem. It does not address the parsing time problem, and in fact exacerbates it, but in my opinion the network issue is the big one. Time works in favor of faster parsing (faster processors), but works against network issues (more congestion). I would go with compression, test the results, and only then look into a binary solution.
Look, I'm not saying water is unimportant. Scarce resources are a cause in any war. However, take a look at the ground, and talk to the people. They really believe this religion shit. Religion is not just a paper mask in front of "material" causes. It is a real motivator. Marx is wrong. For instance, why did Israel get founded in the first place? For water?
However, if you remove the desperation from people's lives, their attachment to extreme religiosity will diminish. People just want to have happy, meaningful lives, however they can get it. But that doesn't mean water is everything, any more than that gold is everything. Politics is complex, and your thesis too simple.
Umm, nothing? Religion is a means to control water? This is a joke, right?
However, the UN inspectors found (correctly) that there were no WMD prior to the war. The threat of war was essential in getting the inspectors back in, but the rush to war after they found no evidence of WMD was dishonest. The administration made fun of the inspectors, but the fact is they were right. If everyone believed Bush then, we know better now.
Yeah, those crazy greens won't let them use lead in our pipes anymore. The inspector was right to ticket them, the idiots.
But that was invented long before 1980.
That is an excellent point (which I think I also made), but not the one I was refuting. The parent claimed Sun was doing all this to keep Solaris the best Java platform. I simply think that idea had no merit.
Apple distributes their own, with features that have only now made it into the Sun JVM for other OSes (shared memory, etc). It is most definately first tier, and has been done with Sun's full support.
The FreeBSD issue was a licensing mistake, and is now cleared up. It shows the weakness of non-free Java for the community, but it is not evidence of a vast conspiracy to make Java slow. Could you provide such evidence for your argument?
However, in the most common case YOU are the developer using the library. Only use commons logging if you plan to redistribute your work as a library for others. If you are building an app, _do not use it_. The dev who designed it said so himself.
Well, since you asked: SessionFactory is not well serialized so when you reload the context, Hibernate creates a new one. This is because (I believe) you can't put it in JNDI in Tomcat. Thus, each time you reload you get an extra (and big) SessionFactory, and eventually run out of memory. However, if you use the Eclipse plugin (hot-code replace instead of context reloading for class changes), you will not need this so often. And certainly you shouldn't be reloading contexts in production: restart Tomcat instead.
I have used Tomcat in production many times, and for the most part it is excellent. The only trouble has been with commons.logging (grr..), the default connection pool (use c3p0 instead), and context reloading with Hibernate (only a dev problem). Resin gives it quite a run for performance, but its not free. As for plugins, Sysdeo has a great one that lets you run it in the debugger, with hot-code replace and everything
I agree. Too many folks allow themselves the folly of comparing others' actual accomplishments with their own mere intentions.
I agree. I am also unimpressed by the following analysis:
In the case of .Net, this is especially impressive, given the relatively short time the platform has been in existance. It is likely that a significant portion of the hits are in some way the result of Microsoft's marketing dollars.
Given that Google ignores punctuation, it seems most likely that they got a listing about "net language" rather than ".net language". More a result of poor methodology then marketing dollars.
Your garbage collection point is good, but I don't quite understand what you mean by "I don't believe java can be as fast as native code". Java has for some time compiled byte code to native.
Our allies are simply those who interests align with ours. Stop asking companies to do more than act in their own interests: it will never happen. The advance of open source in the corporate world has been because it offers real value, not because of ideals. Ideals may drive the creation, but not the adoption.
Well, but you are still not making your point: what is your proof that it is more complex? There are actually tools for testing code complexity, and they would give the answer. You may be right, but lines of code (or size of bzipped file) is not proof. You are just stating over and over it must be true. Code density is not easily compressed out. Perl, for instance, can be very dense, but quite obscure. Java forces explicit coding practices (sometimes quite annoyingly) like catching all exceptions. Its not just whitespaces.
It's "Occam", by the way.
Well, inside a single language that may be true. Between languages, I think it is a meaningless measure. Languages have different densities. Java, for instance, is intended to be sparse for legibility. And legibility does lead to fewer bugs.
I do stupid things all of the time in Java, but usually they are pretty easy to find because it is highly readable. So, in the case of Java, the inverse of your measure could be true.
As a programmer who also has an MFA in writing, I have to agree :)
Could you be more specific? Your argument is very vague. "Lines of code" surely does not directly translate into "number of bugs." That's just silly.
Totally true, but Java does a better job of enforcing readable coding, so you never get into that (pretty common) obscure Perl programming. Lots of Perl code is one-off quick fixes, prototyping, glue, etc, so does not get the attention it deserves. Its not Perl's fault: its just so quick to code up.
Perl can be very beautiful. However, that's it problem: its so expressive that the code can be very individual and unique. Not good for the next guy who has to maintain the "poem" you wrote 3 years ago.
Let's not pretend Perl code is easy to read because it would be in an ideal circumstance. In the real world, I would hate to get handed a 5 year old, 1000 line Perl program to update.
That's one way to do it, but in my years of J2EE programming I have never done it that way. There are plenty of startup companies founded on 4 smart people in a room, using whatever language they feel meets the need (and interests them).
Some recent benchmarks show it is as fast as C++ (not C).
As for the startup time, you are right. However, I think you underestimate the amount of programming done for servers, and the ubiquity of server-based programs. Counting the websites and web applications you use every day, I would suspect that you use many more Java programs than you think.