• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

programming languages

Node_Pointer

Limp Gawd
Joined
Mar 26, 2002
Messages
313
OK, I know there has been alot a talk about which programming language to learn. An yes, it would be great to learn them all, BUT, what does it mean to learn a language?

I have been developing for some time now, around 8 years. I have developed in VB, VB.NET, C, C++, C#, Java and pretty much all the web technologies.

NOW, the language i know best is C# and ASP.NET, altough the language I have spent the most time with, at work, is C++.

It is great to be flexible. Once a person knows how to code, picking up another language is easy. After all it is just syntax.

I guess what I am getting at is, I have worked with alot of languages and technologies, but I am not a MASTER/GURU at any?

Putting aside all the "learn them all" and "use the tool that works best for the situtation", what do you SUGGEST is the "better/most beneficial" technology to use?

I hope I do not get flamed for this!
Have a great day!
 
I guess what I am getting at is, I have worked with alot of languages and technologies, but I am not a MASTER/GURU at any?
I don't understand this question.

Putting aside all the "learn them all" and "use the tool that works best for the situtation", what do you SUGGEST is the "better/most beneficial" technology to use?
It will depend on how you measure "better/most beneficial".

Do you mean "most beneficial" for your likelihood of effective employment? For flexibility when choosing employment? For not so likely employment, but excellent pay when you do find a job?

Or the likelihood of your getting a job at a specific company where you most desperately want to work? Or in a particular industry?

Do you mean "most beneficial" for doing the kind of work you happen to enjoy the most?

The "most beneficial" for expanding your knowledge in programming? In computer science? In network administration?

The "most beneficial" for solving problems or doing work when your main job is really not in development or IT, but some other field -- just using a computer and this language as a tool?

The answer, for every one of those, is really quite different. I don't think any particular language is "most beneficial" over all others in all situations. I'm not even sure you can pick a "most beneficial" language for even a broad category of situations.
 
That's like saying what is the best automobile. There has to be a few prereqs. Every language can do just about everything you need.

Its mainly going to be opinion based answers. My vote, by far, would be java. It has mutimedia framework add-ons, platform independant, a few lines changes it from a program to a web app, and it has a very nice structure seeing as it is bases on hierarchies of classes and makes polymorphism easy. The downside, there arent pointers so to speak. Every language has a downfall though.

Why are you asking this question 8 years into programming? It seem like the average 'I've never programmed before, what do I learn' question.

Just do what works for you.
 
looks like he just wants to completely "master" a particular language, rather than pick up anything of immediate utility. toward that end, i would say it doesnt really matter what you pick, but common sense would be to master the programming language you most often use.s
 
Seems that you're missing "interesting" languages here... You don't have any of the general-purpose Open-Source scripting languages (Python, Perl, Ruby...). You don't have any functional languages (Lisp, ML, Haskell...) or other 'strange' languages (Smalltalk, Prolog...).

Based on that list, I'd hazard to guess you've probably spent most of your time working with Windows - exploring the Linux/Unix camp, using your existing language toolbox, might be of interest to you as well.
 
Most beneficial is a tie; design and debugging. Nothing language specific. You can learn any language, you can master all the funky nuances of a couple. But the ability to create clear, concise design documents and debug complex issues makes you the master of all things programming.


I'm half joking.
 
this question is just as good as the one suggested earlier: "what is the best automobile?" they have different uses.

C is very very fast; from a language standpoint, speed is limited only by how good your compiler is. C++ is just as fast until you choose to employ the benefits of OOP. Both languages provide powerful syntax features to condense code and make it more readable.

Ada a very very safe language to code in, one that won't allow you to do many of the dumb things that C will let you do if you're not careful, but you lose some speed at run-time because of the machine-code level error checking. additionally, the langauge is ver wordy.

Java is pretty safe, has awesome documentation, and a highly object-oriented environment provides extremely easy integration of common, pre-written tasks. java is dog slow due to being interpreted from bytecode, though.similar (though not identical) things can be said about the .NET languages.

LISP is awesome for applications requiring arbitrary precision as it is built into all the data types... but that can come at a performance hit, let alone the possibly complexity of understanding the machine-level representation of the primitives.

ForTran is notorious for being an unfriendly language, but is still used extensively in mathematical and modeling situations...useless languages don't do this.

the answer: "for what purpose" applies very much so. it is the ONLY intellogent answer to the question: "what is the best programming language?"
 
C++ is just as fast until you choose to employ the benefits of OOP.

C++ is just as fast as C, period. The problem is that a lot of class libraries are poorly designed and/or coded. With the right class library, C++ is just as fast as the equivalently-coded structured program in C.
 
Most beneficial is a tie; design and debugging. Nothing language specific.

This is very true if you add "analysis" to the mix.

The problem with becoming a master in any one language is that the industry keeps changing the current fad language. I worked with at least 20 different languages and have become quite fed up with some doofus manager thinking that changing programming environments - again - will solve all the problems. It is rare that technology is the cause of a project failure - the problem is usually management.

If you know C++, you pretty much are capable of picking up Java, JavaScript, JScript, PHP and a bunch of other cheap imitations. Only the gotchas change.

But the ability to create clear, concise design documents and debug complex issues makes you the master of all things programming.

I'm half joking.

You're not really. Writing good documentation is a lot harder than writing good code. I've met lots of good coders, a few great coders and very few decent documenters. Unless you code for fun or develop throw-away apps, documentation is the key to a good system.
 
C++ is just as fast as C, period. The problem is that a lot of class libraries are poorly designed and/or coded. With the right class library, C++ is just as fast as the equivalently-coded structured program in C.

Which class library is the right one?
 
OK, I know there has been alot a talk about which programming language to learn. An yes, it would be great to learn them all, BUT, what does it mean to learn a language?

I have been developing for some time now, around 8 years. I have developed in VB, VB.NET, C, C++, C#, Java and pretty much all the web technologies.

NOW, the language i know best is C# and ASP.NET, altough the language I have spent the most time with, at work, is C++.

It is great to be flexible. Once a person knows how to code, picking up another language is easy. After all it is just syntax.

I guess what I am getting at is, I have worked with alot of languages and technologies, but I am not a MASTER/GURU at any?

Putting aside all the "learn them all" and "use the tool that works best for the situtation", what do you SUGGEST is the "better/most beneficial" technology to use?

I hope I do not get flamed for this!
Have a great day!

Thanks for turning this thread into which language is better, or You don't know enough languages.


Back to the original question, The real question is what does Node_pointer think is the best language based on his experience and what he wants to do when he grows up.

I know a little about all of them, does that help me? Some, but sometimes it hurts because I do not know enough to fully take advantage of that language.

In this moment in time for me is MS languages just because we are an all MS shop. If I left to go somewhere else and they were more mixed environment, my languages would natural switch.
 
Once a person knows how to code, picking up another language is easy. After all it is just syntax.
Not necessarily. Picking up C++ might be easy if you know C. Picking up Prolog or Haskell wouldn't be so straightforward. It's a hell of a lot more than just a change of syntax. It's a fundamentally different way of thinking.
 
Which class library is the right one?

In my experience - the one you write yourself. That, unfortunately is only practical for small project stuff where you don't need a full-featured library. Any library that is designed by a committee and is supposed to be everything to everyone will be a mess.

In practical terms, these libraries don't really exist. If you are told to develop for Windows using Visual C++, you're stuck with that.

But to the original post - it isn't OOP that causes the problem. C++ does not add any overhead to C.
 
In practical terms, these libraries don't really exist. If you are told to develop for Windows using Visual C++, you're stuck with that.
I'm not following you. Visual C++ isn't a class library.
 
C++ is just as fast as C, period. The problem is that a lot of class libraries are poorly designed and/or coded. With the right class library, C++ is just as fast as the equivalently-coded structured program in C.

you're telling that creating an entire object with accessors, mutators, and all the other functions is just as fast creating the same type of thing using a C struct without the dupilcate functions?

i happen to like C++ very much.... but OOP brings inherent machine overhead to programming... more memory, more stack space, more processor cycles. that doesn't mean it isn't worth it, but there's a reason why you see C over C++ more often in very tight places like microcontrollers.
 
you're telling that creating an entire object with accessors, mutators, and all the other functions is just as fast creating the same type of thing using a C struct without the dupilcate functions?

No, I said that an object-oriented program in C++ is no different than a properly structured program in C. The only difference between a class and a struct is the default access - class defaults to private and struct defaults to public. The only difference between calling "new" in C++ and calling malloc in C is that new calls malloc first and then calls the ctor. A properly structured C program will have the initialization of any malloced memory in one place - a function - that makes it just like a ctor. Everything else is equivalent. Classes put the functions together with the data, structs can, but many C programmers place the functions outside with less concern for division of responsibility for data. Clean up that structure and it looks a lot more like C++.

The only reason that C++ class libraries get excessive run time overhead is because the designers tend to get carried away and add a lot of baggage that isn't needed.

Don't forget that a decent optimizer can make a lot of function calls disappear. The purpose of an simple accessor or mutator function in C++ is information hiding and encapsulation of data, something the CPU doesn't care about. If all the function contains is "return value;", the optimizer can strip the function call completely (and can do so for more complex functions as well). Some compilers do that better than others. What the programmer sees is not what the computer needs to do - programs are written for programmers. The C++ compiler just has to make sure the end functioning of the machine code is correct.
 
Java is pretty safe, has awesome documentation, and a highly object-oriented environment provides extremely easy integration of common, pre-written tasks. java is dog slow due to being interpreted from bytecode, though.similar (though not identical) things can be said about the .NET languages.

I don't know about "dog slow". Have you used java lately? Sure, there is a one-time hit when the program starts, but after that, it's fast. Also, it's not entirely interpreted from byte-code. The JIT compiler uses runtime analysis to compile commonly used methods to native code, which makes it faster. I don't know about the .NET languages, but I'm pretty sure they do something similar.

Java has had a pretty bad reputation in the past, but things have changed lot over the 10 years java has been around. The current versions are quite fast, and only getting faster.
 
Visual C++ comes with class libraries.

I'm very well aware of that, as I worked on and managed the teams that wrote them. But you're not "suck" with them. You can use them, or not -- and you can go get whatever other library you'd like and use that with the same compiler.

I guess your assertion is that a poorly-implemented class library can end up being pretty slow, and I agree with that. But I'm confused by some of your surrounding remarks.

Michael Daly said:
The only difference between calling "new" in C++ and calling malloc in C is that new calls malloc first and then calls the ctor.
There are at least a couple other differences of significant importance, particularly when considering performance.

Michael Daly said:
Don't forget that a decent optimizer can make a lot of function calls disappear.
It's a common misconception that inlining is always faster, and that the ability to inline is related to the prowess of the compiler. It is, to an extent--but it has far more to do with the structure of the program.
 
I don't know about "dog slow". Have you used java lately? Sure, there is a one-time hit when the program starts, but after that, it's fast. Also, it's not entirely interpreted from byte-code. The JIT compiler uses runtime analysis to compile commonly used methods to native code, which makes it faster. I don't know about the .NET languages, but I'm pretty sure they do something similar.

Java has had a pretty bad reputation in the past, but things have changed lot over the 10 years java has been around. The current versions are quite fast, and only getting faster.

actually, i can't argue with you. it's gotten quite a bit faster since its inception but still takes forever to load even a small graphical application. additionally, the last time i did any sort of performance computing, i was sieving prime numbers and my java was pretty slow with the same algorithm compared to my C++. i'm not JVM-savvy and compiled-code savvy enough to know why this is, but it's very possible that I just didn't know enough of what i was doing behind the scenes in the java prog.

lastly, graphical programming isn't really an interest of mine, so it might be that i just don't know what part of the API to use and whatnot, but i've noticed in my own applications that Swing is really slow.

to michael daly -- we agree then that C++ is just as fast as C until you use OOP. the difference is not in the language, it's in all the other stuff that's added to make an object oriented program. if i want to make an OOP application, i'll use C++ and not take the time to add all the things to a C program that C++ incorporates automatically.

if you don't agree with me on this, that's fine... but i see your argument as something similar to: "Ada is just as fast as C as long as you add to the C program all the overflow checking and bounds checking that Ada compiles with by default." which is correct, but also missing my original point entirely.
 
There are at least a couple other differences of significant importance, particularly when considering performance.

Can you clarify? I always thought the only difference between a class and a struct was that the class would run the ctor and dtor, whereas a struct would be without those extra initialization/termination functions. That said, there is probably a bit more going on in the background with respect to allowing the class to use inheritance, but I'm not sure what exactly is going on.
 
structures can inherit, as well, in C++. They can also have constructors and destructors, and may be given compiler-provided functions, if required.

My point is more about the differences between malloc and new. Here, the substantial difference is that operator new throws an exception in the event of an out of memory condition. A good programmer will check for a NULL return from malloc and branch in response accordingly. They'll have to write this code for every location where malloc() is called, and end up writing a bunch of code to handle out of memory errors. operator new will throw, and that means the calling code has to be compiled to handle exceptions. Exception-enabling the calling code can get pretty expensive, particularly in aggressive usage.

For example, say I want to dynamically create a tree-like structure. I have CNode, which accepts pointers to two other CNode objects:

Code:
CNode* pRoot = new CNode("Root",
		new CNode("Leaf1", NULL, NULL),
		new CNode("Leaf2", NULL, NULL) );

The compiler has to emit a great deal of code to handle the nested exceptions that are possible here, and correctly unwind any partially constructed objects. In plain C, creating such a construct takes a bit of work, but is far more cumbersome because of the manual error checking that's required.

Saying that the only difference between operator new and malloc is that new calls malloc then executes the constructor is really wrong. It's one of the differences, but the exception semantics are meaningful differences both in semantics at compile time and performance at runtime.
 
It's a common misconception that inlining is always faster, and that the ability to inline is related to the prowess of the compiler.

There are more ways to optimize a function call out of existence than inlining the code. You can branch to the subroutine without pushing registers/arguments on the stack, for example, if sufficient registers exist and the subroutine is restricted to use only a few registers. This can happen if the compiler has the source of both the calling program and the function in the same compilation unit - in a class, for example.

I worked on an OO development where we were able to ensure that almost all member functions used a minimal function call by keeping the register usage under control. This made for very fast function calls.
 
to michael daly -- we agree then that C++ is just as fast as C until you use OOP. the difference is not in the language, it's in all the other stuff that's added to make an object oriented program.

No - it is possible to write a good OO program with no overhead, If you compare real code, you'll find that there are only a few programmers that can produce better C than C++ (assuming that the class library isn't a dog) when comparing to C++ written by programmers who actually understand the language.

It isn't OOP that makes a C++ program slow. It's bad programming. The same thing hampers C.
 
Here, the substantial difference is that operator new throws an exception in the event of an out of memory condition.

I haven't looked at the latest specification of C++, but that certainly isn't in the definition of the language that I have and has not been implemented in all compilers.

Saying that the only difference between operator new and malloc is that new calls malloc then executes the constructor is really wrong.

Only if the language spec has changed in the last several years. I've been away from it for a while, so I won't say that this is correct or not with certainty.
 
I haven't looked at the latest specification of C++, but that certainly isn't in the definition of the language that I have and has not been implemented in all compilers.

Only if the language spec has changed in the last several years. I've been away from it for a while, so I won't say that this is correct or not with certainty.

It hasn't changed lately, but what I've written is still true. Your assessment is both outdated and incorrect. When you have time to get caught-up with the language specification, you'll want to read sections 18.4.1, 3.7.3, and 5.3.4/13.
 
No - it is possible to write a good OO program with no overhead, If you compare real code, you'll find that there are only a few programmers that can produce better C than C++ (assuming that the class library isn't a dog) when comparing to C++ written by programmers who actually understand the language.

It isn't OOP that makes a C++ program slow. It's bad programming. The same thing hampers C.

1) i never said C++ was slow. don't misunderstand me.
2) when i run top on my solaris 9 system, one instance running a c++ prog that declares 100 objects containing one integer and one function and a c prog that declares 100 structs containing one integer and just declare a function for all structs to share, the cpp prog has over double the size and also nearly double the resident memory usage.

there IS an overhead incurred with OOP. more memory, more stack space, more time in creating objects. that doesn't mean you notice it like you're comparing C to Java, but it's there. there is no getting around its existence. at a machine level, it is slower and uses more resources.

if you'd like, i'll post my programs and my top data for you to see. otherwise, i assume you believe me.
 
if you'd like, i'll post my programs and my top data for you to see. otherwise, i assume you believe me.

Please do! I'm surprised at the relative numbers -- double the executable size suggests that you've not built them correctly, or have used different features and unintentionally ended up comparing apples and oranges.
 
i'll post it after work today.

i used gcc 3.4.2 on a solaris 9 machine. i passed no options to the compiler; perhaps that is an issue.

from memory, the C prog was a little over 1 K and the C++ prog was a little over 2 K.
 
i'll post it after work today.
Thanks!

i used gcc 3.4.2 on a solaris 9 machine. i passed no options to the compiler; perhaps that is an issue.
Indeed, I'd figure that's part of it. Not turning on optimizations will cause pretty bad code gen, even for simple programs. gcc is certainly not known for producing small code, but you're not giving it a fighting chance.
 
okay..

well, i took screenshots but couldn't figure out how to post them... so i copied the text from my terminal emulator instead. if you want screenshots, either give me a private email or else show me how to post. C program first:

Code:
   PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
 22265 ----      1   0    0 1056K  704K cpu      0:02 43.83% a.out

Code:
#include <stdlib.h>

struct test_struct{

   int x;
};

void func();

int main(){

  int i;

  struct test_struct* h;

  for(i=0; i<100; i++)
    h = malloc(sizeof(struct test_struct));

  while(1);

   return 0;

}


void func(){}

now cpp prog:

Code:
   PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
 22394 ----       1   0    0 2264K 1312K cpu      0:07 99.93% a.out

Code:
class test_class{

   public: int x;
  void func_one();
};

void test_class::func_one(){};


int main(){
  
  test_class *h;

   for(int i=0; i< 100; i++)
      h = new test_class();
   while(1);

   return 0;
}

as i said, i passed no options to the compiler. i used gcc for the c prog and g++ for the cpp prog
 
Here's the C code that VC++ 2005 generates. I used /Ox, which is a group of optimization options. You can think of /Ox as being a production build with good, basic optimizations, and /Od as being a build with optimizations completely disabled so you can most easily debug the resulting code.


Code:
_main	PROC

; 10   : int main(){

  00000	56		 push	 esi

; 11   : 
; 12   :   int i;
; 13   : 
; 14   :   struct test_struct* h;
; 15   : 
; 16   :   for(i=0; i<100; i++)

  00001	be 64 00 00 00	 mov	 esi, 100		; 00000064H
$LL5@main:

; 17   :     h = malloc(sizeof(struct test_struct));

  00006	6a 04		 push	 4
  00008	e8 00 00 00 00	 call	 _malloc
  0000d	83 c4 04	 add	 esp, 4
  00010	83 ee 01	 sub	 esi, 1
  00013	75 f1		 jne	 SHORT $LL5@main
$LL2@main:

; 18   : 
; 19   :   while(1);

  00015	eb fe		 jmp	 SHORT $LL2@main
_main	ENDP

Really nothing to it; we push 4, call malloc, and loop 100 times over it.

Building the C++ program you have with /Ox, here's the code I get:

Code:
_main	PROC

; 10   : int main(){

  00010	56		 push	 esi

; 11   :   
; 12   :   test_class *h;
; 13   : 
; 14   :    for(int i=0; i< 100; i++)

  00011	be 64 00 00 00	 mov	 esi, 100		; 00000064H
$LL5@main:

; 15   :       h = new test_class();

  00016	6a 04		 push	 4
  00018	e8 00 00 00 00	 call	 ??2@YAPAXI@Z		; operator new
  0001d	83 c4 04	 add	 esp, 4
  00020	85 c0		 test	 eax, eax
  00022	74 06		 je	 SHORT $LN8@main
  00024	c7 00 00 00 00
	00		 mov	 DWORD PTR [eax], 0
$LN8@main:

; 11   :   
; 12   :   test_class *h;
; 13   : 
; 14   :    for(int i=0; i< 100; i++)

  0002a	83 ee 01	 sub	 esi, 1
  0002d	75 e7		 jne	 SHORT $LL5@main
  0002f	90		 npad	 1
$LL2@main:

; 16   :    while(1);

  00030	eb fe		 jmp	 SHORT $LL2@main
_main	ENDP

As you can see, it's almost exactly the same. The difference is that we're not building with exception handling turned-on in the compiler. As a result, the compiler assumes that operator new() returns NULL. After each call to operator new (which has the decorated name "??2@YAPAXI@Z"), the code test to see if NULL was returned. If it was, it just keeps going in the loop, skipping the initialization. If it wasn't NULL, then the default constructor is invoked; that constructor sets the memory in the object to zero. Again, this demonstrates that calling malloc() isn't the same as calling new an then calling the consructor on the resulting memory; there's also a test to see if new actually worked.

The C++ code for me is 32 bytes long. The C code is 21 bytes long. Hardly double the size! I think that either your analysis is too coarse, or you're seeing lots of dependency bleeding because you didn't turn on any optimization, or your tools are pretty lacking. (Odds are, the real answer is some combination of those causes.)
 
I've modified your code to measure perf. I just call the Windows QueryPerformanceCounter() functions to read RTDSC and see how many ticks the loop took.

Here's the modified C++ code:

Code:
#include <stdio.h>
#include <windows.h>

class test_class{

   public: int x;
  void func_one();
};

void test_class::func_one(){};


int main(){

	LARGE_INTEGER liStart;
	LARGE_INTEGER liStop;
	QueryPerformanceCounter(&liStart);

  test_class *h;

   for(int i=0; i< 100; i++)
      h = new test_class();

	QueryPerformanceCounter(&liStop);

	printf("%I64u\n", liStop.QuadPart - liStart.QuadPart);
	QueryPerformanceFrequency(&liStart);
	printf("%I64u\n", liStart.QuadPart);

   return 0;
}

When I run it, I get these results on my QX6700:

Code:
C:\projects\c_compare>new2
60420
2671260000

And for the C code:

Code:
C:\projects\c_compare>alloc2
60360
2671260000

So the C code is 60 clock cycles faster. QueryPerformanceFrequency says my clock speed is 2.61726 GHz, so 60 cycles is 2.2 hundred-millionths of a second. (Er, at least, it is if I'm not having a bad orders of magnitude day.)
 
when i compiled into the Sparc assembly the first night, the code was very similar as you suggested (once i included some do-nothing functions to the C code to emulate a constructor and destructor). i didn't post this code because i figured that since this uses dynamic memory that the assembly wasn't an accurate representation of how much memory would really be used once the programs were running.

the double resource usage came at run-time; my assumption was because the 100 objects use more memory than the 100 C structs due to the C structs sharing functions as opposed to creating a function for each object.

is my analysis incorrect because of a bad assumption or because of my lack of knowledge of how code compiles and runs?
 
When you said

nameless_centurian said:
the cpp prog has over double the size and also nearly double the resident memory usage.
were you referring to the working set of the program, or the executable size? Looking at the code compares the executable size.

What part of the memory usage was code, and what was data? The size allocated by the two functions should be identical, unless you're using some debug library which handles malloc() and new() with different internal structures, granularity, or debugging features.

The compiler never calls your empty function. The linker might (should) discard it.
 
i compared both, but i decided to post the comparison of running program, the working set as you called it.

i have passed no options to the compiler; perhaps g++ defaults with different settings than does its C counterpart, gcc. i would venture to say that i imagine this is the issue, as i can't imagine operator new would help to create a footprint double the size of the one malloc() helps create, but you're much more familiar with this than i am.
 
Node_Pointer, don't learn languages randomly. I know that for a new programmer it looks like it is important to have many languages on a resume, but I can tell you - after a while you like the guys with few languages better.

I highly, highly recommend that you pick one language and then learn different programming paradigms, techniques, algorithms, debug a lot of code you write or download, that sort of thing.

%%

Having said that, if you want to hit languages, here's what to do:

1) never learn single-vendor, single-implementation languages. I know many people who programmed less than a decade don't feel this way, but let me tell you - unless you are a very shallow programmer who only collects buzzwords for his resume you will build libraries, tools and debugging skills for "your" language, and it really really hurts when they take it away from you.

2) you should probably pick a language that allows you to explore new paradigms, programming techniques that open your mind. You should be able to tell who there are virtual destructors but not virtual constructors, you should be able to compute PI at compile time, you should know the difference between a closure and a continuation. Common Lisp, given a good book such as Norvig's is a good language here, but if you are hardcore enough you can go a very long way in C++. All that C# and Java stuff is basically free of compile-time computing and locks your brain into a tiny box. Haskell might also be a good option. Smaller languages like Ruby are nice (or Scheme - shudder).

3) look at your list of languages and ask yourself whether you know the ones that are important to you as well as you should. Given that list I suggest you have a critical look at your C++ skills.
 
Don't learn a language, per se, learn the basics and then when you have a specific job to do, figure out how to do it in that language.

With that said, English is the most important language for a developer. If you want to be a millionaire be a good developer, have a mastery of English, and a functional utilization of Hindi :D

If you can explain high level concepts to non-computer types, you might as well print your own money, cause that's how fast it's going to come in.

Other than that, learn good development techniques and how to test your code correctly.
 
Back
Top