can’t help but think that Sun continued to blow its
opportunities here, for years.
Usually I jump on the bash-java bandwagon. However, I think the author's wrong about this. Java is good in a team setting, and Java is the best choice for the enterprise.
I support a cross-platform, plugin-oriented Java application with a large install base and wouldn't want it written in anything else.
In C applications, it happens that applications will have segfaults, and threaded log less helpfully on the way down whereas in java there's a command that allows you to analyse threads of a running process. When there's a Java problem I have much better odds of getting my head around the source than I would for the sort of macro-affected C source that you'd need for an application run in this setting. If it were to run out of memory it would be clear about it. When you're stuck with libraries where the source and developers are long gone it's realistic to use a decompiler. With some preparation at dev time you can use the classpath and classloaders to hot-patch.
C is good for programmers, but not so good for the other technical workers. And I don't think C is as much of a big deal as it used to be due to the advances in scripting languages. I do a fair bit of programming oriented around unix system calls, all in python. Sometimes I find the documentation is better in C, and mock it up there, and then carry it back to python where I can do more with it. Also, if you're on Bigco's standard-issue Solaris host you're far more likely to find perl than a C compiler. Computers are faster than they used to be. Raw execution speed and memory footprint of a process (areas where C is stronger) are much less relevant to scale issues than they used to be.
Reply said:
The author is comparing Java to C#, not C.
Er - ah - so he did. Thanks for being polite about it.
If it matters, I happen to agree with you, as what you said holds true for Java-vs-C as well as for C#-vs-C.
For Java-vs-C#, I hold my ground :-)
I tend to hack up Perl-like tools in C# these days, using a small regexp-centric framework that also handles command line parsing. It's not much more code, and I feel better about it in my current community.
I support a cross-platform, plugin-oriented Java application with a large install base and wouldn't want it written in anything else.
In C applications, it happens that applications will have segfaults, and threaded log less helpfully on the way down whereas in java there's a command that allows you to analyse threads of a running process. When there's a Java problem I have much better odds of getting my head around the source than I would for the sort of macro-affected C source that you'd need for an application run in this setting. If it were to run out of memory it would be clear about it. When you're stuck with libraries where the source and developers are long gone it's realistic to use a decompiler. With some preparation at dev time you can use the classpath and classloaders to hot-patch.
C is good for programmers, but not so good for the other technical workers. And I don't think C is as much of a big deal as it used to be due to the advances in scripting languages. I do a fair bit of programming oriented around unix system calls, all in python. Sometimes I find the documentation is better in C, and mock it up there, and then carry it back to python where I can do more with it. Also, if you're on Bigco's standard-issue Solaris host you're far more likely to find perl than a C compiler. Computers are faster than they used to be. Raw execution speed and memory footprint of a process (areas where C is stronger) are much less relevant to scale issues than they used to be.
Reply said:
Er - ah - so he did. Thanks for being polite about it.