1. Limited time only! Sign up for a free 30min personal tutor trial with Chegg Tutors
    Dismiss Notice
Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

What programming language should I learn?

  1. May 12, 2013 #1
    I'm a mathematical physicist expecting to finish his Ph.D. this summer. I'm not having any luck with academic positions, so I'm getting ready to try industry. Note that I am not at all sure what kind of position I want. Finance? Sure. Consulting? Yeah, why not? R&D somewhere? Yup.

    BUT...my computer skills are, I think, pretty underdeveloped. (In fact, one of the reasons I went after academia in the first place is that my computer skills seemed too crappy to land a nice industry position; I think industry is a better fit for me than academia anyway.) I've used Mathematica a lot, but it doesn't seem very many people care about that. So what should I do? I took a class on C in college and did very, very well, and so I suppose I could (and probably should) brush that off a bit...but what else?
  2. jcsd
  3. May 12, 2013 #2
    That's a good starting point.

    Consider getting familiar with object-, and more general, class-related concepts and consider learning C++, Java or Python. I would recommend C++, because if you can handle that, learning Java or Python or whatever (except assembly dialects) modern language afterwards is a piece of cake.

    As a foundation for OO, get yourself an issue of
    Grady Booch
    Object Oriented Analysis and Design
    and start "playing" with those concepts in a language of your choice; preferably C++.

    Another excellent book is
    Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
    Design Patterns: Elements of Reusable Object-Oriented Software

    Finally, to get a glimpse of more modern, generic concepts, have a look at (C++) std-library containers std::vector<T> and std::valarray<T> and "Boost"(http://www.boost.org/), especially at boost::ublas and boost::graph; i somehow would assume you
    could like that.

    Regards, S.
  4. May 13, 2013 #3
    Well you should have a look at dice.com or indeed.com at what kinds of programming jobs out there interest you. There's a huge variety, and most types of programming domains have a favorite language or two. So if you can figure out what type of development interests you, then learn the languages that are useful in that type of development.

    One big area these days is web programming, which is largely PHP but also Java, Ruby and ASP.NET, with SQL being hugely important for all these (but very easy to learn). Another big area is mobile device programming which is dominated by Objective-C (iPhone) and Java (Android).

    C++ is a good language to learn for a wide variety of fundamentals, but the majority of jobs don't use C++, and employers aren't generally willing to wait around for you to learn another language. So depending on how much time you have you may be better served to just learn the relevant language for the part of the industry you want to work in.
  5. May 13, 2013 #4
    I would say C#/JAVA and SQL if you want a job
  6. May 13, 2013 #5


    User Avatar
    Science Advisor
    Homework Helper

    Nothing wrong with those bools (and there's even a lot right about the second one IMO) but I wouldn't call either of them good books to start learning OO.

    IMO, Better to start with a language where you can't "ignore OO" - i.e. Java, rather than C++, because if you already know C, you will probably fall into the bad habit of writing C++ code that looks exactly like C.

    The time to buy those books is when you know enough to disagree with what's in them, IMO. That's when you will really learn something from them.
  7. May 13, 2013 #6
    Good point.

    But I see this
    quite contrarily - especially working with those books from the very beginning should point the learner in the right direction.

    That's part of why I mentioned them.

    Best regards, Solkar
  8. May 29, 2013 #7
    I think C++ is a good language to learn. If you are planning to become a hard core programmer then what many of the people above are suggesting should work. Spend some time learning about algorithms and graph theory too, a little bit about operating systems, theoretical computer science and relational algebra and databases. These would be good for the more brainier jobs.
  9. May 29, 2013 #8

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    The topic of "what programming language should I learn?" comes up repeatedly at this site. In my opinion, that is the wrong question. The right question is "What programming languages should I learn?" The answer to this is "a lot". Good programmers, scientific or otherwise, eventually learn every step from low level assembly to fourth generation or higher language, and learn every major programming paradigm. Learning one language doesn't cut it. Learning at least one new language a year is a reasonable goal.
  10. May 29, 2013 #9
    I feel this is an overkill. If you know two or three languages its easier to get a job. But once you're on the job you can learn new languages as and when you require them. You're not going to remember all of them anyway. I work in a scientific type of programming job where math and developing efficient algorithms are equally important as knowledge of the language and I am speaking only from my own experience. I don't know much about the mainstream programming jobs but what I've seen from people I know is that once they start off with a specific language they tend to specialize in it for eg. one guy I know specialized in java and another in oracle databases. I know one guy who worked as a C++ programmer but then lost that job and ended up having to learn java because there were more jobs in that area. So life seems quite chaotic here with people practically living on their wits.
  11. May 29, 2013 #10

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    Is it? Let's look at what languages / tools a physics grad student needs to learn.
    • Fortran. Nobody has mentioned this language. Physics departments are chock full of legacy code written mostly in Fortran. The scientific library is very likely to be written in Fortran.
    • At least one of python or perl. Sometimes one needs to write some experimental code, see if an algorithm has the slightest chance of working. Python and perl perfect for this. Sometimes you need to glue bits and pieces of multiple programs together. Python and perl are the perfect glue code.
    • At least one of C, C++, or Java. Fortran isn't a marketable skill. Python is agonizingly slow.
    • Bash or tcsh. This is what one types at the command line. It's a good idea to learn what's under the hood.
    • Make. At some point a simple script is no longer good enough to build the complex program that models the interior of a failing star. Make is the tool one needs. It's also provides a handy introduction to the declarative programming paradigm.
    • Matlab or Mathematica.
    • LaTeX. Even if the PhD thesis can be written in Word, the articles one wishes to publish most likely need to be written in TeX or LaTeX.
    That's seven languages / tools, and unless one plans on being a tenured grad student, that's a language a year.
  12. May 29, 2013 #11
    ... depends on the domain and who you're working with. I wouldn't recommend learning C++ before you know what you're getting yourself into. It might just be a waste of time. If you go into web development, you're going to be using python, ruby, javascript, or something similar. *Nobody* uses C++ for web development. Does C++ help you learn other languages? Sure, but so what? The ideas are present in many other languages.

    Find the people you want to work with and ask them what tools they use.
  13. May 29, 2013 #12


    Staff: Mentor

    I worked as a programmer for 30 years and knew a number of languages I learned in my degree before I started - Assembly, Foretran, Cobol, Pascal and Simula.

    The fact of the matter is once you know two or three languages learning another one is a snap. As one of my professors said - syntax is boring - that's not what programming is about - its about concepts that are language independent.

    Learn some Assembly and two high level languages like C++ and Python and you will be fine.

  14. May 29, 2013 #13
    Who writes assembly by hand? Unless this is popular with people in computational physics, I would say that's really poor advice. It's really not a marketable skill.
    Last edited: May 29, 2013
  15. May 29, 2013 #14


    Staff: Mentor

    Occasionally, when you want performance you tune critical parts by writing in assembly language. Its also a good for understanding whats going on inside the computer. And you do not write assembly by hand - you use an assembly language which is compiled exactly like a high level language - its advantage being it allows you access to low level functions normally hidden such as the stack.

    I always remember when I learned it I thought - what the fook - why learn this rubbish. The professor said he at one time worked at a place that used it exclusively but they had this huge library of subroutines. Mostly you simply link them together - easy peasy - nothing to it. I sort of giggled - until I actually went out to work and realised how true it was - regardless of what language you use its mostly linking together standard subroutines. To tune a system you have a look at the subroutines chewing the most resources and tune it. Using assembly makes that tuning easier.

    Besides high level languages like C have ways to include inline assembly - if you really want to tap the languages full power you need to know it.

  16. May 30, 2013 #15


    User Avatar
    Science Advisor

    I second that. While the time when you would actually write assembly by hand in real-world to-be-delivered programs is long past, being able to understand it is still a valuable skill, especially when debugging or tuning applications[1].

    [1] and even today, some kinds of problems are still best handled in terms of inline assembly (say, matrix mutliplication kernels).
  17. May 30, 2013 #16
    Yes, many people will tell you that you need to write the critical and most time consuming code in assembly, but how many people *actually* do that? How many people actually do that better than the compiler? How many people actually do it better than the programmers who wrote the matrix multiply library you're using? Also, unless you're programming for specialized hardware, or study computer architecture, you won't 'know assembly'. Assembly for x86 is a mess.

    There are special domains where this sort of thing is relevant. But the guy isn't even sure where he wants to go.

    It's like somebody asking about what kind of car to get and then getting recommendations for websites which sell car parts.
    Last edited: May 30, 2013
  18. May 30, 2013 #17


    Staff: Mentor

    I have done it - but it wasn't complex and it was more to access some of the low level functions of the database system we were using. Using the higher level language it was written in it was SVC bound - if you are not an IBM geek then don't worry about what that is, simply its short for a supervisor call and doing a lot of them can slow programs down. You would issue a call to read the associator in an inverted list database to get the next entry. Its in memory so it should happen quick but it still required a SVC. There was a low level call available to return the associator to memory in the program bypassing the SVC. When the change was released the report was it was like a turbocharger had been added. That's the main reason - on occasion you want to do things a higher level language wont allow you to do.

    All I am saying is once you know 2-3 languages picking up a new one is a snap and if one of those is assembly you have a more rounded background and can pick up other low level languages. You do not need to do it often - but on occasion you do.

  19. May 30, 2013 #18
    I'm going to come in on the side of the number of languages doesn't matter. If you learn a few sufficiently complex languages, then you'll have most of what you need to learn any other language. Especially for you mathematical physicists, it should be obvious that the syntax is not important, only the structures (an if statement is an if statement in every language it appears in).

    I wouldn't focus on assembly language with your background. You shouldn't be marketing yourself as a coding specialist, because your only background in coding is a C course you took in college (that doesn't mean you can't get a coding job). Unfortunately, there are high school students with much better background than that (and will take the job for much less than you). Most employers would cringe at the idea of setting their employees on assembly, especially non specialists. That's why languages like Java are so popular, because they minimize the number of mistakes programmers make by shielding you from the computer. I guess my point is that since you aren't a comp sci major/phd, then most likely someone else will do the assembly language manipulation for you.
  20. May 30, 2013 #19


    Staff: Mentor

    Actually that's true. Its guys like me with a CS background that are called on for stuff like that. So while its desirable and nice to know assembly it's more important to know a higher level language like Python or Java. Turkeys like I was will be called in if tuning is required.

    Last edited: May 30, 2013
  21. May 30, 2013 #20

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    I'll give a specific example: spherical harmonics. Newton's law of gravitation only pertains to point masses and objects with a spherical mass distribution. The Earth and Moon are not spherical. Use Newton's law of gravitation and you won't capture key dynamics. Something more complex is needed. One widely used technique is to model gravitation via spherical harmonics. We had a very large simulation that used spherical harmonics to represent gravitational attraction. The simulation spent an inordinate amount of CPU time applying those spherical harmonics. In a boiled down version of that large simulation, almost all of the CPU time was spent in just a handful of lines of code.

    A naive implementation of a spherical harmonic expansion involves multiply nested loops with all the calculations in the inner loop. After all, that's what the math says to do: [itex]\sum_i \sum_j \text{hairy expressions}[/itex]. The formulae in that inner loop are quite complex as the code needs to calculate potential (a scalar), the gradient of potential (a vector), and the gradient of that (a second order tensor).

    I looked at the assembly generated by the compiler. One problem was that the compiler wasn't finding common expressions that could have been calculated just once, or even better, pushed to the outer loop. While the assembly code showed the problem, hand tuning that assembly code would not have been the right solution. The right solution was to rewrite the C code so that those common expressions were calculated just once.

    The code was still too slow even after applying these optimizations. Those hairy expressions involved a number of integer to double conversions. Delving once again into the assembly, I could see that there was an immense amount of low level bit twiddling in performing those conversions. This bit twiddling is slow. Once again, hand tuning the assembly would not have been the right solution. The right solution in this case was to build an integer to double table that spanned the range of integers that needed to be converted to doubles and then perform those integer to double conversions via table lookup.

    Bottom line: Even though we didn't write a bit of assembly to speed things up, knowledge of assembly was critical in identifying the problems with this code.
  22. May 30, 2013 #21
    Hi D H,
    Everything you've mentioned is a very good thing to learn and your list would be definitely be a very good starting point for the person who posted this query. But a lot of them don't qualify as full fledged programming languages. bash and tcsh are shell scripting languages. make is a file format. LaTeX is a
    formatting language. Matlab/Mathematica have some programming capabilities but they are interpreted languages suitable more for numerical/symbolic computations than for developing stand alone applications. Also, all of them don't have the same learning curve. Some of these can be learnt in a few days. So what you are basically saying is that it is a language or tool a year. But if you are looking for a job right now you can't wait seven years so you got to crash most of these in a few weeks or a month.
  23. May 30, 2013 #22


    User Avatar
    Science Advisor

    Actually programming in Assembly is a mess but there are other reasons to know the machine. One of the things you quickly learn with a understanding an actual machine and the code generated by your language instead of just programming the abstract machine created by the computer language are the limits of compiler optimization and why language languages have developed 'hints' to communicate about the actual machines interface to real hardware to make your code run correctly, faster and more efficiently when compiled.

    The C 'Volatile' is a good example: http://blog.regehr.org/archives/28
  24. May 30, 2013 #23

    D H

    User Avatar
    Staff Emeritus
    Science Advisor

    I disagree. You'll at best have what you need to code poorly in languages similar to the ones you already know. Learning to program as opposed to code in that new language takes effort and time. Learning to program well in that new language means learning the language's idiosyncrasies and idioms.

    Learning to program in a language that represents a programming paradigm dissimilar to those you already know is tougher yet. A person who knows only imperative, procedural languages can move to yet another imperative, procedural language with some ease but is going to face an uphill battle in moving to another paradigm such as object oriented programming or functional programming. C programmers who have just started learning C++ doesn't really write C++. They write a pidgin dialect better named C plus or minus. It takes a good amount of time to make the transition from pure procedural programming to object oriented programming. The transition to functional programming or data driven programming is harder yet.

    No, it's not. An if statement in Lisp looks and behaves like the ternary statement in C/C++ rather than a C/C++ if statement. A Haskell program chock full of if statements is a sign of a noob who doesn't really know how to program in Haskell. There's not much need for if/then/else in Haskell.

    Yes, I did abuse the notion of "language" in that list. However,
    Bash and tcsh are Turing complete. They are programming languages.

    Why it's handy to learn (as opposed to hunt and peck your way through the command line): Suppose that after some fits and starts, you successfully execute a sequence of shell commands, including some loops and if statements. Suppose you need to do this all over again sometime later. How to preserve that work so you don't have to go through all those fits and starts? Simple: Pipe your command history to a file, edit that file, perhaps generalizing a bit, and tada! you have a handy shell script that you can run again at that later time.

    Huh? C is a file format. C++ is a different file format. Python, yet another. Make is a language. Some versions of make are even Turing complete. The make language is an example of the logic programming paradigm, somewhat akin to how Prolog works. One key difference: Make rules are not recursive. To get a make that is Turing complete, you'll have to use a version of make such as gnu make that supports lambda expressions (functional programming paradigm). With lambda expressions it's turtles all the way down.

    A rather important one, particularly for a math or physics PhD candidate. Learning to use it properly to write a thesis is a significant undertaking, as hard as learning a new programming language. Not that you'd want to program in it, you can. It is Turing complete. Fun and games with TeX/LaTeX: Here's the (in)famous xii.tex (build as plain TeX rather than LaTeX).
    Code (Text):

    Fjfi71PAVVFjbigskipRPWGAUU71727374 75,76Fjpar71727375Djifx
    RrhC?yLRurtKFeLPFovPgaTLtReRomL;PABB71 72,73:Fjif.73.jelse
    B73:jfiXF71PU71 72,73:PWs;AMM71F71diPAJJFRdriPAQQFRsreLPAI
    I71Fo71dPA!!FRgiePBt'el@ lTLqdrYmu.Q.,Ke;vz vzLqpip.Q.,tz;
    ;Lql.IrsZ.eap,qn.i. i.eLlMaesLdRcna,;!;h htLqm.MRasZ.ilk,%
    s$;z zLqs'.ansZ.Ymi,/sx ;LYegseZRyal,@i;@ TLRlogdLrDsW,@;G
    LcYlaDLbJsW,SWXJW ree @rzchLhzsW,;WERcesInW qt.'oL.Rtrul;e
    doTsW,Wk;Rri@stW aHAHHFndZPpqar.tridgeLinZpe.LtYer.W,:jbye
    The distinction between interpreted and compiled is a bit arbitrary. There are C and Fortran interpreters, and there are Matlab and Python compilers. That Matlab isn't suitable for developing standalone applications: Tell that to the developers of multiple spacecraft control systems that each wrote their entire system in Matlab/Simulink.
  25. May 30, 2013 #24
    This list is just utterly ridiculous.
  26. May 30, 2013 #25

    jim mcnamara

    User Avatar

    Staff: Mentor

    I see. And how do you back up this assertion?
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook