ThinkingRock (http://www.trgtd.com.au/) and Freeplane (http://freeplane.sourceforge.net) come to mind instantly, as applications I use all the time. Neither of them generate code or have any distinct connection to development.
Let's see a simple example. In Python there is a subtle matter of memory management that can be dangerous to the untrained programmer. When you copy a list like this: a = b you are creating a pointer to the other list, when you copy like this: a = b[:] you are allocating memory for a new list and copying the contents.
When you know C, the difference between the two copy instructions above is obvious, but if you don't know what is memory management this can become very difficult to understand. I bet there are many bugs created by Java, Python, and other modern languages that come from this inability to understand how the language works under the hood.
Well, in all fairness to Java, the memory management rules are pretty simple - people rag on Java for being too simple, but they don't consider how easy it is to actually understand what happens when you pass copies of references around. And there are no exceptions to passing copies of references as method arguments; it's how it's done, and the only way it's done.
That makes Java far more "knowable" than python, for better or for worse, because the rules are constant unless some moron decides to do things differently than the Java conventions suggest and refuses to document it.
Java nudges you really hard towards an acceptable middle. That hurts the people who really, really know what they're doing (and helps the people who know even more than the people who really, really know what they're doing, because they can game the JIT) but it means that even newbies can generally create decent java - and if they do it wrong, java punishes them enough that they have a real impetus to get it more or less right.
Of course, with all that said, C is a better language to master first. By all means, teach them C.
The test is invalid. He's actually doing far MORE work with his "EJB" than a "real" EJB application would. I've written a version of his application, using actual EJBs and a decent architecture. The memory usage is nowhere near "worse" with the EJB version, because the container caches the entities. The scalability he illustrates is rubbish.
Another obvious problem is that he's "testing EJBs" by completely ignoring them. He uses Java 1.4, sure, but the bigger problem is that he's not actually using EJBs at all - he's fetching the data directly from the DB in the servlet, and his "local EJB" returns the data immediately while his "remote EJB" serializes it.
This isn't what EJB does.
This is a retarded "benchmark." A real benchmark might be useful, but it'd require actually figuring out what kind of EJB implementation would make sense on the backend, remote or local. This test is completely invalid, I'm afraid.
"According to the survey of 104 companies in North America, the cost advantage of Windows over Linux for the four workloads ranges from 11 percent to 22 percent over a five-year period."
That's MY concern - it's a five-year study, but uses Win2K? How? That's like requiring twenty years of Java experience... when Java's only ten years old.
For me, the best scifi worlds would have to be... William Gibson's Sprawl (from Neuromancer, Count Zero, Mona Lisa Overdrive) or Dune, with Isaac Asimov's Foundation in the running.
Neuromancer is so gritty, so unexpected, that it would be marvelous (and scary as hell) to live in it.
Dune is amazingly complex, and awe-inspiring until Herbert went 'round the bend a bit at the end... and a previous poster nailed it: the prequels suck.
That's the thing the story's missing: it doesn't say what the terms are. It just says "10% of profits as defined." That's not very good: maybe "profits" was defined as "stuff left over after we paid everything out," which would always be $0, since they probably don't manage a reservoir of cash to pay 10% from...
I was unaware that performance meant having to put out new stable versions every so often. Have you tested Orion? What about it failed for you? Would you rather they released buggy versions as stable, or would you rather them point out "YMMV" with new features?
Personally, I prefer the latter; when I use an experimental version of Orion, I get the latest and greatest of their codebase... and when I need to be able to rely on certain features, I go for the stable. (I find the experimental code stable enough for production work, but hey.)
You decided to move away from Orion to Tomcat... man, your development team must have screamed bloody murder because of the deployment phase.
A few of the things that've bitten me lately: Tomcat's pisspoor choice of JNDI containers, which can (or can't) support Datasources, depending on how much of your system you screw up. Tomcat's handling of output streams in buffered output. Tomcat's oversized buffers, which negatively impact performance in a big, big way. Tomcat's performance, which is astounding... again, in a negative way. Jasper, for a long time, was horribly broken; now it's less so. (They're rewriting it, thank God.) The JSP engine's inability to load taglib descriptors from jar files.
By "compliance testing," I mean that I test my components under a number of containers, including Tomcat, since a lot of people use it.
And my point was that Orion, which is what gave Oracle its very good performance, has a much lower license cost, which means the figures are even better... provided you go with Orion instead of Oracle.
Silverstream has some nice performance numbers of its own, but it has the same problem WebLogic, WebSphere, and JBoss (to a somewhat lesser degree) have: you have to buy into the management process of each package in order to get anywhere with it.
BEA's a good server, if slow, once you get around the absolutely awesomely bad management tools they tout as being so good. (Hint: they're not. If they work for you, great. We've found that we end up deploying the same applications multiple times, with restarts, in order to get the thing working correctly; this is with BEA support riding alongside to make sure we're not doing something stupid. We weren't.
WebSphere... IBM, IBM, IBM. The best compliment I've ever heard about Websphere was from a fan, a developer who loved it: "It's not that bad..." (Yes, it is. In IBM's sales meetings, they crow about how they helped design the entity aspects now-hopelessly-muddled EJB spec... and then later in the meetings they denounce using entity beans altogether because WAS can't give you any good performance with them. Plus, being tied to WSAD isn't my idea of a good time.)
JBoss is really pretty nice - it's built entirely around a component architecture, so you can swap out the Tomcat crap if you need to and replace it with something that actually works. (The default servlet container that comes with JBoss is Jetty, which you should replace with the current version of jetty if you use JBoss. The Jetty that ships with JBoss has a jasper error, jasper being a component from Tomcat.) The only issues I have with JBoss are related to its strengths: the component architecture means that each component chooses how it's administered, so you end up not only learning how to handle JBoss itself, but you have to learn how to configure Jetty, or this product, or THIS product, or THIS OTHER product... I prefer one ring to rule them all, etc.
As far as performance reviews, use google!:) I've done some informal performance reviews, and I've found the two best performers were Resin and Orion, with Resin being a few milliseconds behind Orion in terms of servlet and JSP performance.
I've used Tomcat for testing against the Sun specs, and I find that it's slow and not worth the money you spend on it.
Yes, I know it's free. Pay attention.
It does a relatively poor job of implementing the spec itself, and the spec is supposed to be its reason for being. It's gotten faster over time, which is nice, but it's still not very good at handling things. Tweaks abound, but running a custom version of a servlet container isn't likely to bring comfort to you... I hope.
I'd suggest spending some money on the container, myself; Jetty is okay, but I personally prefer Orion, which is fully J2EE, fast as all get out, and very, very easy to administer. Installation of an Orion instance takes three steps: unzip, copy tools.jar, java -jar orion.jar. Done. It's also free for development, so there's no per-seat license cost for you to use it to write code.
An aside: Oracle recently posted ECPerf numbers which were very good, and Oracle licensed the Orion codebase... and Orion costs thousands less. Since ECperf yields numbers based on dollars per transaction, you'd think Orion would kick butt on ECPerf.
I find Tomcat to be acceptable only for compliance testing, because so many people think it's the best that out there (because of the price point). I've spent a lot of time having to work around Tomcat; I'd hope you didn't feel like doing the same.
I'm all for it. His position as sob sister for all the losers in the world due to his writing that inane "Hellmouth" crap gives him notoriety, but that doesn't translate into relevance, apparently. Personally, I find him and those who bleated about the hellmouth a little scary; these are people so maladjusted that I doubt they'll ever manage to get by in real life; posting a movie review that's only tangentially related to comp sci only contributes to his legacy of crap.
Come on, Katz, get a life - and psychiatric help, too, until you figure out "the Hellmouth" is a fiction created by morons who feel so sorry for themselves that they spend all their time either engaged in infantile escapism, or chirping about it, instead of living their lives.
Slashdot Mirror
ThinkingRock (http://www.trgtd.com.au/) and Freeplane (http://freeplane.sourceforge.net) come to mind instantly, as applications I use all the time. Neither of them generate code or have any distinct connection to development.
Let's see a simple example. In Python there is a subtle matter of memory management that can be dangerous to the untrained programmer. When you copy a list like this: a = b you are creating a pointer to the other list, when you copy like this: a = b[:] you are allocating memory for a new list and copying the contents.
When you know C, the difference between the two copy instructions above is obvious, but if you don't know what is memory management this can become very difficult to understand. I bet there are many bugs created by Java, Python, and other modern languages that come from this inability to understand how the language works under the hood.
Well, in all fairness to Java, the memory management rules are pretty simple - people rag on Java for being too simple, but they don't consider how easy it is to actually understand what happens when you pass copies of references around. And there are no exceptions to passing copies of references as method arguments; it's how it's done, and the only way it's done. That makes Java far more "knowable" than python, for better or for worse, because the rules are constant unless some moron decides to do things differently than the Java conventions suggest and refuses to document it. Java nudges you really hard towards an acceptable middle. That hurts the people who really, really know what they're doing (and helps the people who know even more than the people who really, really know what they're doing, because they can game the JIT) but it means that even newbies can generally create decent java - and if they do it wrong, java punishes them enough that they have a real impetus to get it more or less right. Of course, with all that said, C is a better language to master first. By all means, teach them C.
The test is invalid. He's actually doing far MORE work with his "EJB" than a "real" EJB application would. I've written a version of his application, using actual EJBs and a decent architecture. The memory usage is nowhere near "worse" with the EJB version, because the container caches the entities. The scalability he illustrates is rubbish.
Another obvious problem is that he's "testing EJBs" by completely ignoring them. He uses Java 1.4, sure, but the bigger problem is that he's not actually using EJBs at all - he's fetching the data directly from the DB in the servlet, and his "local EJB" returns the data immediately while his "remote EJB" serializes it.
This isn't what EJB does.
This is a retarded "benchmark." A real benchmark might be useful, but it'd require actually figuring out what kind of EJB implementation would make sense on the backend, remote or local. This test is completely invalid, I'm afraid.
BTW, Rickard Oberg and Cameron Purdy posted the article on JDJ's site before linuxworld got to it...
"According to the survey of 104 companies in North America, the cost advantage of Windows over Linux for the four workloads ranges from 11 percent to 22 percent over a five-year period." That's MY concern - it's a five-year study, but uses Win2K? How? That's like requiring twenty years of Java experience... when Java's only ten years old.
For me, the best scifi worlds would have to be... William Gibson's Sprawl (from Neuromancer, Count Zero, Mona Lisa Overdrive) or Dune, with Isaac Asimov's Foundation in the running.
Neuromancer is so gritty, so unexpected, that it would be marvelous (and scary as hell) to live in it.
Dune is amazingly complex, and awe-inspiring until Herbert went 'round the bend a bit at the end... and a previous poster nailed it: the prequels suck.
And the Foundation is the anti-Sprawl: a panacea.
That's the thing the story's missing: it doesn't say what the terms are. It just says "10% of profits as defined." That's not very good: maybe "profits" was defined as "stuff left over after we paid everything out," which would always be $0, since they probably don't manage a reservoir of cash to pay 10% from...
I refuse. Stallman is an idiot. You can quote me on that all you like.
Personally, I prefer the latter; when I use an experimental version of Orion, I get the latest and greatest of their codebase... and when I need to be able to rely on certain features, I go for the stable. (I find the experimental code stable enough for production work, but hey.)
You decided to move away from Orion to Tomcat... man, your development team must have screamed bloody murder because of the deployment phase.
A few of the things that've bitten me lately: Tomcat's pisspoor choice of JNDI containers, which can (or can't) support Datasources, depending on how much of your system you screw up. Tomcat's handling of output streams in buffered output. Tomcat's oversized buffers, which negatively impact performance in a big, big way. Tomcat's performance, which is astounding... again, in a negative way. Jasper, for a long time, was horribly broken; now it's less so. (They're rewriting it, thank God.) The JSP engine's inability to load taglib descriptors from jar files.
By "compliance testing," I mean that I test my components under a number of containers, including Tomcat, since a lot of people use it.
And my point was that Orion, which is what gave Oracle its very good performance, has a much lower license cost, which means the figures are even better... provided you go with Orion instead of Oracle.
I'm very aware it's the reference implementation - that's what makes its poor compliance so sad.
BEA's a good server, if slow, once you get around the absolutely awesomely bad management tools they tout as being so good. (Hint: they're not. If they work for you, great. We've found that we end up deploying the same applications multiple times, with restarts, in order to get the thing working correctly; this is with BEA support riding alongside to make sure we're not doing something stupid. We weren't.
WebSphere... IBM, IBM, IBM. The best compliment I've ever heard about Websphere was from a fan, a developer who loved it: "It's not that bad..." (Yes, it is. In IBM's sales meetings, they crow about how they helped design the entity aspects now-hopelessly-muddled EJB spec... and then later in the meetings they denounce using entity beans altogether because WAS can't give you any good performance with them. Plus, being tied to WSAD isn't my idea of a good time.)
JBoss is really pretty nice - it's built entirely around a component architecture, so you can swap out the Tomcat crap if you need to and replace it with something that actually works. (The default servlet container that comes with JBoss is Jetty, which you should replace with the current version of jetty if you use JBoss. The Jetty that ships with JBoss has a jasper error, jasper being a component from Tomcat.) The only issues I have with JBoss are related to its strengths: the component architecture means that each component chooses how it's administered, so you end up not only learning how to handle JBoss itself, but you have to learn how to configure Jetty, or this product, or THIS product, or THIS OTHER product... I prefer one ring to rule them all, etc.
As far as performance reviews, use google! :) I've done some informal performance reviews, and I've found the two best performers were Resin and Orion, with Resin being a few milliseconds behind Orion in terms of servlet and JSP performance.
Yes, I know it's free. Pay attention.
It does a relatively poor job of implementing the spec itself, and the spec is supposed to be its reason for being. It's gotten faster over time, which is nice, but it's still not very good at handling things. Tweaks abound, but running a custom version of a servlet container isn't likely to bring comfort to you... I hope.
I'd suggest spending some money on the container, myself; Jetty is okay, but I personally prefer Orion, which is fully J2EE, fast as all get out, and very, very easy to administer. Installation of an Orion instance takes three steps: unzip, copy tools.jar, java -jar orion.jar. Done. It's also free for development, so there's no per-seat license cost for you to use it to write code.
An aside: Oracle recently posted ECPerf numbers which were very good, and Oracle licensed the Orion codebase... and Orion costs thousands less. Since ECperf yields numbers based on dollars per transaction, you'd think Orion would kick butt on ECPerf.
I find Tomcat to be acceptable only for compliance testing, because so many people think it's the best that out there (because of the price point). I've spent a lot of time having to work around Tomcat; I'd hope you didn't feel like doing the same.
Come on, Katz, get a life - and psychiatric help, too, until you figure out "the Hellmouth" is a fiction created by morons who feel so sorry for themselves that they spend all their time either engaged in infantile escapism, or chirping about it, instead of living their lives.