Java...

[sohguanh]

IMHO each programming language has it's pros and cons. Can you imagine using C++ to do web interactive effects which are dominated by Javascript,CSS or Adobe Flex,Flash? Can you imagine using C++ to do complex pattern matching on huge log files ? etc etc.

Each programming language is created for a purpose, and for some of them they really excel in that area. This cannot be denied. My firm belief is there is no SINGLE programming language for all programming tasks. It all depend on the problem on hand and choosing the correct programming language for it.

So as for Java vs C++ etc, I am neutral. Sometimes Java fit, sometimes C++ fit. It depend on the problem on hand. E.g Java for device driver development ?!?! I still think C/C++ fit better.

[coder777]

@rapidcoder

The overhead for smart pointer is negligible 99% of the programs out there (especially user interface). While an additional garbage collection thread is a massive overhead that might even stop the relevant proccessing.

They don't reclaim cycles

What does that mean?

They don't defragment memory

Java does? How?

(why pay for objects you no longer use?)

In Java it stays in memory long after it's used.

Wondering how long? Has Java an object a timeout?

Ok, Java comes with it's own memory management. But is it really better than system? I doubt.

What I like about Java is that it comes in it's own jar and thus be transported over OS limits.

[sohguanh]

I think the debate should not be restrained to Java vs C++. In fact it should be garbage-collector vs non-garbage collector programming languages.

I believe JVM concept is not unique to Java. There are other programming languages that uses some sort of garbage collector underneath too. So I believe the debate should not be just Java vs C++ but more on a general level.

[helios]

>They don't reclaim cycles
What does that mean?

If you have a graph-like data structure where it's possible to go from node A to node B, then directly or indirectly back to A, reference counting will not work.

>They don't defragment memory
Java does? How?

The GC can move objects around in memory because the program is not aware of their addresses, in the same way that the OS can swap pages in and out of physical memory because processes only know their virtual addresses.
Remember, kids: All* problems in computer science can be solved by adding another level of indirection.


_{* Except the problem of too many levels of indirection.}

[rapidcoder]

The overhead for smart pointer is negligible 99% of the programs out there (especially user interface). While an additional garbage collection thread is a massive overhead that might even stop the relevant proccessing.

If you were right, how come, in my evolutionary optimisation program, the GC thread accounts for less than 0.1% of CPU? GC is a problem if you don't understand how it works. I know one C++ programmer that killed JVM's GC by putting a finalize method in every single class he defined (and if you need a finalizer in Java, you're certainly doing something wrong, with some rare exceptions).

BTW, the additional GC thread is a huge advantage - on a multiprocessor machine, it can sit on a spare core(s) and make the total GC overhead exactly zero. Add to that zero cost deallocation and a blazingly fast allocation (about 10x faster than malloc) and clearly GC is the performance winner.
The only problem that GCed applications might encounter are pauses, but this is due to poor Oracle's GC implementation, not due to the GC concept itself. Pausless efficient GCs do exist. And smart pointers can block the thread for a long time, too.

In Java it stays in memory long after it's used.

So what? In C++, too. That you called "delete" on something, doesn't really mean the memory is returned to the OS, because of fragmentation (only full clean pages may be returned to the OS).

The GC can move objects around in memory because the program is not aware of their addresses, in the same way that the OS can swap pages in and out of physical memory because processes only know their virtual addresses.
Remember, kids: All* problems in computer science can be solved by adding another level of indirection.

Wrong. There is no another layer of indirection in the JVM memory model. The application uses "real" pointers, not some virtual handles. The difference is that the JVM knows where all those pointers are and fixes them when objects are moved.

But is it really better than system?

In C++, new, delete and malloc, free are not system calls. Actually they have very little to do with the system. The system doesn't know anything about your C++ "objects". What does know is the userland C++ runtime, which contains the memory allocator, just as the JVM contains the GC. The architecture is very similar, the implementation is very different. Java's GC does not use the new/delete, malloc/free calls to manage memory. It replaces them.

[helios]

Wrong. There is no another layer of indirection in the JVM memory model. The application uses "real" pointers, not some virtual handles. The difference is that the JVM knows where all those pointers are and fixes them when objects are moved.

Pfft. Implementation details. It doesn't contradict what I said, that the program is not aware of the addresses of objects.
Besides, some pointers are handles. For example, the so-called "compressed pointers".

[1vRz3TCk]

Isn't this just a little bit "My Leatherman is better that your Gerber"? Does it really matter? They are different languages, they have different philosophies behind them both in implementation and use.

[tition]

Can you imagine using C++ to do web interactive effects which are dominated by Javascript,CSS or Adobe Flex,Flash

html+javascript is the easiest way to implement C++ GUI.

I use javascript quite a lot in my C++ program (just output html+javascript via std::cout to an Apache server). I write the html+javascript in a separate file, and then convert (using a small program of course) to c++ static std::string's. Needless to say, I use the browser to display the output of my program :)

Furthermore, native client is coming out, so we will soon have a rightful place inside the browser (as much if not more than Java does ;).

[Cheraphy]

@tition: How have I not heard about this?!?!? I just spent the last 15 minutes reading everything I could about nativeclient.... sooooo excited XD

[sohguanh]

http://code.google.com/p/nativeclient/ sounds interesting but this isn't new isn't it ? When Java become "hot" initially it was due to Java applet. A/some compiled Java .class that "travel" from the server to the user browser and then execute within the browser. It was revolutionary during that time but soon lost it's favor due to the time needed to download the bytecode from the server to the user browser. Also the browser must be installed with JVM to run the sand-boxed Java applet.

I wonder if Google when launching Native Client factor in those experiences from Java applet. Learn from past mistakes and try to correct them in their new approach.

[rapidcoder]

Google says in their FAQ NaCl is aimed rather at porting old legacy applications to the web. Somehow I can't imagine writing new webapps in sandboxed C++ - the probably only advantage of C++ over Java which is easy access to hardware and OS level has been removed in NaCl.

As for performance, the most important factor for webapps is download time, and here it will be an order of magnitude longer than for Java/Silverlight/Flash applets, considering how many utilities are already in their runtime environments that are not part of standard C++ library and (for Java) how awesome pack200 is.

Portability? NaCl will probably never run in IE nor iOS browsers. That will be ported to Firefox or Opera is also doubtful.

It was revolutionary during that time but soon lost it's favor due to the time needed to download the bytecode from the server to the user browser. Also the browser must be installed with JVM to run the sand-boxed Java applet.

These were never the reasons. The time to download and start Flash applets is similar. And you also need to download a Flash plugin. And somehow Flash is on 90-95% of computers.

Sun generally f**ed up deployment issues - installation of JRE was cumbersome and lengthy, there was no auto-update service, it was impossible to create your own progress loading splashscreen, applets often failed because of wrong version of JRE instead of prompting for JRE update (like Flash applets do), deploying applets portably was very hard from the developers perspective, there was no ability to interact with DOM, Swing was pretty ugly etc. All of these have been fixed long time ago, but much too late. Another important reason was that Sun didn't release anything "visual" for creating flashy advertisements or simple games with minimum effort almost without programming. So Flash immediately took that part of the market.

[sohguanh]

Swing was pretty ugly etc

I think above is rather subjective. The concept and syntax-wise/implementation of event driven programming model present in Swing has been adopted in Android SDK also. So a person who has done Java Swing programming will be familiar to the event-driven API provided by Android SDK.

The Java Swing event driven model may take sometime to adjust to but in general I find it works for GUI related stuff. This is purely my opinion though.

that Sun didn't release anything "visual" for creating flashy advertisements or simple games with minimum effort almost without programming

Above I agree but there are actually 2D graphics API. It is just that they are at very basic primitive API level. It lack higher level convenience API like what Flash provided. That is why you see lots of Flash on the Web becuz programming-wise it is so much easier compared to Java.

[tition]

Somehow I can't imagine writing new webapps in sandboxed C++ - the probably only advantage of C++ over Java which is easy access to hardware and OS level has been removed in NaCl.

Native client is not intended to write traditional web apps in C++. It is intended to turn a traditional non-web app (such as a game like quake or a computer algebra system) into a web app. According to a google paper this is at the cost of only 5% up to 30% performance loss (btw quake had only 5% performance loss - you won't even notice it).

What is the rationale behind that? It's pretty clear. I have never seen something uglier in my life than writing GUI via WINAPI. So, we will ditch that horribly designed monster WINAPI for a much friendlier way to display things on the screen - the web browser :)

[sohguanh]

horribly designed monster WINAPI

Actually it is not so bad. It is just the adoption of Hungarian notation that turn a lot of developers off. Look at the Unix/Linux system calls, they are much more manageable and yet they do not lose out in functionalities in comparison to WinAPI.

The lack of Hungarian notation used in API outside of WinAPI speak of it's popularity or should I say notoriety :P

[helios]

What about the fact that most common calls look like DoSomething(0,0,0,0,actually_useful_parameter,0,0,0,0,0)?

[tition]

to back the anti-WINAPI opinion:
Hello world with apache server with enabled cgi scripts:

#include <iostream>
int main()
{ std::cout << "Content-Type: text/html\n\n";
  std::cout << "<html> <title>Hello World </title><body>Hello world</body></html>" ;
  return 0;
}

What is the shortest "Hello World" you have seen in WINAPI?

[hamsterman]

What is the shortest "Hello World" you have seen in WINAPI?

#include <windows.h>

int main(){
   MessageBox( 0, "Hello, World!", "Banana", MB_OK );
}

:-)

[tition]

@hamsterman
alright you win :). It appears I quit winapi before I managed to learn its secrets :)

[moorecm]

I love Java but unfortunately I spend my professional development time primarily in C++ (C and Perl on occasion).

Java in general is free, portable, and has less of a learning curve than C++. It's perfect for academics.

The GC debate seemed to have skip over its greatest benefit (even though it's inherent). Organizations spend a fortune on resources, tools, and work-items to find, prevent, and fix memory leaks. Managing your own resources is error-prone, no matter how careful you are.

Swing is easy to use and capable. It's "event-driven model" was being criticized earlier but it sounds unfounded. What other model is there for a GUI? Sure, different toolkits use different methods to communicate between widgets (callbacks, virtual method hooks, signals and slots, etc.) but they are all event driven.

If I want a quick distributed database application, I'd use Java. If I wanted to manipulate text files, I'd use Perl. If I wanted to do system operations, I'd use C++.

[rapidcoder]

Swing is easy to use and capable. It's "event-driven model" was being criticized earlier but it sounds unfounded. What other model is there for a GUI?

I haven't criticized the event-driven model but that Swing look and feel is ugly. This will never be fixed, because Swing is deprecated now (for good reasons). As for the event-driven model for GUI - I'd expect the reactive model to be much better and much more scalable, although it hasn't been yet widely tested, and only few languages are powerful enough to support it (C++ is not one of them).