Anaphase

[Grundoko]

I'd much rather see it put to making Android apps, as Android is Linux based, and I hate Apple's products, mainly because of how closed they are.
Too bad Android apps use Java, and not C++

[The 11th plague of Egypt]

People relax and let him work. We don't want all this excitement to stress his life.

Good luck with the release. I'll wait.

[Grundoko]

Meh, this is the internet. We can worry about his life as little as needed.
Josh, finish Enigma R4. Sleep is not a priority >: (

But seriously, take your time, we can wait.

[luiscubal]

- Better working environments: OO programming and lack of preprocessor makes writing IDEs far easier, and autocompletion is more relevant.

I don't understand how this is a conceivable argument at all.  Object-Oriented programming is, well, in some cases, good, but in other cases, like Java, really bad.  Instantiating classes and creating classes uses memory, which is... well, extremely inefficient at best.  And don't give me any optimization crap, because I know that Java does none of that.  IDEs are language-independent.

No, they are not. IDEs are VERY language dependent.
In C, for instance, you had no namespaces, so all functions were in the global scope. Therefore, pressing Ctrl+Space would put lots of useless junk, and some times omit the things that matter.
In C++, namespaces and classes made this *a bit* better, but it's still essentially the same crap. C++'s #includes are less IDE-friendly than Java's imports.

- Consistent APIs. In C you have no core library. You have a "standard" library which isn't exactly implemented the same way by everyone and then you need third-party libraries for anything that matters. Sometimes I'm frustrated by lack of library functionality in Java and C#, but this is nowhere as bad as C(++)'s problem.

The point of C++ is that there is no API.  You get to do whatever that you want.  If you want a standard API, you can make one, and tell everyone to use that.  That's essentially what Java and C# are, however, it forces you to use that API.

At least the API is *consistent*. You rarely need just a single API. And, when you do need two C++ APIs to interop, you've got trouble, because they just don't. No matter what you say, you always need an API unless you're writing a kernel. So C is very good for kernels, but usually sucks for everything else. Everything uses java.lang.String, and java.util.List. Of course, C++ has the C interop thing, so it has an unfair disadvantage due to C strings and arrays(which are computer-friendly but definitively not programmer-friendly).

- Garbage collection. C's static allocation is good when it works, but it's not always enough so you have to use malloc/free eventually, which are pain to handle. C++ added lots of features that make pointers easier to handle, such as T& pointers, but the problems remain. In Java and C#, it *just* works. No memory leaks. C++ wasn't designed for garbage collection, so C++ GCs are always ugly, imperfect and/or inefficient.

See the above.  You can't use the argument that "when things are made in Java, they just 'happen' to be better."

I can't? Since when? Oh, and "see the above", you can't use any argument that disagrees with me. Why, you may ask? Oh, for no particular reason, but since you can dismiss arguments by just pretending they don't exist I figured I could do the same.

- It just works. No segfaults. In C, you have weird errors. You have to compile again in debug mode, try to reproduce the error and use gdb to have some chance of finding the problem. In Java and C#, you get an exception, which points you to exact file, class, function and line where the error is. When it crashes without warning it is typically because of C parts(JNI/JNA).

See above.  Additionally, debuggers use loads of space, and slow-down the program.  If you want a debugger, make one.  It should not be required.

If your program leaks memory everywhere and crashes in unclear and strange ways even after hours of testing and debugging, you're doing it wrong. Slow is better than unstable. Using so little memory is irrelevant when you can't work for two days without running into a non-trivial memory leak.

- Good enough runtime speed. Aside from some GUI slowness which is a library rather than a language problem, Java and C# are fast enough for most purposes. In many cases, they can match C's speed thanks to Just-In-Time compilation(Java and C# are typically *NOT* interpreted languages)

You can't just say that "it's good enough, so, on a good computer, you won't notice the difference."  I've always seen a significant gap in speed between Java and C/C++.

I can quote sources: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html Can you?
In the above benchmarks, you can see Java can be either faster or slower than C, depending on the cases(depending on problem and compiler/optimization mode). Once again, it's important to remember that Java IS compiled. Its compilation might actually be better than C's.
If you read the whole article, it actually has some reasons about why Java should be faster than C.
Garbage collection may actually be faster than malloc/free for reasons related to the computer's cache.

- Compilation of "real projects" takes some minutes, as opposed to several hours in C++.

It's always been the same to me.  Even on older computers.

I've let my computer alone compiling some projects from source(because some people thought open-source didn't need binaries, only source code). In a dual core(with both cores being used), it would still take hours.
Java projects are way faster to compile. This is more noticeable in big projects, but even on small ones I'm starting to notice this.
See: http://stackoverflow.com/questions/318398/why-does-c-compilation-take-so-long
I think I might be seeing terrible compilation times in my small personal C++ projects because I aggressively use templates, but I did see this problem in big C-only projects, so it can't just be my code.

- Great languages, although C# is technically superior to Java, both are much less frustrating than C++. In Java, I can just write xyz.replaceAll("\n", "\n\t"). The equivalent is much more painful in C, and better but still annoying in C++. Not to mention that regular expressions are available if you need them, without needing to go fetch some weird libraries and check if they work on your compiler.

"I just like Java better."
[/quote]
I mentioned enough cases of why my "liking Java" is justified.

I've seen lots of contradictory benchmarks, but here is the essential parts:
 - Java/C# are not too slow compared to C.
 - Java/C# have consistent APIs. C++ "has no API"(your words).
 - Java/C# are FAR FAR FAR faster than C++ when it comes to *compilation* time.
 - Garbage collection is not a handicap.
 - Java/C# are nice to code in. C is masochism.
 - C may be nice when it works, but it hardly does and it is awful when it doesn't. Java/C# are just as nice when they work, but greatly attempt to prevent things from not working(memory leaks, segfaults, etc.)

And a new argument: Java/C# are safer than C. Running C is a security risk. Buffer overflows security vulnerabilities, for instance, are VERY rare in Java, while very common in C.

You seem to say that C is "better than Java", but it's not the case.
Java and C#'s are easy to use, fast enough and safer than C. When those things matter, C always loses.
C only seems to win in some particular speed benchmarks(and not all!), really low-level tasks(such as kernels and drivers, which are also possible in C#/Java, by the way, even if rare) and supporting legacy code(huge code bases such as Mozilla, which would be perfectly fine if started in Java/C# from the ground up).
So don't ever say C is always better again. When you have a problem, look at the problem and only then decide the language.

[Game_boy]

@luiscubal

Why, then, does no one use Java or .NET for desktop programs? It may be prevalent in enterprise, but I have exactly zero programs on my computer that use Java/C#, (open or proprietary, Linux or Windows). Why aren't developers starting new projects in Java, if it is suitable for some things?

I also see very few Java applets on the web, except for ancient educational pages.

[luiscubal]

FlashDevelop and Paint.NET use C#, for instance, and Eclipse, NetBeans and LGM use Java. FlashDevelop may not be important for non-flash app devs, but Paint.NET is among the best image editors I've ever seen(its Linux port - Pinta - is heading the right way too). Eclipse is one of the most widely use IDEs ever.

On Linux, besides Pinta, Tomboy and F-Spot are written in .NET.

If you're planning to use ENIGMA, you'll pretty soon going to use LGM too, which means, you'll have a Java application installed.

On to the real explanation: Java is being defeated by .NET. .NET, however, hasn't caught up in Linux/Mac yet, primarly because Microsoft patent fears have only recently stopped, and not for all APIs(WPF is still under FUD, for example), so Mono is still kind of feared.
Also, old legacy applications are not rewritten every day, so those big legacy projects(Firefox, WebKit, GNOME, KDE, etc.) are stuck in legacy languages.
GNOME, however, recognizes the need for more productivity, so they have the Vala language. The fact that a primarly C environment feels the need to clone the Java/.NET environment in a C-compatible way proves the fact that these higher-level languages do matter.

As for the Applets, have you seen modern Flash? ActionScript code looks a LOT like Java.
You may say Flash is being replaced by HTML5, but last time I checked, HTML, SVG, CSS and JavaScript are definitively not C. Will you say nobody uses those?

[RetroX]

@MrJackSparrow: The iPod/iPhone is literally running the full version of OS X.  The entire operating system is on there.

No, they are not. IDEs are VERY language dependent.
In C, for instance, you had no namespaces, so all functions were in the global scope. Therefore, pressing Ctrl+Space would put lots of useless junk, and some times omit the things that matter.
In C++, namespaces and classes made this *a bit* better, but it's still essentially the same crap. C++'s #includes are less IDE-friendly than Java's imports.

I still have no clue what the hell that you're talking about.  Saying that "java forces you to sort everything" is really stupid.  It does not matter what language that you use.  You can code in C++ like you code in Java; I don't care.  It'll be a lot more efficient, and will solve your "sorting" issue.  Just change a few key words and then "WOW, IT WORKS."  But really, I don't see why you'd want to do that in Java.  Sacrificing speed for sorting the code is not acceptable, or at least, in my opinion.

At least the API is *consistent*. You rarely need just a single API. And, when you do need two C++ APIs to interop, you've got trouble, because they just don't. No matter what you say, you always need an API unless you're writing a kernel. So C is very good for kernels, but usually sucks for everything else. Everything uses java.lang.String, and java.util.List. Of course, C++ has the C interop thing, so it has an unfair disadvantage due to C strings and arrays(which are computer-friendly but definitively not programmer-friendly).

Stop using these areguments.  You can't say that "Java just happens to be consistent because it's there."  There are loads of programs with standard APIs.  GTK, Qt, and wxwidgets are in that category.  So are WinAPI and XLib.

I can't? Since when? Oh, and "see the above", you can't use any argument that disagrees with me. Why, you may ask? Oh, for no particular reason, but since you can dismiss arguments by just pretending they don't exist I figured I could do the same.

...you're just trying to prove your point with nothing.  Please give me a legit argument, and I'll gladly listen to you.  I mean it, too; I'd like to know why you like Java and C# so much.

If your program leaks memory everywhere and crashes in unclear and strange ways even after hours of testing and debugging, you're doing it wrong. Slow is better than unstable. Using so little memory is irrelevant when you can't work for two days without running into a non-trivial memory leak.

No, it's not.  There are plenty of debuggers that can be used, and besides, if you do have a memory leak and can't find-out where it could have been, you need to learn how to code correctly.  Memory leaks don't "just happen."

I can quote sources: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html Can you?
In the above benchmarks, you can see Java can be either faster or slower than C, depending on the cases(depending on problem and compiler/optimization mode). Once again, it's important to remember that Java IS compiled. Its compilation might actually be better than C's.
If you read the whole article, it actually has some reasons about why Java should be faster than C.
Garbage collection may actually be faster than malloc/free for reasons related to the computer's cache.

C: 1.1
Java: 9.0

Yes, the third one is faster.  Big whoop.  I doubt that they were using the same codes for both; they probably just had written it better in Java than in C.  And in the case that you didn't know, Java is written in C.

I've let my computer alone compiling some projects from source(because some people thought open-source didn't need binaries, only source code). In a dual core(with both cores being used), it would still take hours.
Java projects are way faster to compile. This is more noticeable in big projects, but even on small ones I'm starting to notice this.
See: http://stackoverflow.com/questions/318398/why-does-c-compilation-take-so-long
I think I might be seeing terrible compilation times in my small personal C++ projects because I aggressively use templates, but I did see this problem in big C-only projects, so it can't just be my code.

C compiles slower when people compile the entire thing at once, whereas most of Java's utilities are pre-compiled classes.  That's why you have libraries and object files that you compile for the stuff that is already done.  It's not like you need an entirely different mentality to compile in a different language.

I've seen lots of contradictory benchmarks, but here is the essential parts:
 - Java/C# are not too slow compared to C.
 - Java/C# have consistent APIs. C++ "has no API"(your words).
 - Java/C# are FAR FAR FAR faster than C++ when it comes to *compilation* time.
 - Garbage collection is not a handicap.
 - Java/C# are nice to code in. C is masochism.
 - C may be nice when it works, but it hardly does and it is awful when it doesn't. Java/C# are just as nice when they work, but greatly attempt to prevent things from not working(memory leaks, segfaults, etc.)

Please give me several reliable sources that aren't your opinion and/or something that I can actually try-out, or stop arguing.

And a new argument: Java/C# are safer than C. Running C is a security risk. Buffer overflows security vulnerabilities, for instance, are VERY rare in Java, while very common in C.

[citation needed]

You seem to say that C is "better than Java", but it's not the case.
Java and C#'s are easy to use, fast enough and safer than C. When those things matter, C always loses.
C only seems to win in some particular speed benchmarks(and not all!), really low-level tasks(such as kernels and drivers, which are also possible in C#/Java, by the way, even if rare) and supporting legacy code(huge code bases such as Mozilla, which would be perfectly fine if started in Java/C# from the ground up).
So don't ever say C is always better again. When you have a problem, look at the problem and only then decide the language.

More opinion.  Big whoop.  Please learn how to support an argument.

I mentioned enough cases of why my "liking Java" is justified.

No, you haven't.  If you'd like to PM me or message me on MSN (however, not this week; I have relatives that are coming over later today), then feel free.  But I'm not clogging-up this topic any more.

Besides, Pinta, Tomboy and F-Spot aren't very good, nor are they fast.

You can't argue that Java/C# are faster than C/C++.  For starters, they are both written in C, so, no matter what, the lower-level language will be better.  Secondly, while they are both compiled, they require a separate runtime that's running to run the compiled code.  It can be argued that the speed isn't enough to worry about, but not that it's not there.

[freezway]

  (also josh: do NOT rewrite everything at this point!)

[Josh @ Dreamland]

Thanks for understanding, guys. Does mean a lot.
freezway: I promise.

[score_under]

- Java/C# are nice to code in. C is masochism.
 - C may be nice when it works, but it hardly does and it is awful when it doesn't. Java/C# are just as nice when they work, but greatly attempt to prevent things from not working(memory leaks, segfaults, etc.)

Actually, I quite like the ability to access a function without goin' all "namespace.class.pointer.otherobject.function()", and instead just using "function(pointer[2])".
Lack of OOP is just personal preference, though.

And "C may be nice when it works, but it hardly does and it is awful when it doesn't"... C has always worked for me, and if you can't get it to work then you don't know the language. Really, you shouldn't code in languages you don't actually know. [Also, ever heard of __try{}/__catch(){}? Works in C++, and can be implemented through function calls in C. Catches errors, you can deal with them however you want.]

[Game_boy]

@luis

I wasn't bashing Java. I really was asking why it wasn't more widely used.

And, yes, LGM will be the first Java app I use regularly.

[IsmAvatar]

There are loads of programs with standard APIs.  ...[like] XLib.

Excuse me, I just threw up a little in my mouth.

Source:
I wrote the xlib UI for enigma.

[RetroX]

There are loads of programs with standard APIs.  ...[like] XLib.

Excuse me, I just threw up a little in my mouth.

Source:
I wrote the xlib UI for enigma.

It's still a standard API.

[IsmAvatar]

Sadly.

[Rusky]

IDEs are language dependent. Syntax highlighting and intellisense require language-specific behavior. The main difference here, however, is #include vs import/using. #include is part of the preprocessor and can thus be abused. Header files require extra maintenance and that public APIs be parsed at least twice- once in the header and once at the definition. Java and C#'s way is much better- it's faster in compilation and development time, because it's not redundant and gets the information it needs directly from its source. However, this is completely independent of the rest of the language. Java/C# could easily have been implemented with #include, and C/++ could easily be implemented with import.

Java and C# have standard APIs. All the different parts interoperate pretty much perfectly. C/++ has several commonly used APIs, yes, but they're not standardized as part of the language and they aren't designed to cooperate. Java and C# implement this by including the enormous standard library in a runtime that must be downloaded separately, C/++ has no standard so the APIs all have their own runtime libraries or are included in each and every program that uses them. The idea with .NET is to become like WinAPI, part of the OS. We're still in a transition phase, so it's slightly painful, but it allows programs to be much smaller while still accessing large support libraries. Both approaches have advantages and drawbacks, so it really depends on your target platform which one is better in this case.

In addition to header files and pre-distributed runtimes, there's another factor involved in compile time. C/++ object files and the APIs they use are less standardized and so (especially open source) libraries usually distribute the source uncompiled. In Java and C#, libraries (and the equivalent of header files; this is the biggest part) are already compiled, so there is no extra parsing or compilation. This design makes building large projects much, much faster. While this is still not dependent on the actual language, it is a better design.

Garbage collection is undoubtedly a good thing. It's not good for every situation, no. I would never use GC in a device driver. However, it is not the only reason, or even the biggest reason, for Java and C#'s (lack of) speed. A bigger problem is Java/C#'s relative lack of static allocation. When everything's on the heap, things will be slower. Although C# has a lot more types that can be allocated on the stack, it still has to deal with automatic boxing and unboxing. It would be possible, I believe, to improve the situation a lot, without giving up GC.

Think about C/++'s dynamic allocation for a minute- things would be a lot slower if you malloc/new'd everything (and free/delete'd it afterwards) because of all the extra work on the heap. Now, if you don't consider that inequality, which as I explained could be fixed, the only difference is that GC does all the hard work on deallocation, while manual memory management does it on allocation. C/++ must walk through the heap looking for enough space and modify the list to mark the memory used. All GC requires for allocation is an add. On deallocation, C/++ doesn't always have to do as much work as GC, but it still does quite a bit. It has to walk the list again, insert the free memory and merge it with surrounding blocks. Despite all that, a manual heap can get fragmented. GC follows references and compacts the heap. Compacting can be expensive, but generational GC helps this quite a bit, and there are plenty of designs that figure out good times to start collection.

Java/C# are also safer by design. You cannot create an arbitrary pointer to anywhere you want like "int* x = (int*)0xDEADBEEF". You cannot cast said pointer to a function pointer. Buffer overruns and other such code injection vulnerabilities are nearly impossible. In the case of Java/C# specifically, these kinds of security holes are all in the VM, which is extremely hardened code as it is used in every single program in existence. In another language like this, it would be in the VM or in the compiler, depending on how it was implemented. None of this requires any runtime support, either. It would be just as fast as C/++ if casting rules were tightened rather than changed to Java/C#-style.

C/++ and Java/C# both have their advantages. While most of the community here seems to blindly follow Josh on his "C++ is the best PERIOD" opinion, that is not the case. C/++, or a language much like them with the same speed and target use cases, could be greatly improved with several things straight from Java/C# land:

• design of object files that removes the need for header files and their associated extra parsing/compilation
• more cooperation between libraries (for C/++ this would probably mean a new .NET like super-library for an OS)
• garbage collected heap rather than manual new/delete
• safer memory management and pointer usage