Slashdot Mirror


Programming Language Specialization Dilemma

aremstar writes "I'm a final-year Computer Science student from the UK. During my studies, we covered 3 programming languages: C, C++ and Java. The issue is that we didn't cover any of these languages in sufficient depth for me to claim that I have commercial-ready experience. It's one thing being able to write simple programs for class assignments, but those are quite different from writing something as complex as the Linux kernel or a multi-threaded banking app. I'm thinking of spending a few weeks/months studying in order to specialize in one of those languages. Fortran also entered my consideration, as it is great for numerical computing and used by many financial institutions, banks, etc. In terms of skill requirements in job ads, my (brief) experience suggests that most programming jobs require C++, with Java a close second. C — unfortunately — doesn't appear as much. My question is: if you were in my shoes, which language would win your time investment? My heart suggests C, with a little bit of Fortran to complement it, but I'm a bit worried that there might not be enough demand in the job market."

2 of 569 comments (clear)

  1. Re:Going against the grain... by HiThere · · Score: 4, Informative

    That was excellent advice for the earlier generations of processors. I'm not convinced that it's a good idea now. But something similar could be achieved:
    Learn to write programs in JVM machine code.

    Or Parrot. Or Python Virtual Machine. Or MIX, even.

    Actually, Mix might be the best, but it's a bit more limited. But modern processors are too complicated for this to be a useful learning tool, and you don't want to REALLY start assembly language programming. A new generation of processors will break everything you've ever written.

    For the purpose, Parrot machine code would probably be best. JVM the most useful.

    OTOH, you might also consider LUA. It's not a great language, per se, but it's an excellent adjunct to C or C++.

    Part of the problem is that there are a number of directions to go, and a limited amount of time. You really NEED to learn some sort of assembler, and for that I would recommend Parrot. It looked like a reasonably simple code, and reasonably well documented. But I'm not sure that this is the right time.

    An alternative is to pick a language and start learning to use it's standard libraries and how to manipulate files. (When I was in college, I never got taught how to use files, and I regretted this for years, until I had backfilled the knowledge on my on time.) If you pick C++ STAY AWAY FROM TEMPLATES!! That's advanced work. (Yeah, use them for simple generics, but don't do anything fancy. They only exist to make your life simpler. Once they stop doing that, avoid them.)
    I can't give any comparable advice for C. In C and C++ both you need to restrain your use of macros and pointers. Prefer arrays over pointers. Prefer references over pointers. (And acknowledge that sometimes they are necessary evils...but they remain evil.)

    My advice against pointers is symmetric to the standard advice against program jumps (AKA "Go to considered harmful") and in favor of structured programming (i.e., while loops, do loops, and function calls). I'm not sure that structured programming is even mentioned anymore as it's become so dominant. The same reasons it became dominant argue against the use of pointers. (You'll note that Java essentially eliminated the use of pointers. It's a [slightly] more recent design than C++, and not as close to the metal. But the efficiency cost of Java was more due to garbage collection and a virtual machine than it was to the elimination of pointers. [E.g., see Digital Mars D, which is about as efficient as C++, but severely limits the need for pointers.])

    P.S.: Re:

    Many of the current commercial languages belong in toyland. They are designed for programmers who really don't have any idea about managing resources efficiently.

    That's a really obnoxious attitude. Different languages are designed for different situations. If you're writing code in a hurry, you don't want to worry about lots of unnecessary fiddling details that would be very important if you had plenty of time and really needed to optimize execution. So you'd use different languages. If you use C where you should use Ruby, everyone will be very unhappy with you, and likewise for the converse. Actually, I think that C is almost always the wrong choice. Most work that's done in C should really have been done in Ada...but the people doing it already knew C, and it was "good enough", so that's what they used. Don't ever, however, make the mistake that this prove that it was optimal. (Except in the sense of the costs of causing the programmer to learn a new language.) Ada would even often be a better choice in places where C++ is chosen, though less frequently. With Java the division is less clear cut. Where Java is used because the programmer didn't know C or C++, then the same comments apply. In many other cases, however, Java is a better choice. (Java is less efficient, but it has dynamic capabilities that are very difficult to manage in Ada.

    Things get more complicated when you start to include complex libraries, such as Lua. In that case C + Lua is frequently a superior choice to Ada...because Lua interacts better with C and is only used when a bit of dynamic behavior is appropriate.

    --

    I think we've pushed this "anyone can grow up to be president" thing too far.
  2. Re:Forget C and Fortran by OeLeWaPpErKe · · Score: 4, Informative

    You forget to mention that there are basically 2 principles you need to know in order to learn both java and C# in a VERY fast way :
    1) memory allocation principles
    2) scripting languages
    (and if you want to really excell)
    3) generating code

    1 will be more (much more) than adequately covered in any C++ course. C++ is like a "galactic conquest kit (some assembly required)" of programming languages. It can do anything. Anything any other language can do, can be done in C++. Java is more an "IKEA" language, compared to C++'s "metal shop". Everything "typical" is done for you in Java, but you have to add a few screws here and there. But getting a chair that's really "your kind of chair" ... not going to happen. And a less-than-average C++ programmer is going to be a good C# and Java programmer. Generics are lacking in Java, and that's being polite.

    2 will be covered with something like perl or python. Especially if you cover list comprehensions (compare them to SQL for example)

    And if you are a good programmer, but you want to be the best one in the state, you'll need to add 3 to your repertoire. LISP is a good language to learn to see these principles in action. Imho linux shell is also a good language for this. Or using linux shell to generate configuration files. That sort of thing.

    The important thing is not to force each language and use the "lowest common denominator" but really learn a language in order to appreciate it's differences from the others. You can write procedural programs in each of these languages trivially. DON'T. If you learn C++, use template metaprogramming and multiple inheritance (of templated classes, passing through template parameters up the inheritance chain). Use operator overloading for everything from combining 2 lists, write the complex number class everyone writes. Write a sparse matrix class if you're up to it. Learn boost. Learn ANTLR ...

    I realise these are not many good problems for these solutions. The point is to learn to use them, get a feel for what they can do.

    Use C# for what it's good for : use all the features of C# 3.0. Use the UI designer, get to know it's advantages.

    With java you want to use it's libraries. Use a few contraint satisfaction libraries. Write a J2EE application, say the bookstore bullshit. Admire the endless exceptions of the typical server.

    And spend the rest of your education learning maths. Algebra, as much as possible. Theoretical logic. Only when those 2 subjects are sufficiently covered start with analysis. Don't forget to get at least an introductory class about numbers (e.g. when/why do multiplications fail on calculators and computers, what are fixed points of matrices ? What happens when floating point numbers differ too much in matisse from the solution of the calculation you're making, ...)

    The more algebra and logic you know, the easier algorithms will become.