Forgot your password?
typodupeerror
Programming IT Technology

Programming Language Specialization Dilemma 569

Posted by Soulskill
from the choosing-a-path dept.
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."
This discussion has been archived. No new comments can be posted.

Programming Language Specialization Dilemma

Comments Filter:
  • by Anrego (830717) * on Saturday March 21, 2009 @01:24PM (#27279929)

    Honestly... a general knowledge of programming is the best you can hope for.

    Every shop has their own specific tool stack and custom libraries and documentation process. They are also going to need you to be very knowledgable in one or more very specific areas. There's no way you're going to be able to get yourself ready for any.. or even many jobs before hand. The important thing is that you can learn new stuff quickly.. digest existing code.. present your ideas in a digestible way to a diverse group of people (managers, other developers, testers, clients).. work in a team.. and not let your ego get in the way.

    First several months at any new shop are spent learning their way of doing things .. they expect that. It's why programming shops put such a heavy emphasis on the hiring process. The company will invest a lot of money on you before you make them any.

    C++, C, and Java are kinda the standard trifecta these days. I'd suggest doing a little assembler, and maybe a really messed up language like Perl just to see the "other side" (pre-emptive defense: I love Perl.. but common.. it is pretty messed up). One thing I would recommend though that I didn't see in your post is a good knowledge of technical writing. You can have the perfect answer.. but if you can put it on paper in a clear and understandable manner.. what's the point.

  • Practice (Score:5, Interesting)

    by adisakp (705706) on Saturday March 21, 2009 @01:27PM (#27279955) Journal
    The best way to get programming experience is thru practice. Either work on your own personal projects or contribute to a larger shared (OSS) project. That's the only way you're going to become a better programmer. Classes are merely an introduction to the ideas.

    Programming classes are like piano lessons. You're not going to become a concert pianist thru basic lessons without lots and lots of outside practice on your own.
  • COBOL (Score:5, Interesting)

    by flyingsled (1475035) on Saturday March 21, 2009 @01:27PM (#27279959)
    If you're thinking of banking apps, think COBOL (at least here in Canada). Bunch of those programmers are near retirement too...
  • by pm_rat_poison (1295589) on Saturday March 21, 2009 @01:28PM (#27279969)
    Focus on learning how to program properly and efficiently. Learn correct resource-management and security practices and study algorithms. If you master programming in general, you can master any language withing a matter of weeks. Certainly too short a period to make your career based on that decision.
  • Why not web stuff? (Score:3, Interesting)

    by mgkimsal2 (200677) on Saturday March 21, 2009 @01:36PM (#27280035) Homepage

    While it's good you've got solid grounding in C/C++/Java, there's quite a lot going on in the software world centered on the web. Taking your logic skills and applying them to the web arena may net you the "commercial ready" skillset you're thinking of much faster than just trying to hack away at Linux kernel code.

    Most of these will make traditional CS people cringe a bit, but there's plenty to learn from and contribute to in the worlds of PHP, Perl, Python (Pylons, Django, etc), JavaScript, Ruby (Rails), Groovy (Grails), Flex/ActionScript, Silverlight, ASP.Net (new MVC framework out).

    The tried and true recommendations of "pick an open source project and dive in" probably apply here as much as anywhere. The development cycles tend to be faster and more iterative using these technologies (broadly speaking) and you'll find plenty of people to learn from and, with your background, plenty of solid grounding in fundamentals to contribute.

    As someone else already said, no one is going to expect a recent grad to be writing banking software (threaded or not). Few people actually *write* core banking software anyway. You'd more likely be writing web frontends for bank admin and report generation processes.

    Remember that you can generally change direction later on as well. Just because you've studied Java for a few years doesn't mean your future is set in stone as a Java dev. Look at C# - there might be plenty there you'd like too.

    Good luck in whatever you choose!

  • Direction (Score:3, Interesting)

    by holophrastic (221104) on Saturday March 21, 2009 @01:36PM (#27280037)

    You really have a number of paths to select, "computers", as you know, isn't exactly unified.

    If you start your own company, or work for a small company, it doesn't matter what language you use because the client doesn't tend to care. What matters is that in your chosen language, you can do just about anything within the scope of small business. That tends to mean business logic and basic interface.

    If you're working for a very large corporation, with a team of programmers, then you needn't have anything more than the basics. Large corporations will take you for your general breadth. On day one, you'll be shown what to do. On day two, you'll be altering small and isolated parts of very large projects. By the time you're the one maknig large changes, you'll realize that you don't need language-specific knowledge so much as you needed to study their particular implimentation of a project that is more structure than language.

    Finally, if you're a consultant or programming contractor, it won't matter which language you select because there is always someone with eneds in any major language.

    Fifteen years ago, I was in the second world. This large corporation was using embedded perl, and moving to JSP -- before there was documentation for it.

    Ten years ago, I went the first way. I started working for small companies and then I openned my own. My clients have no technical knowledge. So I make sure that no matter what the request, I can do it when I control all of the technical aspects. I'm also in the web world and the custom business software world. I chose Perl, JScript, HTA's, and MySQL. I stop short of programming activex controls and device drivers -- which would have occasionally helped, but I farm those out as small C/C++ executables and tiny projects to someone like you for a few hundred or a few thousand dollars. The last one, for example, registered a protocol (like http:/// [http] that decrypted resources on-the-fly so my crummy little HTA (think web-site in a file with no security restrictions) could have encrypted content on the CD.

    In another twenty years from now, I'll move to the third world.

    So, in summary, pick what you like, and then lower your head, bend your knees, and charge in that direction. Don't do what our parents said. Don't "keep your options open". Slam doors behind you. Holding all of those doors open stops you from actually going through any of them. And besides, most of those doors don't have locks; so let them close.

  • Listen to Norvig (Score:5, Interesting)

    by Phs2501 (559902) on Saturday March 21, 2009 @01:37PM (#27280041)
    Read this:

    Teach Yourself Programming in Ten Years [norvig.com]

    Peter Norvig knows what he's talking about.

  • Be a doctor instead (Score:2, Interesting)

    by Anonymous Coward on Saturday March 21, 2009 @01:39PM (#27280061)
    Since you're a final year student this advice is probably a bit late... but I've been programming for 20 years, and every few years a new language or API comes out that you must learn to stay competitive. It gets old, plus you're competing against decent developers in the East that are paid way less... In retrospect for my career it would've made sense to just be a doctor... you only learn the body once, it doesn't change and you can easily make $100k/yr till you're 70.
  • Re:Good News! (Score:5, Interesting)

    by rossifer (581396) on Saturday March 21, 2009 @01:48PM (#27280145) Journal

    Nobody expects a recent graduate to write a kernel or a banking app!

    Even more precisely, nobody expects a recent graduate to really know how to write good enough code. That's something a new graduate should expect to learn in their first three to six months on the job.

    The expectation is that you already know how to learn languages. The issue with only learning C, C++, and Java is that they all use a related syntax and they are all statically typed. This is not enough variety. I would suggest that before you hit the real world you learn at least one language that isn't the same. Python, Ruby are excellent choices at this time. Lisp, Haskell, Erlang are also possibilities if you'd like to explore functional programming.

    Something else a good developer is usually expected to do is adapt to the coding conventions in the current project. I have found, however, that many if not most developers are completely and unable to adapt to team conventions. They have their "best way" and can't write code any other way.

    If I can provide one piece of advice to help you with your success in programming: remember that conventions are not for you. They're for the people who come after you. Having consistent and readable code is more important than whether or not you like indentation with tabs or spaces.

  • Re:skillsets (Score:2, Interesting)

    by deodiaus2 (980169) on Saturday March 21, 2009 @01:51PM (#27280177)
    Look at this site which rates languages by popularity of use:
    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html [tiobe.com]

    My suggestion is to read Kernigan's The Practice of Programming .
    Debugging the Software Development Process by Microsoft Press
  • by fermion (181285) on Saturday March 21, 2009 @01:53PM (#27280185) Homepage Journal
    Exactly, concentrate on techniques. Moving languages requires an understanding of the how the language approaches a problem, and what the typical errors and pitfalls are, and such an understand only comes with long use. For instance, I remember being 17 after a few years of writing Fortran, and seeing a non descript error appear. I knew what it was, and realized at that point I understood the language. The same thing happened in C after a few years.

    What can and should be learned in school is the various levels of architecture for developing a piece of software. Composite and structured programming in which data is isolated and a minimum knowledge of the data exists outside the relevant functions. We did this even before we had fancy OO programming. Factoring code into base units and refactoring to improve legibility. I have been on some interviews where all i did was write the functions that would be needed to solve the problem, and that was enough. If one has the write architecture, and code money can fill in the blanks.

    Some of this requires classes. I would not be able to write a kernel because I have not had OS architecture, or microprocessor architecture, or even complier design, though I have written simple compilers. I think that these are wonderful things to know, but on my interviews what they wanted was a CS degree, preferable masters, and the ability to put some code on paper.

  • by BrokenHalo (565198) on Saturday March 21, 2009 @02:05PM (#27280279)
    I know this will seem foreign to most of the current generation of graduates, but I would suggest a strong grounding in assembly coding for any processor. If the programmer really understands assembly, s/he should "intuitively" acquire a sound grasp of what makes a good program written in C, Fortran or whatever.

    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.
  • by Anonymous Brave Guy (457657) on Saturday March 21, 2009 @02:13PM (#27280375)

    The idea is that you can apply computer science to any language you want to learn.

    Which is great, except that with such a narrow range of languages to start with, the OP won't have the kind of general background knowledge and breadth of experience to do that yet. The saying that a good programmer can learn a new language in a week is bull and always has been, and it seems that this particular CS course has not covered as wide a range of languages as we might hope for.

    To the original poster, while you still have an opportunity to do it easily, I strongly recommend exploring a few other languages, even if only to the level of basic familiarity that you now have with C, C++ and Java. You may not realise it yet, but those three languages are all more similar than different in the grand scheme of things, and there are more ways to solve programming problems than fairly low-level, imperative, statically typed programming with C-like syntax. To expand your thinking a bit, I would recommend at least learning:

    • a dynamically-typed scripting language (I'd probably suggest Python, but something like Perl or Ruby would do just as well);
    • a functional language (Haskell or OCaml are probably the best documented); and
    • JavaScript (useful if you're ever thinking of doing web work, but also as an example of a rather different way to do OO than the C++/Java approach, and of a mid-range language with C-like syntax but both dynamic and functional features integrated).

    Most of these are immediately commercially relevant in large commercial fields anyway, and functional ideas (though perhaps not dedicated functional programming languages) are becoming more and more important. For bonus points, a bit of Lisp, Smalltalk and some sort of assembler wouldn't do you any harm either, but these are less directly applicable for most commercial roles. On the flip side, some exposure to .Net, probably via C#, is a valuable commercial asset even if it's rather similar to what you've already learned through C++ and Java: jobs working the typical Microsoft tool stack (C#/.Net libraries/ASP.Net/SQL Server...) are a big field.

    The important thing is that you don't have to master each of these at this stage. Just play around enough, even with simple toy programs, to get the basic feel for the different approaches and understand that the C/C++/Java way is not the only one (and certainly not the best one for all jobs).

    And all the while you're doing this, remember that a programming language is just a tool to express ideas. The more general CS knowledge — general data structures and algorithms, design skills, understanding specific fields such as database theory, graphics and operating systems, and so on — is every bit as important, whatever language you use.

  • C++ (Score:3, Interesting)

    by shutdown -p now (807394) on Saturday March 21, 2009 @02:15PM (#27280387) Journal

    Out of those that you've listed, you should definitely consider C++ a priority. Here's why.

    First of all, it gives you C essentially for free. Yes, there are differences, but they are minor enough. The general philosophy is radically different, too, but it's much easier to adjust from C++ to C than vice versa (if you go C++ -> C, you will always remember what you missed, but you'll know how to work around it; if you go C -> C++, you'll just be annoyed by all the RAII stuff that gets in your way, and probably just end up writing C code with C++-style comments).

    Java is on a slow decline. It's still the most popular language out there by and large, but it hasn't seen any significant advances in the last few years. With Sun not feeling well, it's quite likely that it will be taken over by IBM, and that will seal its fate as COBOL-2. It's not that you'll run out of Java job offers anytime soon - new stuff will keep being written, and there's always need of maintenance for existing code, but it's not going to be much fun, especially when you compare your toolset with other guys on the block ("what do you mean, no closures?..").

    As for C++, it's still the language of choice for writing desktop software on any platform, and even in the "enterprisey" Java/.NET/whatever solutions there are often bits and pieces that are best left to C++ for performance reasons, or just because there's a C++ library available that does that thing. Picking up Java (or C#, or VB) after C++ is generally pretty easy (and there is plenty of literature catering precisely to such a transition - google "Java for C++ developers" etc). Furthermore, I've found that people who are looking for senior Java or .NET developers often want at least some C++ experience as well. I guess it shows that you're less inclined to treat things such as GC as "magical", which can matter [msdn.com].

    By the way, while you're at it, have a look at C++0x. Draft standard is already there, and compiler providers are racing to get it implemented. I don't know about g++ release schedule with respect to that, but Visual C++ will have bits and pieces (such as e.g. lambdas) in the upcoming major release, and there are
    new Microsoft libraries that rely on them heavily (e.g. google for "Parallel Patterns Library"). If you know that stuff when no-one else does, that's another one in your favor.

    Of course, as others have suggested, learning just one or two languages is not good enough these days, anyway. Learn something functional. If you want to be pragmatic, go for F# on Windows, or OCaml on Unix. Haskell is worth studying just for the pure aesthetic beauty of the language, even if you'll probably never use it except as a glorified calculator. Same for Scheme.

  • Re:Good News! (Score:5, Interesting)

    by dgatwood (11270) on Saturday March 21, 2009 @02:17PM (#27280413) Journal

    I would argue the exact opposite, actually. If a large percentage of jobs are in .Net/C#, there's a good chance that there are equally large numbers of candidates flocking to apply for those jobs, and that the number of applicants is likely to exceed the number of jobs by a significant margin. If you want a job that will be robust against economic problems, specialize in something that requires more unusual specialization. Learn Objective-C, for example. Either start your own company selling iPhone apps or hunt for jobs elsewhere doing Mac programming. Even though the number of jobs seems very limited, companies have a hard time finding qualified candidates in this area, so if you can fill the slot, you have a good chance at getting the job. The same isn't necessarily true for C# jobs.

  • Re:Good News! (Score:3, Interesting)

    by vux984 (928602) on Saturday March 21, 2009 @02:29PM (#27280539)

    I'm not sure how 5000 applicants competing for 500 jobs is better than 50 applicants competing for 5.

  • by FlipperPA (456193) on Saturday March 21, 2009 @02:59PM (#27280865) Homepage

    I'm a firm believer that the theory, science, and logic of programming is far more important than the language itself. Once you understand the important aspects of elegant design, the rules of most languages are the same. I graduated in 1996 - a while back now - but remember that the thing I thought most sorely lacking from my education was a firm understanding of database architecture and design. That is going to be just as important as understanding solid programming in any job. If a database is well designed, the code should almost write itself, once you understand end users requirements.

    After that mouthful, Tiobe does a fairly good job at monitoring trends in programming language popularity. Java/C/C++ are 1/2/3 according to them. You can see their full list and trends here:

    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html [tiobe.com]

    Regards,

    -Flip

  • Re:Good News! (Score:2, Interesting)

    by zefram cochrane (761180) on Saturday March 21, 2009 @03:23PM (#27281161)

    Parent has a good point. I have taken my fair share of programming coursework, but learned most of my current skill-set on my own. This did not include C#, but did include C++, Java, Perl, Python, and Fortran. When interviewing for a job, these languages interested the company. However, when they came back with an offer, it was for coding in C# for a particular need they had.

    If you already know a bit of C++ and Java, C# is not difficult to pick up, and is used heavily with the .NET environment in many businesses today. I'll be the first to admit...as a diehard Mac/Linux user, it hurt to have to program for the Windows environment and using M$ tools...but it's really not as bad as I originally made it out to be.

    Also important, is to realize that no company that will be hiring a graduate straight out of a BS/BA will expect them to be able to write a massive program immediately or on their own. Most programming houses will have you working in a development team, of which you will slowly integrate, and will only be working on small pieces of a much larger program.

  • by Nursie (632944) on Saturday March 21, 2009 @05:08PM (#27282141)

    Hey,

    C is still number 2 language after java I'll have you know. C is still alive andd well and running most of your stuff.

    There are lots of positions for a good C programmer. You have to be good though.

  • Re:COBOL (Score:2, Interesting)

    by clicktician (1210898) on Saturday March 21, 2009 @06:12PM (#27282721)
    COBOL developers are in demand at many large, multinational corps. Mastercard, for example, uses it heavily. Text books on COBOL are rare, and few have studied it in formal education. The best part is that offshore's don't offer COBOL skills, so job security is quite high.
  • by angel'o'sphere (80593) on Saturday March 21, 2009 @08:17PM (#27283793) Homepage Journal


    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

    Hm, don't get what you want to say. Exactly this above is what you don't care about in Java and C#. Only in C++ and C you need to know this badly.

    However the rest of you post makes sense ;D

    angel'o'sphere

  • by Anonymous Coward on Sunday March 22, 2009 @02:15PM (#27289257)

    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'd like to recommend the exact opposite. Your co-workers will thank you.

    95% of what you are going to see in commercial software is "lowest common denominator" code. For a C++ project, for instance, that means, it will look like C with classes. You're not going to see any clever use of the language. You're not going to see templates (besides USE of template classes such as STL). You're not going to see very interesting uses of inheritance, function pointers, polymorphism, etc.

    And if you start barfing all those language acrobatics into the code base, your co-workers are going to hate your guts. By and large, your co-workers want to go to work, do their job, and go home to play with their kids. If they have to sit there and figure out that what they're looking at is your overloaded () operator because it's a neat way to implement the "Visitor" design pattern, or something, it makes their job harder, they're not going to like you, and the whole project is going to suffer because the code is no longer readable to the team.

    Learn the basics of the language REALLY WELL and be able to crank out functional, readable, SIMPLE code, quickly.

    Of course, this whole post applies only if you're going to write software for a living. If you're learning a language for the challenge and fun of programming for yourself, disregard.

    As a developer that has been around for many years, I would like to say that this is a really bad argument. Writing bad code so that your ignorant co-workers can read it is not the way to go. Instead, improve your co-workers skills by writing the code the way it should be written and then explaining it to them. Peer code reviews are a great place to explain why you used a certain pattern or technique and maybe explain it to your code workers that don't understand. You may not be able to do that. If not, recommend some reading. One of the books that had a real impact on me as a programmer is 'Design Patters' by the gang of four (gof). Look it up if you haven't read it. Recommend it to others.

    In closing, readability is important. However, its not more important that scalability, testability, maintainability, reliability, or any one of the many other ilitys.

    P.S. I hope the message before this one was a joke? I'm not going to even respond to it because I'm assuming it is. =)

UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn

Working...