Best Programming Language for Jobs

[Ender]

Ok, so I went out on a limb and lost it =p I'm a C++ newbie. Let me ask one question though: if you have an abstract base class A with a pure virtual function doSomething(MyParam param), all the derived classes have to implement this function, right? I read something about the abstract class creating a pointer to the derived class which implements it, or at least, its ability to, and this is what confused me. 

EDIT:

Wow this has become so off-topic. But who cares Also changed it's to its* 

[Kp]

if you have an abstract base class A with a pure virtual function doSomething(MyParam param), all the derived classes have to implement this function, right?

Strictly speaking, no.  The following is legal:

Code Select Expand

class A
{
public:
virtual void doSomething() = 0;
};

class B : public A
{
int x;
/* doSomething is not implemented here */
};

class C : public B
{
virtual void doSomething();
};

void C::doSomething()
{
}


However, since I neglected to implement doSomething in B, B is also an abstract class.  Therefore, I cannot declare an instance of A, nor can I can declare an instance of B.  I can declare an instance of C, since C provides an implementation of doSomething.

Note that it's redundant to say 'abstract base class with a pure virtual function'.  A class with a pure virtual function is automatically abstract.

[Ender]

Ah, that makes sense. Thanks.

[Yegg]

Ender, interpreted languages can handle creating games just as well as C++ can. I've een games written in Python, you wouldn't know that they were written in an interpreted language. So what if interpreted languages are slower? Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases. Would you rather have a faster program that is more error prone, or a "slower" program that will never let you down?

[iago]

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.

If there's one thing I hope never reaches Java, it's operator overloading.  I hate it. 

I've been using the 1.5 stream the last couple days, and I have to say I like it.  Enumerations aren't actually numeric values, they're pure enumerations (you can request a value, with ElementName.ordinal(), if you want).  And templates feel so much cleaner than they did with C++, until 2 days ago I always hated templates because they became so unwieldy, but Java actually handles them reasonably gracefully. 

For opponents of Java's decision on unsigned: Java does unsigned the same way as Assembly does, with different operators.  I both Java and Assembly, data types aren't signed, they're just data.  How you use them indicates whether or not they're signed (the classic example is the signed and unsigned shift operators, >> and >>>).  C chose to use different variable types, and Java chose to use a different operator.  In the end, they both have unsigned.  It's VB that doesn't have unsigned at all. 

To answer your question from this thread: none of the above.  Different workplaces use different languages, commonly Java and C#, but if you want to have a much easier life, you should also learn C, Perl, and Shell (Bash or whatever).  When I'm at work, I frequently need to throw together a quick script to make my life easier.  I'll usually use Perl or Shell for it.  If I'm writing anything a little bigger, or that's processing-heavy (not data), I use C.  If I need a program that has to work on different systems or that has to do something more advanced (unzip files, send objects across a network, etc), I use Java.  It really comes down to: The right language for the job.  And they're all important, because it's rare that you do one single job.

[Kp]

For opponents of Java's decision on unsigned: Java does unsigned the same way as Assembly does, with different operators.  I both Java and Assembly, data types aren't signed, they're just data.  How you use them indicates whether or not they're signed (the classic example is the signed and unsigned shift operators, >> and >>>).  C chose to use different variable types, and Java chose to use a different operator.  In the end, they both have unsigned.  It's VB that doesn't have unsigned at all.

So what's the operator to use to perform an unsigned comparison against another value?  I use < and > for signed comparisons, but for unsigned...?

[iago]

For opponents of Java's decision on unsigned: Java does unsigned the same way as Assembly does, with different operators.  I both Java and Assembly, data types aren't signed, they're just data.  How you use them indicates whether or not they're signed (the classic example is the signed and unsigned shift operators, >> and >>>).  C chose to use different variable types, and Java chose to use a different operator.  In the end, they both have unsigned.  It's VB that doesn't have unsigned at all.

So what's the operator to use to perform an unsigned comparison against another value?  I use < and > for signed comparisons, but for unsigned...?

Hmm, now that you mention it, that's never come up.  The only way that comes to mind is moving it into a bigger variable type, but that's gross.  You win!

[Ender]

Ender, interpreted languages can handle creating games just as well as C++ can. I've een games written in Python, you wouldn't know that they were written in an interpreted language. So what if interpreted languages are slower? Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases. Would you rather have a faster program that is more error prone, or a "slower" program that will never let you down?

IMO, there is no way an interpreted language can create a program that can efficiently run a game like Starcraft, Diablo, or WoW. All the instructions for a translated language are already translated into machine language when you run it. But with an interpreted language, you have to run the bytecode (or the equivalent of Java's bytecode) through a virtual machine for interpretation. Each instruction has to be translated into machine language at runtime. Whereas a translated language is already compiled into machine language and only has to run this machine language, an interpreted language has to interpret the instructions into machine language AND then run the machine language through the lower levels. And as I said before, there can be "bottleneck" situations in the interpreted language's VM, whereas a translated language would have already worked these situations out. Games like chess and poker could be easily accomplished using interpreted language, but games like starcraft, with a more complex UI and way better graphics... Then again, my opinion is not based on evidence per se (I have never seen a Starcraft-like program written in Java at runtime). So I could be completely wrong.

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.

If there's one thing I hope never reaches Java, it's operator overloading. I hate it.

Hm, why?

For opponents of Java's decision on unsigned: Java does unsigned the same way as Assembly does, with different operators. I both Java and Assembly, data types aren't signed, they're just data. How you use them indicates whether or not they're signed (the classic example is the signed and unsigned shift operators, >> and >>>). C chose to use different variable types, and Java chose to use a different operator. In the end, they both have unsigned. It's VB that doesn't have unsigned at all.

Ah, you're right. I looked up the >>> operator. It says so here. I guess this operation makes this post look silly!

[Ender]

For opponents of Java's decision on unsigned: Java does unsigned the same way as Assembly does, with different operators.  I both Java and Assembly, data types aren't signed, they're just data.  How you use them indicates whether or not they're signed (the classic example is the signed and unsigned shift operators, >> and >>>).  C chose to use different variable types, and Java chose to use a different operator.  In the end, they both have unsigned.  It's VB that doesn't have unsigned at all.

So what's the operator to use to perform an unsigned comparison against another value?  I use < and > for signed comparisons, but for unsigned...?

Hm, I see your point. That becomes a problem when you're comparing unsigned qwords... which is java's limit for data storage (64 bit signed integers (long)). So the problem in Java is that the reduced range of data types due to everything being signed.

[iago]

Ender, interpreted languages can handle creating games just as well as C++ can. I've een games written in Python, you wouldn't know that they were written in an interpreted language. So what if interpreted languages are slower? Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases. Would you rather have a faster program that is more error prone, or a "slower" program that will never let you down?

IMO, there is no way an interpreted language can create a program that can efficiently run a game like Starcraft, Diablo, or WoW. All the instructions for a translated language are already translated into machine language when you run it. But with an interpreted language, you have to run the bytecode (or the equivalent of Java's bytecode) through a virtual machine for interpretation. Each instruction has to be translated into machine language at runtime. Whereas a translated language is already compiled into machine language and only has to run this machine language, an interpreted language has to interpret the instructions into machine language AND then run the machine language through the lower levels. And as I said before, there can be "bottleneck" situations in the interpreted language's VM, whereas a translated language would have already worked these situations out. Games like chess and poker could be easily accomplished using interpreted language, but games like starcraft, with a more complex UI and way better graphics... Then again, my opinion is not based on evidence per se (I have never seen a Starcraft-like program written in Java at runtime). So I could be completely wrong.

Partly true.  Don't forget, when you have a program that is interpreted, there can be run-time optimizations.  If it is optimized well while it is running, it is possible to skip large parts of processing that may or may not be required, then turn out to not be required.  An example program is to write a loop in Java and C that does nothing, but does it 10000000 times.  The key is to make it do something conditionally so that the compiler can't optimize it out.  The Java version will remove it at run-time, but the C one won't, can't. 

Java is currently slower than C.  But keep in mind that it isn't IMPOSSIBLE, just difficult. 

If there's one thing I hope never reaches Java, it's operator overloading. I hate it.

Hm, why?

That's a whole other discussion.  Search my history for it, I've already said it a long time ago. 

Actually, I did the search, and here's one thing I said about it:

I disagree - I *hate* operator overloading.  It makes things happen that shouldn't happen which just confuses things.

std::string a ="123test" + 3;
That should make a point to the character array "test", and it's impossible to figure out what's going on without the documentation because of the two overloads (= and +).

That code sample is extremely ambiguous as a result of overloading.

[Joe[x86]]

It's VB that doesn't have unsigned at all.

I may be taking this out of context, because I don't know exactly whats being discussed, but Byte is unsigned.

[Joe[x86]]

Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.

In computer programming class, a few days ago, I ran the following code side-by-side:

Java 1.4:

Code Select Expand

public class Main {
    public static void main(String args[]) {
        for(long i = 0; i > -1; i++) {
            System.out.println(i);
        }
    }
}

VC++ 6:

Code Select Expand

#include "stdafx.h"
int main() {
    for(long i = 0; i > -1; i++) {
        printf("%u", i);
    }
    return 0;
}

By the time Java reached 20,000, C++ was far past 60,000.

[Yegg]

Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.

In computer programming class, a few days ago, I ran the following code side-by-side:

Java 1.4:

Code Select Expand

public class Main {
    public static void main(String args[]) {
        for(long i = 0; i > -1; i++) {
            System.out.println(i);
        }
    }
}

VC++ 6:

Code Select Expand

#include "stdafx.h"
int main() {
    for(long i = 0; i > -1; i++) {
        printf("%u", i);
    }
    return 0;
}

By the time Java reached 20,000, C++ was far past 60,000.

Hmm, quite interesting. I'm not sure how accurate such a speed test is, but could you compare Python with C++ in the same manner if you get the time?

[Mephisto]

Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.

In computer programming class, a few days ago, I ran the following code side-by-side:

Java 1.4:

Code Select Expand

public class Main {
    public static void main(String args[]) {
        for(long i = 0; i > -1; i++) {
            System.out.println(i);
        }
    }
}

VC++ 6:

Code Select Expand

#include "stdafx.h"
int main() {
    for(long i = 0; i > -1; i++) {
        printf("%u", i);
    }
    return 0;
}

By the time Java reached 20,000, C++ was far past 60,000.

Hmm, quite interesting. I'm not sure how accurate such a speed test is, but could you compare Python with C++ in the same manner if you get the time?

It's not accurate to do a speed test in that manner, and it's been discussed before.  Not to mention that something as insignificant as that (a few statements) is not indicative of speed of the language at runtime, IMO.

[FrOzeN]

This topic I made ages ago brings up some discussion about speeds.