Best Programming Language for Jobs

[Ender]

Out of the options given, which do you think is the best high-level programming language for jobs? Consider the demand for certain languages in working environments (popularity), and the capabilities of each language. Post the reason(s) behind your vote.

Note: I know that this question may have been asked a dozen times, but it hasn't been asked in a while, and opinions may have changed. So don't tell me to "stop reviving old topics!"

[Warrior]

I went C++ since there was no PHP and "Other" is icky.

I like C++ because of it's (atleast intended) portability across languages withought much runtime support (moreso in C but whatever). It is object oriented and that itself offers some neat features like operator overloading and classes. I would have chosen Java but really I havn't worked with it much and it's limited in most areas since it's interpreted.

I've had good results with Ruby and I'd recommend it to anyone but like Java I havn't used it enough.

[Kp]

Java has some serious shortcomings in the realm of object-orientation.  For instance, you can't do multiple inheritance or operator overloading.  Access specifications must be repeated for every variable or method.  Traditional Java (pre-1.5) provided very little support for typesafe containers.  (You'd get a ClassCastException at runtime if you screwed up, which is nice if you happen to have a testsuite that exercises that path.  Otherwise...)  1.5 finally has some support for it with the so-called "generics", but I'm not clear on whether code which uses generics can even be compiled for a legacy JVM.  Worse, the 1.5 javac defaults to compiling bytecode which is not legacy compatible and complains at you if you don't use 1.5-specific features like generics.

Beware that if any true Java zealots see your message, they'll go on and on about how Java is now almost as fast as C++.  Some fanatics will even claim Java is faster than C++, which can really only occur if the C++ compiler isn't doing a full enough job.

[Warrior]

Well I wasn't getting on it's speed I was getting on it's ability to perform on a level suitible for things like Game Development and stuff. Seriously I know it has a 3D factor but due to thier need to be cross platform I'd asusume it was OpenGL and most likely not very good across platform.

I'd rather use C++ with some ifdef's here and there to maintain portability than complicate things in the long run with Java. Not saying it's not good for a practical application though.

[Ender]

Java has some serious shortcomings in the realm of object-orientation.  For instance, you can't do multiple inheritance or operator overloading.  Access specifications must be repeated for every variable or method.  Traditional Java (pre-1.5) provided very little support for typesafe containers.  (You'd get a ClassCastException at runtime if you screwed up, which is nice if you happen to have a testsuite that exercises that path.  Otherwise...)  1.5 finally has some support for it with the so-called "generics", but I'm not clear on whether code which uses generics can even be compiled for a legacy JVM.  Worse, the 1.5 javac defaults to compiling bytecode which is not legacy compatible and complains at you if you don't use 1.5-specific features like generics.

Beware that if any true Java zealots see your message, they'll go on and on about how Java is now almost as fast as C++.  Some fanatics will even claim Java is faster than C++, which can really only occur if the C++ compiler isn't doing a full enough job.

On the other hand, I think that Java is more OO then C++ and one of the most OO languages there is. IMHO, the absence of multiple inheritance is a good thing, and it was definitely done deliberately by Java's creator. Multiple inheritance just makes it so much more likely that you're going to change one of your base classes and as a result screw up your child classes. Also, you could make the mistake of accessible variables with the same name in different base classes, or making functions with the same names and parameters. I think that Java's interfaces are a very good replacement to C++'s multiple inheritance.

I agree that Java can't be as fast as C++. Java's interpreted whereas C++ is translated. But there is a benefit of interpretation, which is better debugging! And Java's speed has never been an issue for me.

What I don't like about Java is that it is too hard to access asm with it, and it has no unsigned data. These seem like small concerns, because both can be fixed (though accessing asm is a pain), but these are the problems I have come into contact with Java.

My overall opinion on Java and C++ is that Java is more high-level than C++, and so the advantages and disadvantages of both languages revolve around this.

[Joe[x86]]

Java. Compiled to Java Bytecode it is supported over many systems including Linux, MacOS, BSD, Solaris, and Windows, and if you dislike its interpreted nature, programs such as gcj can compile it to native executables.

[Ender]

Someone told me recently that the "Java executables" are just 10-line C programs that use commandline to start up a Java program, such as a jar. And worse, that the computer still needs to have all the Java stuff required for any other Java program, including the JVM. Is this true?

[Kp]

On the other hand, I think that Java is more OO then C++ and one of the most OO languages there is. IMHO, the absence of multiple inheritance is a good thing, and it was definitely done deliberately by Java's creator. Multiple inheritance just makes it so much more likely that you're going to change one of your base classes and as a result screw up your child classes. Also, you could make the mistake of accessible variables with the same name in different base classes, or making functions with the same names and parameters. I think that Java's interfaces are a very good replacement to C++'s multiple inheritance.

Agreed, Java's creators definitely (wrongly) thought it was bad to support multiple inheritance.  How do interfaces mitigate any of these risks?  You can still change the interface to break an implementing class.  You can still have conflicting prototypes come down from multiple interfaces.

I agree that Java can't be as fast as C++. Java's interpreted whereas C++ is translated. But there is a benefit of interpretation, which is better debugging! And Java's speed has never been an issue for me.

How does being an interpreted language have any effect whatsoever on debugging?  A C++ program built with debugging symbols can be traced more easily than a Java program can be traced with jdb.  Build something in VC7 with full debugging symbols, then try to trace it with windbg.  You get symbolic names of all the variables and original source in a companion display.  Or have a C++ program commit an access violation, and check out the core dump.  Assuming it didn't run afoul of RLIMIT_CORE, you get a full image of the process's memory at the time of the fault.

What I don't like about Java is that it is too hard to access asm with it, and it has no unsigned data. These seem like small concerns, because both can be fixed (though accessing asm is a pain), but these are the problems I have come into contact with Java.

Java is specifically designed to keep you away from high performing constructs like programmer directed runtime code generation, in the interest of keeping it portable.  There's no excuse for leaving out unsigned types though.  They did include floating point, even though the JVM is required to implement a full emulation of floating point if the host hardware cannot do it natively.  Given that, why not just require that the JVM emulate unsigned types if it runs on a host which lacks unsigned operations?

Someone told me recently that the "Java executables" are just 10-line C programs that use commandline to start up a Java program, such as a jar. And worse, that the computer still needs to have all the Java stuff required for any other Java program, including the JVM. Is this true?

If it takes a C program 10 lines to start up a JVM, that's a bit silly.  It shouldn't require nearly so much space.  The rest of the answer depends on whether you meant binaries created by gcj or some other strange construct.  GCJ produces true native code from the Java source, though I think it still requires a GCJ-created Java runtime for support.

[MyndFyre]

I agree about multiple inheritence....  I've seen some pretty cool things done with it, but on the whole, it seems to be more trouble than it's worth, especially when you run into virtual calls and naming collisions.  Interfaces seem to solve this problem elegantly.  Also, they allow for some very odd OOP behavior, like a class that inherits from a WheelBarrow and a FireTruck.  While the resultant object might be able to transport materials as well as put out fires, it's pretty clear that the situation should not be that the new class IS_A WheelBarrow and IS_A FireTruck - but rather it simply shares common functionality.  This should be defined via an abstract command -- interfaces -- rather than multiple base classes.  The size saved in code reuse might be beneficial, but changes in the base class -- as already noted -- might come back to haunt you (because as I said, you can change a fire truck, but since our derived class isn't a fire truck, you might not think the change would affect it).

Operator overloading is very much a missing feature.  It's about damn time, too, that the compiler does implicit typecasting for native types so that you can call a method on int.  Too bad that feature isn't available in legacy systems.  Java 1.5's "generic" or "template" feature is funky too.

Agreed, Java's creators definitely (wrongly) thought it was bad to support multiple inheritance.  How do interfaces mitigate any of these risks?  You can still change the interface to break an implementing class.

But you know it at compile-time, not runtime.

You can still have conflicting prototypes come down from multiple interfaces.

But you don't need to choose which implementation to support.  If both a FireTruck and Wheelbarrow specify "transport(Object)," you know that the derived class is going to transport an object.  You don't know how it's done (it's a "black box" of OOP), which is the way it's supposed to be.  You know the input data and the result state.

[Ender]

Yeah... it would be really nice if Java had operator overloading. It's a growing language though, perhaps it will come out in the next platform, just like Enums (a wonderful addition) came out in the 1.5.0 platform.

[Kp]

Agreed, Java's creators definitely (wrongly) thought it was bad to support multiple inheritance.  How do interfaces mitigate any of these risks?  You can still change the interface to break an implementing class.

But you know it at compile-time, not runtime.

The same holds true if you're using an abstract base class in C++.  It's always seemed a bit silly that an interface can define a function (instead of just declaring it).  I can see how you get a very slight bit of safety here, but I still don't think it merits swearing off multiple inheritance.

You can still have conflicting prototypes come down from multiple interfaces.

But you don't need to choose which implementation to support.  If both a FireTruck and Wheelbarrow specify "transport(Object)," you know that the derived class is going to transport an object.  You don't know how it's done (it's a "black box" of OOP), which is the way it's supposed to be.  You know the input data and the result state.

I don't follow here.  If you were doing pure virtual functions in C++, you'd be forced to implement a hybrid-specific transport and get a guarantee that it's the one called (since no other exists).  If the functions aren't pure, then you have a conflict.  In Java, interfaces match pure virtual functions much more closely than non-pure ones.  If the interface mimiced a non-pure function, wouldn't you have the same problem?

Enums were long overdue.  I remember seeing some really ugly hacks to simulate enums in prior versions of Java.

[Ender]

The same holds true if you're using an abstract base class in C++.  It's always seemed a bit silly that an interface can define a function (instead of just declaring it).  I can see how you get a very slight bit of safety here, but I still don't think it merits swearing off multiple inheritance.

But polymorphism would be impossible without defining the function. Polymorphism relies on the fact that you can talk to an object without knowing what object it is. What you do know is the object's interface. If interfaces didn't define functions, then you wouldn't know the exact interface, you wouldn't know what parameters to send to the function. And to know this, you would have to know which kind of object it is, which is why polymorphism would be impossible.

I don't follow here. If you were doing pure virtual functions in C++, you'd be forced to implement a hybrid-specific transport and get a guarantee that it's the one called (since no other exists). If the functions aren't pure, then you have a conflict. In Java, interfaces match pure virtual functions much more closely than non-pure ones. If the interface mimiced a non-pure function, wouldn't you have the same problem?

Hm, I also seem to be on a different wavelength! I quickly googled c++ virtual functions, and so I'm basing this post on what I got out of it (so if I'm completely wrong, forgive me ). What I got out of it is that pure virtual functions are functions of a base class that not all derived classes can handle. So the base class creates a pointer as to which object is talked to when this function is called. So you can talk to many objects that are all derived from abstract base class A, and you don't have to worry that not all of the derived objects can take a certain function call that you plan to make. If I got this right, then this is different from Java's interfaces because in Java's interfaces all objects implement a certain interface, so all the objects derived from abstract base class B have impementations of the defined interface. It seems that the limitation in c++'s pure virtual functions is that the pointer that the base class creates can only apply to one derived class. This helps you in that you can talk to your objects in a uniform, non-specific manner, but you cannot have different implementations of a pure virtual function because a pure virtual function can only point to one derived class to do the work, and so there is a single implementation.

Or maybe I'm wrong, and there is a way to conditionally decide which derived class to point to for a pure virtual function. I'm not that familiar with c++.

[Yegg]

DId anyone even mention Python? Not that it is used in many jobs today. But soem day it, and its fellow interpreted languages will be used everywhere. The idea of these languages is to ease the creation of software developement, where you may hit hard to fix or hard to find errors that require you to debug in languages such as C/C++, Python is the exact opposite. I never have to search for errors in my Python applications, and I develope 10 times as fast as if I used C/C++, C#, or Pascal (just languages I know or relatively understand). The speed difference between Python and C++ for example, is hardly noticeable, and in the end does not matter at all. In the next few years, more and more companies will be developing in Python and other interpreted languages. Lua seems to be gaining some popularity.

[Ender]

Hm, well it's true that interpreted languages are better for debugging and testing, but then again they are slower, and the line-by-line interpretation can result in "bottleneck" situations. They also create larger programs. I agree that interpreted languages will be further embraced as computers become more powerful over time, but I cannot see any large games (i.e. Starcraft, Diablo, WoW) being written in interpreted languages in the near future. Which is an important consideration when deciding whether to use interpreted languages or translated languages.

EDIT3:
Deleted EDIT1 and EDIT2 (lol)
Deleted the rest, because I should back up my opinion (or be prepared to) with evidence before posting it.

[Kp]

The same holds true if you're using an abstract base class in C++.  It's always seemed a bit silly that an interface can define a function (instead of just declaring it).  I can see how you get a very slight bit of safety here, but I still don't think it merits swearing off multiple inheritance.

But polymorphism would be impossible without defining the function. Polymorphism relies on the fact that you can talk to an object without knowing what object it is. What you do know is the object's interface. If interfaces didn't define functions, then you wouldn't know the exact interface, you wouldn't know what parameters to send to the function. And to know this, you would have to know which kind of object it is, which is why polymorphism would be impossible.

I don't follow here. If you were doing pure virtual functions in C++, you'd be forced to implement a hybrid-specific transport and get a guarantee that it's the one called (since no other exists). If the functions aren't pure, then you have a conflict. In Java, interfaces match pure virtual functions much more closely than non-pure ones. If the interface mimiced a non-pure function, wouldn't you have the same problem?

Hm, I also seem to be on a different wavelength! I quickly googled c++ virtual functions, and so I'm basing this post on what I got out of it (so if I'm completely wrong, forgive me ). What I got out of it is that pure virtual functions are functions of a base class that not all derived classes can handle. So the base class creates a pointer as to which object is talked to when this function is called. So you can talk to many objects that are all derived from abstract base class A, and you don't have to worry that not all of the derived objects can take a certain function call that you plan to make. If I got this right, then this is different from Java's interfaces because in Java's interfaces all objects implement a certain interface, so all the objects derived from abstract base class B have impementations of the defined interface. It seems that the limitation in c++'s pure virtual functions is that the pointer that the base class creates can only apply to one derived class. This helps you in that you can talk to your objects in a uniform, non-specific manner, but you cannot have different implementations of a pure virtual function because a pure virtual function can only point to one derived class to do the work, and so there is a single implementation.

Or maybe I'm wrong, and there is a way to conditionally decide which derived class to point to for a pure virtual function. I'm not that familiar with c++.

It seems your understanding of the terminology is wrong.  It's quite possible to create an interface without defining a single function.  The functions need to be declared, but needn't be defined.  A pure virtual function is a declaration of the prototype.  A non-pure virtual function is a declaration of the prototype and a definition of a default implementation (which is used if the derived class does not override it).  Your second paragraph really doesn't make much sense, so I'm not even going to bother rebutting it.