The Daily WTF: Curious Perversions in Information Technology

2009-05-13 Reply Admin

Dirk Diggler:
xtremezone:
A compiler will make better optimizations than 99% of us can. So a program written in C or C++ will probably be near equal to or probably even faster than the equivalent program written by the same programmers in assembly.
The 1% that can beat the compiler intersects nicely with the programmers than CAN program in assembly. The rest of us need to stick with higher level languages.

I'd rather write a simple nested loop to iterate a large 2d array and have the compiler section it up so I don't thrash L1 cache than worry about doing it myself, especially when I want it unrolled too.

2009-05-13 Reply Admin

xtremezone:
Franz Kafka:
If you can't outthink a marketer, then I'm very sorry.
My job isn't to make assumptions. Assumptions lead to mistakes. I'm also not interested in anything that needs to be falsely advertised.
Franz Kafka:
No, strings are not just arrays of chars, they are strings that happen to be stored as an array. Java Strings are an improvement over the mishmash of C++ string classes and I like them a lot better. If you don't like the slightly better abstraction, that's fine, but it isn't Java's problem.
Perhaps "array" is too low-level for you. Sequences of symbols is how Wikipedia chooses to define it.
http://en.wikipedia.org/wiki/String_(computer_science)

Franz Kafka:
public static final String CONSTANT="Some stuff"
Does that hold up for a method parameter?

Your job is to make judgements and analyze crap. The java 2 thing was confusing for exactly 5 seconds, and then it was ignored. If you can't deal with marketroid crap, why are you even here?

you're the one who claimed that strings were arrays of chars and then bitched about how java strings are immutable. mutable strings is largely regarded as a mistake, so you're in the minority on this one.

re: constants, yes, of course you can pass a constant string as a parameter. Why wouldn't that work?

xtremezone · 2009-05-13 Reply Admin

Franz Kafka:
Your job is to make judgements and analyze crap. The java 2 thing was confusing for exactly 5 seconds, and then it was ignored. If you can't deal with marketroid crap, why are you even here?

Please explain what being here has to do with "marketroid crap".

Franz Kafka:
...constants, yes, of course you can pass a constant string as a parameter. Why wouldn't that work?

You don't seem to comprehend const-correctness. I want to pass a normal (non-"constant") object into a method and have that method agree not to modify any part of it. In other words, the source data is not constant, but according to the method, its parameter is.

2009-05-13 Reply Admin

xtremezone:
Franz Kafka:
Your job is to make judgements and analyze crap. The java 2 thing was confusing for exactly 5 seconds, and then it was ignored. If you can't deal with marketroid crap, why are you even here?
Please explain what being here has to do with "marketroid crap".

Apparently, you aren't smarter than a marketroid. I'm sorry.

xtremezone:

Franz Kafka:
...constants, yes, of course you can pass a constant string as a parameter. Why wouldn't that work?
You don't seem to comprehend const-correctness. I want to pass a normal (non-"constant") object into a method and have that method agree not to modify any part of it. In other words, the source data is not constant, but according to the method, its parameter is.

You can't pass an object into a method in java period. A final const string is as close as you will get - at most the method can change the reference it's using. As many people have said, passing an immutable wrapped object ref will prevent the method from modifying the parm's members.

Now then, if you haven't done this in C++, you don't have const either - const is a suggestion, and can be cast away. Const, just like class visibility only works if the other programmers are acting in good faith.

Now then, you need to settle down and listen a little more if you want to get better at what you do.

BikeHelmet · 2009-05-13 Reply Admin

xtremezone:
A compiler will make better optimizations than 99% of us can. So a program written in C or C++ will probably be near equal to or probably even faster than the equivalent program written by the same programmers in assembly.

The same argument can be applied to Java and C++, unfortunately.

Ahh, the 99% statistic! Why not just say "most"? :P

xtremezone · 2009-05-13 Reply Admin

Franz Kafka:
Now then, if you haven't done this in C++, you don't have const either - const is a suggestion, and can be cast away. Const, just like class visibility only works if the other programmers are acting in good faith.

I'm well aware. It requires an explicit cast (which is simple to check for) and if it does cast to non-const then it isn't const-correct (i.e., it can be considered a bug).

2009-05-13 Reply Admin

Franz Kafka:
Do tell: how do Java constants differ from C# constants? Specifically, why is the Java constant 'fake'?

Because it doesn't use the const keyword. I'm just playing around, functionally they are the same.

2009-05-13 Reply Admin

someone:
perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant?? Forget const...

There is a million and one reasons NOT to use a preprocessor directives. This is common knowledge for C++ developers.

2009-05-13 Reply Admin

dkf:
BoomWav:
[C# is] also faster than java and is better supported.
Only on a single expensive platform with some distinct scaling issues. (To be frank, Mono doesn't count!) If you don't mind being non-portable and bound to the whole Windows platform for execution environments, C# isn't a bad choice. But that doesn't work for everything.

C# is not bound to any platform. You even mentioned Mono in your post (and uh, it does count).

Compiling C# produces IL code, not machine code. So theoretically it could be executed on any platform with a virtual machine capable of executing the IL.

2009-05-13 Reply Admin

far9999:
I don't think you are understanding the constant deal correctly. C++ has const correctness (http://en.wikipedia.org/wiki/Const_correctness) which both Java and C# are missing.
Basically in Java and C# there is no way to guarantee that a method you call doesn't mess with the internals of your object (unless your object is immutable). This is possible in C++.

For the last time, C++ DOES NOT HAVE CONST CORRECTNESS. Please don't ever code in C++ again, thanks. And yes, there are plenty of ways to guarantee this in C# (and Java too I'm assuming; I'm not a Java coder).

Jake Clarson · 2009-05-13 Reply Admin

Joshua:
My experiments show that in most cases, Java is between 1x and 3x slower in CPU time, but most things simply aren't CPU bound anymore.

Slower in CPU then what? When you say something like that you really should be more specific.

For pure 100% CPU bound number crunching algorithms, the performance of Java ranges from approximately 2x as fast to 3x times as slow when compared to C++. In a fair number of situations Java is nearly exactly as fast as C++, but C++ is more often 2x as fast then its 2x as slow. For some specific algorithms, C++ is 3x as fast.

It all depends on how well the actual run-time data can be used to optimize the algorithm. Java depends heavily on a very high-performance run-time optimizer, while C++ depends on a very high-performance static optimizer. Both have their virtues. As said, on some algorithms Java performs better, on some C++ performs better. Overall the two are nowadays at approximately the same level.

If you compare Java to PHP however, it becomes a completely different league. Algorithms implemented in Java can be a 100x(!) faster, in some occasions even almost up to 200x.

Still, as other posters have pointed out, a lot of business systems simply aren't about number crunching, but are a mix of CPU and IO, with IO typically being the more important aspect. That's precisely why a horribly slow language as PHP is still able to implement high performing web applications. Basically PHP simply isn't the one doing any heavy lifting. Typical PHP applications put request values in an SQL query, sent that to some DB and after a little while they'll iterate over the resultset to pump out some HTML.

xtremezone · 2009-05-13 Reply Admin

Zer0:
someone:
perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant?? Forget const...

There is a million and one reasons NOT to use a preprocessor directives. This is common knowledge for C++ developers.

On the contrary, there are many reasons TO use preprocessor directives. Achieving "constants", however, is not one of them.

Macros (i.e., via the #define directive) in particular are bad because they make the code obscure to the programmer and hide things that aren't obvious. However, there are still times where there is no other solution.

// Bad:
#define MY_CONSTANT 5

// Better:
const int MY_CONSTANT = 5;

The main reason macros are bad is because the C++ compiler doesn't even know about them (they are substituted before it sees the code) so it has no way to know where the actual offending code is. As a result, tracking down errors that are the result of macro substitution is painful and error prone: you can be looking at valid code, but part of that code might be substituted with text that makes it invalid.

xtremezone · 2009-05-13 Reply Admin

Zer0:
For the last time, C++ DOES NOT HAVE CONST CORRECTNESS.

Const-correctness is a best practice, not a language feature. It describes correct code in much the same way other logic errors do. Just because the language lets you do it doesn't mean it's correct.

Zer0:
And yes, there are plenty of ways to guarantee this in C# (and Java too I'm assuming; I'm not a Java coder).

I'd really appreciate it if you could show us a few of them.

2009-05-13 Reply Admin

xtremezone:
Zer0:
someone:
perhaps I miss the point, but if you define a constant in c++ (ie use #define) is it not constant?? Forget const...

There is a million and one reasons NOT to use a preprocessor directives. This is common knowledge for C++ developers.
On the contrary, there are many reasons TO use preprocessor directives. Achieving "constants", however, is not one of them.

Macros (i.e., via the #define directive) in particular are bad because they make the code obscure to the programmer and hide things that aren't obvious. However, there are still times where there is no other solution.
// Bad:
#define MY_CONSTANT 5

// Better:
const int MY_CONSTANT = 5;
The main reason macros are bad is because the C++ compiler doesn't even know about them (they are substituted before it sees the code) so it has no way to know where the actual offending code is. As a result, tracking down errors that are the result of macro substitution is painful and error prone: you can be looking at valid code, but part of that code might be substituted with text that makes it invalid.

You may think it's bad, but it's great for job security!

2009-05-13 Reply Admin

Zer0:
For the last time, C++ DOES NOT HAVE CONST CORRECTNESS. Please don't ever code in C++ again, thanks.

Oh come on, it does for all practical purposes. If you're going to const_cast the constness away (or declare all your class member variables 'mutable'), that's your own fault and nobody else's.

That said, these C++ vs Java debates are silly, and I think deep down in your hearts you ALL know this. Personally, my languages are C++, Python and Tcl. I've only had minimal exposure to Java and C#, but from all I've heard and read, in MOST cases there's not much to choose between these languages (C++, Java, C#), as far as performance is concerned. If you code your programs using efficient data structures / algorithms, either of those languages will more than cut the mustard. There may be some specialized cases where you may have to revert to C++ or even C (or ASM), but for the vast majority of applications this should be unnecessary. Oh, and I full believe that an interpreted language can do some things as fast or faster than C++, because sometimers the virtual machine will be able to make certain optimizations AT RUNTIME that can allow out it outpace functionally equivalent C++.

QUESTION: The one thing that kinda puts me off Java is the lack of RAII, which to me is one of the most essential tools a computer language can offer. In C++ this is easily doable by simply allocating RAII guard object on the stack. These objects will then perform cleanup when their destructor is run. Python offers RAII functionality via 'context managers'. In Incr Tcl, one can create 'local' objects, whose destructors is run as soon as the function they were created in is left. Last time I checked, Java didn't have anything like that, but then I haven't been doing any Java in ages. Does anybody know whether this has changed in the meantime?

2009-05-13 Reply Admin

Zer0:
dkf:
BoomWav:
[C# is] also faster than java and is better supported.
Only on a single expensive platform with some distinct scaling issues. (To be frank, Mono doesn't count!) If you don't mind being non-portable and bound to the whole Windows platform for execution environments, C# isn't a bad choice. But that doesn't work for everything.

C# is not bound to any platform. You even mentioned Mono in your post (and uh, it does count).

Compiling C# produces IL code, not machine code. So theoretically it could be executed on any platform with a virtual machine capable of executing the IL.

C# is not supported outside of the MS platform. Mono is always a rev back and needs to be validated separately, so no, it doesn't count. Let's not talk about theory when discussing operating code.

/hoping xtremezone goes away

2009-05-13 Reply Admin

Jay:
Anon:
Fedaykin:
What "special servers" and "special software" do you think is required to run Java?

Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

Well, last I checked C++ apps require that you have numerous libraries installed. A decent install program for a Java app will have to install the JVM, just like a decent install program for a C++ app will have to install a bunch of libraries. I don't see that as a truly qualitative difference.

Exactly. You still have to install the equivalent components.

xtremezone · 2009-05-13 Reply Admin

woah!:
Jay:
Anon:
Fedaykin:
What "special servers" and "special software" do you think is required to run Java?

Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

Well, last I checked C++ apps require that you have numerous libraries installed. A decent install program for a Java app will have to install the JVM, just like a decent install program for a C++ app will have to install a bunch of libraries. I don't see that as a truly qualitative difference.

Exactly. You still have to install the equivalent components.

A virtual machine is not equivalent to a dynamically linked library. At all. A class library or JAR is an approximate equivalent to a dynamically linked library. Java byte-code means nothing to the Windows or Linux kernels, nor the machine's processor, whereas the code in a dynamically linked library should.

In other words, with a native program (written in any language and compiled to a supported binary format) you need:

The program.
Probably, though not necessarily, dynamically linked libraries.

With Java:

The program.
Probably, though not necessarily, class libraries.
A (compatible) Java Virtual Machine.

Count the points. :P You might notice an extra requirement for Java. :P

The JVM is essentially an interpreter. To my knowledge, your Java program is always interpreted (probably JIT compiled) by it before being fed to the processor. It isn't essentially the same. It's completely different.

And there's nothing wrong with that. But it means that in practice, Java will probably never be faster than C++ in more than a few select areas, where run-time analysis reveals a few useful optimizations.

My processor time AND memory are important to me. I don't want to waste them on needless layering and lazy programmers. In practice, Java can be replaced with a high-level language (like D) that is designed to abstract all platform specifics so that code doesn't need to be ported and can easily be compiled natively for each platform.

With that, Java sounds obsolete.

** EDIT **

This reminds me of an interesting note... It sounds like a huge WTF that static properties are implemented at the JVM level, not the program level... :-X When is that useful (for non-"constants")?

2009-05-13 Reply Admin

After installing your toolchain

Check. Excelsior Jet installed.

Compile your Java program.

Check.

Statically link it with all required libraries.

Check.

then take the resulting executable to a freshly installed OS and try to run it.

Check.

There you fucking go. Try that with Java.

Check(mate).

STFU indeed.

xtremezone · 2009-05-13 Reply Admin

Jim S.:
After installing your toolchain
Check. Excelsior Jet installed.
Compile your Java program.
Check.
Statically link it with all required libraries.
Check.
then take the resulting executable to a freshly installed OS and try to run it.
Check.
There you fucking go. Try that with Java.
Check(mate).
STFU indeed.

Good to know. Does it actually improve performance as one would expect?

Java is technically a language and a platform, and you simply compiled the language to a native binary (which can be done with any language). That doesn't work with Java byte-code which was the point I was making (that is, you can't take Java byte-code to a fresh OS and run it without installing a JVM). Look at all of the Java applications used today. None of the popular ones are distributed as native binaries to my knowledge. They all require Java to be installed.

It's still not really the same thing. Java compiled to machine code would eliminate one of the problems I have with it.

Addendum (2009-05-13 22:00): <sigh/>

According to the Web site, applications still require about the same amount of RAM and disk space on end user machines as if used by Sun JRE...

2009-05-14 Reply Admin

snookerdoodle:
I once interviewed for a project that would use my experience in both C++ and Java: they wanted to convert a desktop client application from Java to C++ because the application had memory leaks and they heard you had more control over memory allocation in C++.
I called the headhunter as soon as I walked out and told him I didn't think I'd be a good fit there.

Was the client rep named "Dick" ?

2009-05-14 Reply Admin

Zer0:
For the last time, C++ DOES NOT HAVE CONST CORRECTNESS.

Yes it does. A program that casts away the const-ness of a const object is not a conforming C++ program.

Severity One · 2009-05-14 Reply Admin

xtremezone:
My processor time AND memory are important to me. I don't want to waste them on needless layering and lazy programmers. In practice, Java can be replaced with a high-level language (like D) that is designed to abstract all platform specifics so that code doesn't need to be ported and can easily be compiled natively for each platform.

Now I know you're trolling, but that doesn't give you a right to become downright offensive. So I'm a lazy programmer because I prefer not to waste time hunting obscure bugs that have to do with the fact that applications that do not run in a virtual machine have a tendency not to have all the bounds checking and security that a virtual machine offers?

Let me put it differently. When I started programming, which would have been in the early eighties, it wasn't just easy to completely hang/crash your computer whilst programming, it was in fact expected. You'd have to switch off your computer, switch it on again (which luckily took mere seconds) and reload your program from cassette tape.

Between then and now I've worked with Z80 assembler, 8088 assembler, 68000 assembler, several flavours of BASIC, (Turbo) Pascal, C on MS/DOS, C on the Amiga, C on Unix, C++ on Unix, Perl, Bourne Shell and a bunch of others that aren't worth mentioning. And Java, of course.

There's no way that I'll ever go back to an environment where I have to spend time on things that a computer could do for me, like all the things a JVM does for me. I've got better things to do.

And abstraction, yes, that's important too. Try writing an application on a Windows system that you test with a MySQL database, and then port it to Solaris with Oracle. If you're using something like Hibernate to abstract the database engine, you don't even need to change your SQL queries and recompile.

Your point keeps coming back that CPU time is more important than the time you spend developing. In other words, the computer is more expensive than you are. It's not something I would be particularly proud of, but then again I get paid rather well for programming in Java, so what do I know?

2009-05-14 Reply Admin

Joshua:
My experiments show that in most cases, Java is between 1x and 3x slower in CPU time, but most things simply aren't CPU bound anymore.

Proof please. Links to your papers detailing your method.

2009-05-14 Reply Admin

Mike:
TRWTF is disagreeing that Java is slow. SQL Developer, Zend Studio, and pretty much all other Java-based development tools I've used have been horridly slow in comparison to non-Java based equivalents.

Eclipse vs Visual Studio?

2009-05-14 Reply Admin

Ah, Eclipse, an awesome development environment.

Also, reposting FTW: - Went & looked up that java quake2 port previously mentioned, and interestingly it had benchmarks!

http://bytonic.de/html/benchmarks.html

Fullscreen (probably more reliant on CPU)

C - 315fps Java 1.5 - 250fps

xtremezone · 2009-05-14 Reply Admin

Severity One:
Now I know you're trolling, but that doesn't give you a right to become downright offensive. So I'm a lazy programmer because I prefer not to waste time hunting obscure bugs that have to do with the fact that applications that do not run in a virtual machine have a tendency not to have all the bounds checking and security that a virtual machine offers?
Let me put it differently. When I started programming, which would have been in the early eighties, it wasn't just easy to completely hang/crash your computer whilst programming, it was in fact expected. You'd have to switch off your computer, switch it on again (which luckily took mere seconds) and reload your program from cassette tape.

Between then and now I've worked with Z80 assembler, 8088 assembler, 68000 assembler, several flavours of BASIC, (Turbo) Pascal, C on MS/DOS, C on the Amiga, C on Unix, C++ on Unix, Perl, Bourne Shell and a bunch of others that aren't worth mentioning. And Java, of course.

There's no way that I'll ever go back to an environment where I have to spend time on things that a computer could do for me, like all the things a JVM does for me. I've got better things to do.

I prefer to know what I'm doing when I'm programming as opposed to just throwing code at a compiler/run-time until it works. However, it's completely possible to implement bounds-checked types in C++.

I don't find myself getting caught by those kinds of bugs very often. I find it's relatively easy to track them down. I'm sure you're aware that debuggers and stack traces exist for native programs...

As for security, I'm not sure if you mean system security or application security, but operating systems are fully capable of handling system security (i.e., what memory addresses and/or resources your program can access) and I don't really see a difference between application security in C++ and Java applications (with the possible exception of buffer overruns, etc., in poorly written native code).

Severity One:
And abstraction, yes, that's important too. Try writing an application on a Windows system that you test with a MySQL database, and then port it to Solaris with Oracle. If you're using something like Hibernate to abstract the database engine, you don't even need to change your SQL queries and recompile.

Absolutely. Abstraction is a good thing. There's nothing preventing abstraction from being written into C++ though. The reason C++'s standard library is so lacking is mostly because of its age. There are libraries and frameworks to fill in the gaps. Boost has a ton of functionality, though I'm not sure what exists for data layer abstraction.

Severity One:
Your point keeps coming back that CPU time is more important than the time you spend developing. In other words, the computer is more expensive than you are. It's not something I would be particularly proud of, but then again I get paid rather well for programming in Java, so what do I know?

No, the time I spend USING is more important than the time I spend developing and it's related to CPU time. I don't care if it takes me 6 months to develop an application if it does what I need efficiently for the next 3 years.

Time adds up quickly. I don't know about you, but if I could somehow count the time wasted on slow Java applications it would probably amount to a lot of wasted time.

And development time is directly affected by CPU time as well. You can only test an application's functionality as quickly as it can run. So if it takes more time to run then it will take you more time to test.

Maybe you need Java to hold your hand, but I don't. There is absolutely a time to use RAD tools and interpreted programs can be useful to get something simple done quickly, but personally for something that myself or others will be using a lot, I think it's worth the development time to build an efficient native program (even if you decide to prototype it in Java first).

2009-05-14 Reply Admin

My parents used to have problems with Excel, and were always asking me for help. I installed VisualStudio.NET and the full MSDN library onto their computer and told them to write their own spreadsheet application, and now they never ask me for help!

Jake Clarson · 2009-05-14 Reply Admin

antred:
QUESTION: The one thing that kinda puts me off Java is the lack of RAII, which to me is one of the most essential tools a computer language can offer. [...] Last time I checked, Java didn't have anything like that, but then I haven't been doing any Java in ages. Does anybody know whether this has changed in the meantime?

Well, it's STILL not in the current version of Java which at the time of writing this is Java 6 update 13. However, former Sun employee and designer of among others the collection framework in Java, Joshua Bloch, is currently making a strong argument to have this ability included in Java 7.

The original reason for leaving this very useful feature out might be exactly the same reason why enums and templates among others where left out: Java needed to remove a lot of 'redundant' and 'unnecessary' features to be able to position itself as the easy alternative to C++. Of course, beginners and people who program only occasionally for fun don't need RAII. Well, they basically would need it, but they will never understand that they'll need it. When Java took of as a development language for serious development, it became clear that leaving out all of this had been a mistake. Later versions of Java thus added enums, and something that captures one use case for which one typically uses templates in C++ (generics). Although Generics are but a shadow of C++'s templates, enums are actually better implemented in Java.

Currently try/finally is used in Java to make up for the missing RAII functionality. Hopefully Joshua's proposal will make it to Java 7. Java 7 is slated for a release in 2010, but release dates tend to slip by a year or so. This is one area where Java surely does better than C++, where release dates tend to slip by close to a decade. <ducks> :P

antred · 2009-05-14 Reply Admin

Jake Clarson:
Currently try/finally is used in Java to make up for the missing RAII functionality. Hopefully Joshua's proposal will make it to Java 7. Java 7 is slated for a release in 2010, but release dates tend to slip by a year or so. This is one area where Java surely does better than C++, where release dates tend to slip by close to a decade. <ducks> :P

Well, that's good to hear. I might get my feet wet with Java some more then. And you're right, the pace at which C++ evolves IS painfully slow. I mean I understand the need to carefully review all decisions lest they turn out to be a mistake later on, but gosh ... it's been 6 years since the last C++ revision and it'll probably be one more before C++0x arrives. And then it'll be a couple of years before compiler vendors implement all the new features? ... :-(

antred · 2009-05-14 Reply Admin

John Smallberries:
My parents used to have problems with Excel, and were always asking me for help. I installed VisualStudio.NET and the full MSDN library onto their computer and told them to write their own spreadsheet application, and now they never ask me for help!

LOL!! :D

2009-05-14 Reply Admin

Why?

Because of its lack of concurrent classes like ConcurrentHashMap, etc..?

Because of its lack of a TreeMap?

Or because of its failure to give you a reasonable way to handle timezones? (Don't say DateTimeOffset because it doesn't even have proper daylight savings handling)

Or maybe it is because of its VERY POORLY encapsulated database API? I mean.. I thought MS invented ODBC, they could at least have made a good copy of JDBC.

ASP.Net is awesome.. but .Net and C# are just Ok when compared to Java. In Java world the UI frameworks are mostly a mess (though Wicket and GWT are nice).

2009-05-14 Reply Admin

const_cast is used to interact with legacy interfaces. Any other use would be an abuse.

I'm not sure what you mean by you can't pass an object into a method. You can pass a reference to an object... I commonly refer to this as passing an object. Maybe that's wrong but that's what I say.

This whole comment flame war has mostly been C programmers who think they are C++ programmers vs Java and C# programmers who may or may not know what they are doing...

Severity One · 2009-05-15 Reply Admin

xtremezone:
I prefer to know what I'm doing when I'm programming as opposed to just throwing code at a compiler/run-time until it works. However, it's completely possible to implement bounds-checked types in C++.

At which point you lose quite a bit of your coveted performance.

I don't find myself getting caught by those kinds of bugs very often. I find it's relatively easy to track them down. I'm sure you're aware that debuggers and stack traces exist for native programs...

I rarely, if ever, have to use a debugger. For one thing, I use proper programming techniques, and second, Java helpfully points out where something went wrong, with stack traces and everything. Source code analysis with a tool like PMD helps as well to hunt down trivial bugs that the Java compiler (which catches a lot more bugs than a C compiler) doesn't catch. And then there are unit tests, which become easy with JUnit, etcetera.

As for security, I'm not sure if you mean system security or application security, but operating systems are fully capable of handling system security (i.e., what memory addresses and/or resources your program can access) and I don't really see a difference between application security in C++ and Java applications (with the possible exception of buffer overruns, etc., in poorly written native code).

I didn't mention security.

Absolutely. Abstraction is a good thing. There's nothing preventing abstraction from being written into C++ though. The reason C++'s standard library is so lacking is mostly because of its age. There are libraries and frameworks to fill in the gaps. Boost has a ton of functionality, though I'm not sure what exists for data layer abstraction.

There is simply nothing like it. You cannot take a C/C++ program from one architecture and take it to a different one without spending a lot of time. Heck, even if you try to compile something on Solaris that was written by someone who only knows Linux and GCC (instead of Sun's compiler) it's a nightmare. Perl has a quite reasonable database abstraction layer, and it's relatively easy to install a module, and I think PHP has one too, but both are a far cry from JDBC. But you don't even have that for C++, for the simple reason that outside the Windows platform, C++ is very much a niche product. C, no, but C++, yes.

No, the time I spend USING is more important than the time I spend developing and it's related to CPU time. I don't care if it takes me 6 months to develop an application if it does what I need efficiently for the next 3 years.

You obviously don't work in an environment where people actually have to deliver products and meet commercial deadlines... contrary to most of the readers of this site, I would imagine.

Time adds up quickly. I don't know about you, but if I could somehow count the time wasted on slow Java applications it would probably amount to a lot of wasted time.

Could you corroborate this claim perhaps? I work daily with Netbeans, developing Java applications, and they're not slow. I never spend more than a couple of seconds compiling, and it may take maybe - just maybe - a minute if I re-compile an application from the ground up. But that is only if I re-compile all the projects that are listed as dependencies, and all of their source code has to be compiled as well.

And development time is directly affected by CPU time as well. You can only test an application's functionality as quickly as it can run. So if it takes more time to run then it will take you more time to test.

You mean you don't use unit tests? I thought you said you knew what you were doing, and not throw code at a compiler until it works.

And again you come with this claim that Java is so slow, without ever trying to back it up with some evidence. What sort of applications do you write anyway? You haven't mentioned that, you've just been re-hashing the 'Java is slow' mantra.

Maybe you need Java to hold your hand, but I don't. There is absolutely a time to use RAD tools and interpreted programs can be useful to get something simple done quickly, but personally for something that myself or others will be using a lot, I think it's worth the development time to build an efficient native program (even if you decide to prototype it in Java first).

Again, what sort of program? Note that the code I write runs on back-end servers, deals with very large amounts of data, and is very much bound by the database engine (Oracle) that we use. As said, Java is fast enough, because we don't do simulating of aircraft or nuclear explosions.

But apparently you typically write programs where development time and deadlines are not an issue, but quick run times are? If you're working at a university, it could make sense, but please do enlighten us.

2009-05-15 Reply Admin

Java is indeed slow, as you can see for yourself by visiting any site with an embedded applet and watch Java painfully struggling to load, while the page displays a pathetic 'Applet loading' message.

2009-05-15 Reply Admin

why is the cpu execution still in focus when it comes to sw?

As many seem to say that it is maintainabillity that really makes sw usefull over time..then we could pay some performance pennalities in order to gain maintainabillity..one factor in this is portabillity.

we need to think in execution cykles of the sw not the cpu?

C++ and old hw thinking might screw up a lot. 1.cpu centrik seems really cilly as we have multiple cpu.. 2.OO thinking in the old code reuse way is cilly as reusabillity is really worthwhile first on high levels of abstraction.. Dicks argumentation that got him into trouble is that he did not understand what is the driving force behind his system. 1.adaptabillity to requirement changes is far more important than performance when in reasonable diffrencies. 2.integration that works is the responsibillity not of any older system but of the CIO. 3.If a faliure occurs and it is to be fixed and it is the interface techniqe between the applikations that causes the problem..only severe constraints should prevent you from updating the older app to a newer more effective interface.If it is not doable this should be a signal to rewrite in the other language. 4 cost of apps is not just the maintenance cost day by day.It can be total replacement cost if it is keept in to old environment.

2009-05-15 Reply Admin

Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.

2009-05-15 Reply Admin

John Dugeen:
Java is indeed slow, as you can see for yourself by visiting any site with an embedded applet and watch Java painfully struggling to load, while the page displays a pathetic 'Applet loading' message.

Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.

What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.

To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.

xtremezone · 2009-05-15 Reply Admin

Severity One:
xtremezone:
I prefer to know what I'm doing when I'm programming as opposed to just throwing code at a compiler/run-time until it works. However, it's completely possible to implement bounds-checked types in C++.
At which point you lose quite a bit of your coveted performance.

No more than Java. Matter of fact, probably a lot less than Java if you do it well.

Severity One:
I didn't mention security.

Yes, you did:

Severity One:
So I'm a lazy programmer because I prefer not to waste time hunting obscure bugs that have to do with the fact that applications that do not run in a virtual machine have a tendency not to have all the bounds checking and security that a virtual machine offers?

Severity One:
There is simply nothing like it. You cannot take a C/C++ program from one architecture and take it to a different one without spending a lot of time. Heck, even if you try to compile something on Solaris that was written by someone who only knows Linux and GCC (instead of Sun's compiler) it's a nightmare. Perl has a quite reasonable database abstraction layer, and it's relatively easy to install a module, and I think PHP has one too, but both are a far cry from JDBC. But you don't even have that for C++, for the simple reason that outside the Windows platform, C++ is very much a niche product. C, no, but C++, yes.

I've heard Java zealots claim that in practice Java often needs to be tailored to a specific machine too. Write once, run everywhere isn't quite so clear cut in practice.

You can, however, take C++ from one machine to another without much extra work if your team is aware of platform specifics and everybody writes platform independent code (and all libraries used are either platform independent or equivalent functionality is pulled from platform specific libraries for all supported platforms). It isn't like C++ needs to be completely rewritten in order to work on another machine. There's nothing platform specific about C++, the language. It's the compiler implementations and operating systems that bring the specifics. And that stuff can easily be wrapped up just like Java wraps it. Reusing stable and powerful platform independent frameworks can really save you a lot of work.

In practice it usually isn't as convenient as Java, sure, but then again the end result is hopefully software that greatly outperforms the equivalent Java software and is that much more user-friendly for it. I hate waiting for computers to do things and therefore expect applications to perform as quickly as possible. Especially applications that I use a lot. Perhaps the way we use computers differs.

Severity One:
You obviously don't work in an environment where people actually have to deliver products and meet commercial deadlines... contrary to most of the readers of this site, I would imagine.

The right tool for my jorb right now is ASP.NET. I never said to use C/C++ (or other native alternatives) for everything.

Severity One:
Could you corroborate this claim perhaps? I work daily with Netbeans, developing Java applications, and they're not slow. I never spend more than a couple of seconds compiling, and it may take maybe - just maybe - a minute if I re-compile an application from the ground up. But that is only if I re-compile all the projects that are listed as dependencies, and all of their source code has to be compiled as well.

I wonder what your machine specs are. I haven't used NetBeans in about a year or two, but when I used it it was nearly unusable on decent hardware (albeit, it ran MUCH better in Linux than Windows). I spent much of my Java classes in college wishing it had been written in a native language.

And actually, Visual Studio has become quite slow as well (at least, in my experience). I don't know if it was written in managed code or is just bloated, but I'd guess it's probably a little bit of both... :P

I find it refreshing to get home and develop in Vim. :D

Severity One:
You mean you don't use unit tests? I thought you said you knew what you were doing, and not throw code at a compiler until it works.

Sure I do. If the code runs slower than native code then it will be slower to test than the equivalent native code. It doesn't matter if it's a full scale application (which still needs to be tested regardless of unit tests) or a unit test.

Severity One:
And again you come with this claim that Java is so slow, without ever trying to back it up with some evidence. What sort of applications do you write anyway? You haven't mentioned that, you've just been re-hashing the 'Java is slow' mantra.

It's common knowledge that Java is slow. I don't need to prove it. Anybody that doesn't believe me can install it and find themselves a nice Java application to use. Obviously a zealot will deny this. And maybe the Java applications that you use aren't slow. I don't know. The ones I've used have been.

Slow is a relative term anyway. As somebody said earlier (maybe you, maybe not), on the backend you can throw hardware at it to make it perform adequately. Most users don't know what's happening in the backend and only experience the Java running on their own hardware. Even if the backend is fast because of lots of hardware, there are usually many many frontends that you don't have control over (and couldn't afford to anyway) that need to interface with the backend. If those are all written in Java, hardware might not be available to solve the problem.

By all means, if you can afford to make your Java applications perform well with hardware on the backend, go for Java. I don't care what you use on the backend as long as it performs well and works correctly. However, unless you're going to buy me an uber powerful gaming rig to use your frontend, write it in something less wasteful so it doesn't hog all my system's resources.

Severity One:
Again, what sort of program? Note that the code I write runs on back-end servers, deals with very large amounts of data, and is very much bound by the database engine (Oracle) that we use. As said, Java is fast enough, because we don't do simulating of aircraft or nuclear explosions.
But apparently you typically write programs where development time and deadlines are not an issue, but quick run times are? If you're working at a university, it could make sense, but please do enlighten us.

I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).

I never said to use C/C++/D/etc. for everything. However, there is absolutely a time to use it and IMHO the use for Java is a relatively small niche. Again, that's based on my personal experience running Java applications which obviously isn't like yours because you love it.

IMHO, the vague description the article gives doesn't give us enough information to make a technology decision. By the sound of it, the system will handle lots of data for an entire country and won't change much once written. To me, that sounds like a good candidate for native programs. I don't know that obviously. I know next to nothing about what this particular contracted company was being considered for. You don't know that Java was the right tool either though.

xtremezone · 2009-05-15 Reply Admin

Rob:
Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.

How well do you think your JVM will run without the operating system? Thought so.

Rob:
Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.
What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.

To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.

Perhaps they should write the JVM in Java... Oh wait...

2009-05-15 Reply Admin

xtremezone:
It's common knowledge that Java is slow. ...
I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).

It is also common knowledge that people who write in ASP.NET are talentless and brain-dead. They're all VB6 drag'n'drop muppetts who've retrained using a Learn * in 24 hours book. They didn't have the design talent to get a PHP job or the programming skill to get a job writing real applications in Java/C++/C/... They use Windows because they're soulless corporate micro-drones and aren't smart enough to use a real shell. They once tried to install Linux but were confused when they didn't have to click Start to Stop their PC.

It turns out that 'common knowledge' isn't that reliable since one, or more, of my previous statements may be untrue.

2009-05-15 Reply Admin

xtremezone:
Rob:
Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.
How well do you think your JVM will run without the operating system? Thought so.
Rob:
Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.
What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.

To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.
Perhaps they should write the JVM in Java... Oh wait...

Java requires AN operating system not A SPECIFIC operating system.
Point 1 isn't quite true since there are/were Java machines that had the JVM on bare metal - effectively it was the OS. This was an awful idea but, that aside, Java can run without an OS.
With each release of Java more and more of it is written in Java and it gets faster with each release. Make of that what you will.

2009-05-15 Reply Admin

At which point you lose quite a bit of your coveted performance.

Not enough to worry about.

I rarely, if ever, have to use a debugger. For one thing, I use proper programming techniques, and second, Java helpfully points out where something went wrong, with stack traces and everything. Source code analysis with a tool like PMD helps as well to hunt down trivial bugs that the Java compiler (which catches a lot more bugs than a C compiler) doesn't catch. And then there are unit tests, which become easy with JUnit, etcetera.

Just because you rarely use a debugger (surely if Java catches more syntactic errors, the majority of bugs will require a debugger, being logic errors) just suggests a different technique. I know C++ coders who rarely use one, but the VS2005 one is by and large fantastic. There's plenty of static analysis tools for C++, ever heard of Lint?

There is simply nothing like it. You cannot take a C/C++ program from one architecture and take it to a different one without spending a lot of time. Heck, even if you try to compile something on Solaris that was written by someone who only knows Linux and GCC (instead of Sun's compiler) it's a nightmare. Perl has a quite reasonable database abstraction layer, and it's relatively easy to install a module, and I think PHP has one too, but both are a far cry from JDBC. But you don't even have that for C++, for the simple reason that outside the Windows platform, C++ is very much a niche product. C, no, but C++, yes.

Don't be silly, you can, if you want, write portable C++ code. I've come across it on several occasions. The difference is that you can also use platform specific libraries to leverage (really hate that word) specific functionality. It's there if you want it, and most people use it, probably because the majority of software is Windows based. Java doesn't offer that. Portability is a noble cause, but different things for different purposes, and if you don't need it for your requirements, why limit yourself for it?

You obviously don't work in an environment where people actually have to deliver products and meet commercial deadlines... contrary to most of the readers of this site, I would imagine.

I do, but I also work in an environment where performance is absolutely critical (and fits neither of your scenarios). For quick things I'll use C#. It's quicker than Java because VS2005 has one of the best IDEs out there (although I did particularly like IDEA [possibly the only one that I think had any real chance of beating it] when I did Java, although ReSharper changes the playing field) and because the framework has a better selection of commonly used things for the things I need to do. The performance critical stuff is done using C++, memory management, stability and speed are absolutely critical (in terms of life/death), and Java really doesn't quite cut it, however much it's improved.

Could you corroborate this claim perhaps? I work daily with Netbeans, developing Java applications, and they're not slow. I never spend more than a couple of seconds compiling, and it may take maybe - just maybe - a minute if I re-compile an application from the ground up. But that is only if I re-compile all the projects that are listed as dependencies, and all of their source code has to be compiled as well.

What does compilation have to do with this? People are used to seeing slowish Java apps, I think some of that is perceived because Swing apps generally look dog. I really don't understand why you keep mixing dev/compile/run timings altogether. Different projects have different priorities, and if your company gets them consistently wrong then maybe you should leave (and yes, I've plenty of experience with rushed prototypes which are sold).

You mean you don't use unit tests? I thought you said you knew what you were doing, and not throw code at a compiler until it works. And again you come with this claim that Java is so slow, without ever trying to back it up with some evidence. What sort of applications do you write anyway? You haven't mentioned that, you've just been re-hashing the 'Java is slow' mantra.

It IS slower than C++ on most operations. Evidence has been posted previously, and I'll quite happily collab to optimise some tests. The thing is, while it may be relatively negligible on some JVMs, the Sun JVM is woefully slow compared to other ones and that's what most people's experience of Java is, so yes, I think it's perfectly fair to call it slow.

Again, what sort of program? Note that the code I write runs on back-end servers, deals with very large amounts of data, and is very much bound by the database engine (Oracle) that we use. As said, Java is fast enough, because we don't do simulating of aircraft or nuclear explosions.
But apparently you typically write programs where development time and deadlines are not an issue, but quick run times are? If you're working at a university, it could make sense, but please do enlighten us.

Good for you. The thing is, his argument is completely irrelevant, and you claiming that Java is better because of dev-time is irrelevant as well. At the end of the day it's not how fast the language is but, as you rightly say, if it is "fast enough". For exactly the same that random optimising is stupid, complaining about language speeds when it's negligible is pointless unless you need that extra speed. If you have a company full of C++ devs who are shit hot you'll probably get better, more maintainable code than a mediocre Java coder. On the other hand if you have one stupid developer, he's less likely to do harm in your Java app. I'm trying to say it's all relative. There's a lot of stupid criticism of both languages but they both have very important usages, and if it fits your company and your requirements then there's no real reason to change it.

2009-05-15 Reply Admin

Rob:
Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.

This is bollocks. What are you actually talking about. Idiot.

Rob:
1. Java requires AN operating system not A SPECIFIC operating system.

Cool, same with C++ then.

Rob:
2. Point 1 isn't quite true since there are/were Java machines that had the JVM on bare metal - effectively it was the OS. This was an awful idea but, that aside, Java can run without an OS.

Yay, go Java! Why was it an awful idea? Try and explain it without making Java sound crap. Go on.

Rob:
3. With each release of Java more and more of it is written in Java and it gets faster with each release. Make of that what you will.

Well how about this, it gets faster because it doesn't have to constantly swap in and out of the JVM to run code. Logically the more Java code it runs the faster it'll get because it has to do less interfacing with a different language. Also, it'd be a kind of shit release if it didn't get faster wouldn't it.

Rob:
Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.
What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.

To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.

What is actually wrong with you? If there wasn't a JVM to start up wouldn't it be a lot faster?

Why would anyone be stupid enough to try writing an applet in C++? It's like telling you to write a DirectX game in Java. Fucking dense.

So is the JVM fast or slow? Maybe if they weren't writing buggy C++ they wouldn't have to get round it.

xtremezone · 2009-05-15 Reply Admin

Rob:
xtremezone:
It's common knowledge that Java is slow. ...
I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).

It is also common knowledge that people who write in ASP.NET are talentless and brain-dead. They're all VB6 drag'n'drop muppetts who've retrained using a Learn * in 24 hours book. They didn't have the design talent to get a PHP job or the programming skill to get a job writing real applications in Java/C++/C/... They use Windows because they're soulless corporate micro-drones and aren't smart enough to use a real shell. They once tried to install Linux but were confused when they didn't have to click Start to Stop their PC.

It turns out that 'common knowledge' isn't that reliable since one, or more, of my previous statements may be untrue.

As a matter of fact, I'm an avid Linux user, hate Visual Basic, and hate Windows.

2009-05-15 Reply Admin

Shakje:
Rob:
Attempting to claim that Java has more installation dependencies than C++ is nonsense of the worst kind. C++ requires the biggest library of them all THE WHOLE OPERATING SYSTEM. It requires special servers - whatever it was compiled against.

This is bollocks. What are you actually talking about. Idiot.

And here we have it. Someone points out that you're a moron, but does you the service of not using the word moron and... you're off with your insults. Well, I shall hold back no more. You, sir, are a moron of the worst kind. I will answer the rest of your points below, but please note, this is purely for the interest of others. You are far too stupid to understand the reasoned discourse that has been occurring here.

Shakje:

Rob:
1. Java requires AN operating system not A SPECIFIC operating system.

Cool, same with C++ then.

So your point is that I can compile a C++ application on Linux, test it send it to my tester friend who uses windows and after he signs it off, deploy it on Solaris? No, I didn't think so. It turns out that cross-platorm applications and potentially cross-platform source code aren't the same thing.

Shakje:

Rob:
2. Point 1 isn't quite true since there are/were Java machines that had the JVM on bare metal - effectively it was the OS. This was an awful idea but, that aside, Java can run without an OS.

Yay, go Java! Why was it an awful idea? Try and explain it without making Java sound crap. Go on.

Why would I want to do that? I'm being honest, not a trolling moron. At the time, the JVM in use didn't provide support for real-time or near real-time garbage collection algorithms which introduced more uncertainty in some operations than was appropriate - reading system-time for example.

Shakje:
Rob:
3. With each release of Java more and more of it is written in Java and it gets faster with each release. Make of that what you will.

Well how about this, it gets faster because it doesn't have to constantly swap in and out of the JVM to run code. Logically the more Java code it runs the faster it'll get because it has to do less interfacing with a different language. Also, it'd be a kind of shit release if it didn't get faster wouldn't it.

What swapping in and out of the JVM are you talking about you buffoon (I thought I'd throw in a little of your own language there). If you had even a vague clue what the words coming from your pea-sized brain meant you'd be twice the man you are just now (hey, I can see why you like this, you shiftless fool). Everything is inside the JVM, there is nothing else.

Why would a new release be shit if it didn't get faster? That, like you, makes no sense.

Shakje:

Rob:
Actually, that's the JVM that's starting up which is written in C++ so ... sorry, own-goal there I think. After the start-up time it is very fast.
What sort of solutions do you have for writing applets in C++? Oh, that's right .. none .. can't be done .. you'd wait forever which is veeery slow indeed.

To counter my own point. Install the latest version of Java and you'll find that the applets pop open very quickly. They managed to work round the buggy C++ .. eventually.

What is actually wrong with you? If there wasn't a JVM to start up wouldn't it be a lot faster?

Why would anyone be stupid enough to try writing an applet in C++? It's like telling you to write a DirectX game in Java. Fucking dense.

So is the JVM fast or slow? Maybe if they weren't writing buggy C++ they wouldn't have to get round it.

If there wasn't a JVM wouldn't it be faster? Err, no. That doesn't make any sense, you demented swine. Flash applets don't have a JVM - it is also written in C++ - and it is slower at computation than a Java applet at run-time.

Why would it be stupid to write an applet in C++? Ohh, hold on. I see, you don't understand the words you're using. It turns out that you think the word applet means only a Java applet. Sorry, thank-you for playing on this weeks episode of "Let's see what the moron does with a keyboard".

In some future version of Silverlight you might actually be able to write applets in managed C++.

Shakje:
So is the JVM fast or slow? Maybe if they weren't writing buggy C++ they wouldn't have to get round it.

This is the core of your problem. Fast and slow are meaningless terms in this context (you worthless sack of excrement). As far as VMs go, the JVM is amongst the fastest. Is it fast enough for any particular application? That depends on the application and the hardware? Same with C++, C and ASM.

There is no right or wrong answer. If the application is performance sensitive, is the application suitable for parallelisation, then the JVM might be good. Is the application one where memory can be allocated and de-allocated deterministically, then C++ might be good. Does the application involved only the manipulation of very primitive types with simple algorithms, then C might be best. Is it single threaded and every instruction is vital, then ASM might be best.

Oh, and you're a fool (hadn't pointed out the obvious for a while)

2009-05-15 Reply Admin

xtremezone:
Rob:
xtremezone:
It's common knowledge that Java is slow. ...
I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).

It is also common knowledge that people who write in ASP.NET are talentless and brain-dead. They're all VB6 drag'n'drop muppetts who've retrained using a Learn * in 24 hours book. They didn't have the design talent to get a PHP job or the programming skill to get a job writing real applications in Java/C++/C/... They use Windows because they're soulless corporate micro-drones and aren't smart enough to use a real shell. They once tried to install Linux but were confused when they didn't have to click Start to Stop their PC.

It turns out that 'common knowledge' isn't that reliable since one, or more, of my previous statements may be untrue.
As a matter of fact, I'm an avid Linux user, hate Visual Basic, and hate Windows.

But all the rest is true? Who'd have thought it, I thought I was just making a rhetorical point. My point stands, your protestations of loathing for the technologies you spend your life working in, notwithstanding. The two points of contention about common knowledge are that it is neither common, nor actually knowledge. If it was knowledge it would be built on a demonstrable foundation, which you obviously lack.

PS If you really hated the technologies you use, you'd get a better job, if you could.

xtremezone · 2009-05-15 Reply Admin

Rob:
So your point is that I can compile a C++ application on Linux, test it send it to my tester friend who uses windows and after he signs it off, deploy it on Solaris? No, I didn't think so. It turns out that cross-platorm applications and potentially cross-platform source code aren't the same thing.

Java proponents have told me that in their experience, Java can behave differently on different platforms. So you still need to test it on each intended platform to be sure. The only real difference is what is cross platform: the code or the build. Sure, with Java you can theoretically build one and move it around between platforms (usually without problems, I'm sure), but building on a given platform isn't a very challenging thing. Cross compilers can make it even easier. And then the program will probably perform better than the Java equivalent would for the lifetime of that build. I can understand why some people wouldn't like that model, but personally I do.

Rob:
If there wasn't a JVM wouldn't it be faster? Err, no. That doesn't make any sense, you demented swine. Flash applets don't have a JVM - it is also written in C++ - and it is slower at computation than a Java applet at run-time.

AFAIK, Flash has an interpreter the same as the JVM interprets (albeit, these days probably JIT compiles) Java byte-code. The Flash "player" is probably written in C or C++ (I don't know), but the actual implementation of Flash "programs" (I wouldn't call it a program, but you know what I mean) is done with ActionScript, which is basically ECMAScript/JavaScript.

2009-05-15 Reply Admin

xtremezone:
and in my experience it always performs poorly (nearly every Java app I've used has been near unusable

This is not an issue with Java, it's an issue with the programmers who can't write a stable application. I could write a crap application in C++ that crashes all the time, but that doesn't mean that C++ performs poorly.

2009-05-15 Reply Admin

xtremezone:
Rob:
So your point is that I can compile a C++ application on Linux, test it send it to my tester friend who uses windows and after he signs it off, deploy it on Solaris? No, I didn't think so. It turns out that cross-platorm applications and potentially cross-platform source code aren't the same thing.
Java proponents have told me that in their experience, Java can behave differently on different platforms. So you still need to test it on each intended platform to be sure. The only real difference is what is cross platform: the code or the build. Sure, with Java you can theoretically build one and move it around between platforms (usually without problems, I'm sure), but building on a given platform isn't a very challenging thing. Cross compilers can make it even easier. And then the program will probably perform better than the Java equivalent would for the lifetime of that build. I can understand why some people wouldn't like that model, but personally I do.
Rob:
If there wasn't a JVM wouldn't it be faster? Err, no. That doesn't make any sense, you demented swine. Flash applets don't have a JVM - it is also written in C++ - and it is slower at computation than a Java applet at run-time.
AFAIK, Flash has an interpreter the same as the JVM interprets (albeit, these days probably JIT compiles) Java byte-code. The Flash "player" is probably written in C or C++ (I don't know), but the actual implementation of Flash "programs" (I wouldn't call it a program, but you know what I mean) is done with ActionScript, which is basically ECMAScript/JavaScript.

I've been building and deploying Java applications for over ten years, building and deploying across Windows, Linux and Solaris. I've never had any problems other than people hard-coding paths with backslashes that work on windows but not *nix. So, yeah, nothing's perfect. But I've never seen any other deviations.

Java isn't interpreted. There is no interpreter. Java is compiled to bytecode and then compiled to machine code dynamically by the JIT part of the VM. So it gets compiled twice.

Interestingly this second part can often produce faster code than an un-tuned C++ compiler because it can make use of processor specific extensions that you couldn't , or didn't, take advantage of when performing a generic "work on as many boxes as possible" build with C++. You certainly could use the same, or similar, optimisations in many cases but not all. The JVM can optimise based on run-time behaviour that a static compiler could never see. So for instance if a loop is called with a counter that is 2 most of the time, then the HotSpot compiler can unroll that loop at run-time for increased performance.

I'm not saying that Java is faster than C++ in general, but in some cases it is. There are now a very large number of potential deployment configurations, if you're only compiling for a single known platform you can get the best performance out of ASM, C, C++ and Java in ( probably ) that order. If you don't know the exact deployment platform hardware configuration then the runtime performance is not as clear. If you're creating general purpose apps, the number of potential deployment platforms is too large to create hardware optimised versions.

Interestingly the .NET model where an assembly is put through an optimising compile stage at deploy time seems like a really good middle ground.

Java is Slow!

Leave a comment on “Java is Slow!”