What programming language should I learn?

In summary, the conversation discusses the individual's background as a mathematical physicist and their plan to transition into industry. They mention their lack of computer skills and ask for advice on what languages to learn. Suggestions are made for C++, Java, and Python, as well as web and mobile programming. Books on object-oriented analysis and design and design patterns are recommended. The conversation also touches on the importance of learning multiple languages and paradigms for a successful programming career.
  • #1
AxiomOfChoice
533
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?
 
Physics news on Phys.org
  • #2
AxiomOfChoice said:
I took a class on C in college and did very, very well,
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
AxiomOfChoice said:
I'm a mathematical physicist
could like that.

Regards, S.
 
  • #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.
 
  • #4
I would say C#/JAVA and SQL if you want a job
 
  • #5
Solkar said:
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

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.
 
  • #6
AlephZero said:
because if you already know C, you will probably fall into the bad habit of writing C++ code that looks exactly like C.
Good point.

But I see this
AlephZero said:
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.
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.

Solkar
 
  • #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.
 
  • #8
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.
 
  • #9
D H said:
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.

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.
 
  • #10
physwizard said:
I feel this is an overkill.
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.
 
  • #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.
 
  • #12
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.

Thanks
Bill
 
  • #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:
  • #14
goingmeta said:
Who writes assembly by hand?

Occasionally, when you want performance you tune critical parts by writing in assembly language. Its also a good for understanding what's 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 realized 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.

Thanks
Bill
 
  • #15
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).
 
  • #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:
  • #17
goingmeta said:
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?

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 won't 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.

Thanks
Bill
 
  • #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.
 
  • #19
DimReg said:
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.

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.

Thanks
Bill
 
Last edited:
  • #20
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.
 
  • #21
D H said:
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.
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 learned 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.
 
  • #22
goingmeta said:
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.

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
 
  • #23
DimReg said:
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.
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.

an if statement is an if statement in every language it appears in.
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.
physwizard said:
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.
Yes, I did abuse the notion of "language" in that list. However,
bash and tcsh are shell scripting languages.
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.

make is a file format.
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.

LaTeX is a formatting language.
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:
\let~\catcode~`76~`A13~`F1~`j00~`P2jdefA71F~`7113jdefPALLF
PA''FwPA;;FPAZZFLaLPA//71F71iPAHHFLPAzzFenPASSFthP;A$$FevP
A@@FfPARR717273F737271P;ADDFRgniPAWW71FPATTFvePA**FstRsamP
AGGFRruoPAqq71.72.F717271PAYY7172F727171PA??Fi*LmPA&&71jfi
Fjfi71PAVVFjbigskipRPWGAUU71727374 75,76Fjpar71727375Djifx
:76jelse&U76jfiPLAKK7172F71l7271PAXX71FVLnOSeL71SLRyadR@oL
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

Matlab/Mathematica have some programming capabilities but they are interpreted languages suitable more for numerical/symbolic computations than for developing stand alone applications.
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.
 
  • #24
D H said:
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.

This list is just utterly ridiculous.
 
  • #25
Gauss M.D. said:
This list is just utterly ridiculous.

I see. And how do you back up this assertion?
 
  • #26
I don't think his list is ridiculous. Competent programmers need to know the whole stack. I don't think you need in-depth knowledge of assembly, make, or bash (this is something you can easily learn on demand), but you should be able to pick out appropriate tools for each job.

Whether or not the OP, or physics students, have to know all that--I have no idea.
 
Last edited:
  • #27
jim mcnamara said:
I see. And how do you back up this assertion?

57% of the list consists of stuff that's either not a programming language, or stuff that is really easy to pick up if you're already well versed with c++ or whatever. He is implying that you need in-depth knowledge of a bunch of really tough-to-master languages to be considered programming savvy when really, solidity in one good language and fleeting familiarity with the other six points is basically fine.
 
  • #28
I think some of the discussion here is people talking past each other. The original poster asked, essentially, what programming language should I concentrate on learning to maximize my ability to get a job right here, right now.

DH gave a list of useful things to learn as a graduate student, some of which aren't so marketable (fortran, latex,mathematica). And also- there is a difference between being a truly good programmer, and being a hire-able programmer. The first step for a physicist looking for a job is to become merely hire-able.

I think the best thing the original poster can do is figure out what type of work he/she wants to do, and learn the languages being used there first. If you want to do statistical data work, start with R. If you want to program iphone apps start with objective C. Pick one of python or perl and get good with it.

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.

I'm almost positive a good profiler/debugger would have found the same problems without a person having to get down into the assembly.
 
  • #29
ParticleGrl said:
I think some of the discussion here is people talking past each other. The original poster asked, essentially, what programming language should I concentrate on learning to maximize my ability to get a job right here, right now.

DH gave a list of useful things to learn as a graduate student, some of which aren't so marketable (fortran, latex,mathematica). And also- there is a difference between being a truly good programmer, and being a hire-able programmer. The first step for a physicist looking for a job is to become merely hire-able.

I think the best thing the original poster can do is figure out what type of work he/she wants to do, and learn the languages being used there first. If you want to do statistical data work, start with R. If you want to program iphone apps start with objective C. Pick one of python or perl and get good with it.



I'm almost positive a good profiler/debugger would have found the same problems without a person having to get down into the assembly.

I think I was looking for the words to say this, but gave up. Particularly that there is a difference between a hire-able programmer and a good programmer.

@OP: For the most part, all your first employer is likely to care about is how good you are at the one language you are expected to use. Search for job openings, and learn the languages that are asked for in jobs you want.

C++ and Java are perfectly good languages for hireability too.
 
  • #30
ParticleGrl said:
DH gave a list of useful things to learn as a graduate student, some of which aren't so marketable (fortran, latex,mathematica).
A physics graduate student, in particular. Those skills are essential side skills that many physics grad students need to acquire somewhere along the way to getting that PhD. Side skills, mind you. A physics grad student has ten or so hours a week, tops, to learn those side skills. The other 80 or more hours of a typical grad student's work week is split between jumping through the hoops that the student's PhD adviser keeps erecting, jumping through the hoops that the administration keeps erecting. Somewhere along the way the student also needs to do the research needed for the thesis.

Of course some of those skills are easy to obtain. They have to be. There's just not enough time.

I think the best thing the original poster can do is figure out what type of work he/she wants to do, and learn the languages being used there first.
Go back to the original post. The number one item: "Finance? Sure." In other words, a quant. That requires a good deal of numerical analysis and programming dexterity, and not just in one computer language. Good knowledge of multiple languages is a key skill. A quant's day might start with pulling data from a database (SQL), then performing some statistical analysis on it (R, or some Fortran-based statistics package), and then performing a principal component analysis (Fortran, or maybe python/numpy).

If you want to do statistical data work, start with R.
That's a good one to add to the list if the goal is to be a quant.

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.
I'm almost positive a good profiler/debugger would have found the same problems without a person having to get down into the assembly.
No, it wouldn't. How's a debugger going to help? Yes, you can make a debugger switch to executing the assembly code, but that's not going to be much help if you don't know assembly. Debuggers and profilers aren't all that good with optimized code. (Some debuggers can't even run on optimized code. They skip right over it.) The problem is that the as-built code and the as-written code no longer map to one another nicely once the code is optimized. A good optimizer will push part of a statement here, another part there. It might isolate expressions common to multiple statements. Which statement gets the blame in profiling?

A profiler did tell us that one particular function was hogging all the CPU time, and when compiled unoptimized, only a handful of lines were responsible. What the profiler didn't tell us was that the compiler wasn't doing a bang-up job when the code was compiled optimized. Looking at the assembly did. Only then was it obvious that common or invariant subexpressions were not recognized as such. The profiler didn't tell us that the standard int to double conversion is best avoided in a tight, multiply nested loop. How could it? It's not obvious to the human reading the as-written code, either. The conversion looked so benign, particularly since it was but one small part of a complex expression and since the conversion was implicit rather than shouted out via static_cast<double> (n).
 
  • #31
D H said:
Go back to the original post. The number one item: "Finance? Sure." In other words, a quant. That requires a good deal of numerical analysis and programming dexterity, and not just in one computer language. Good knowledge of multiple languages is a key skill. A quant's day might start with pulling data from a database (SQL), then performing some statistical analysis on it (R, or some Fortran-based statistics package), and then performing a principal component analysis (Fortran, or maybe python/numpy).

I'm not sure what your point here is. Is it that big of a jump to go from what I said, to the idea that if an employer is asking for knowledge of multiple programming languages, to learn those multiple programming languages? MY point is that employers tell you what they are looking for, because it saves everyone's (especially their) time when they do. So learn what they are looking for. Simple.
 
  • #32
D H said:
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.

That's an exellent sketch for a medium-distance road map; but I would nevertheless recommend C++ as the first language the OP should study given his C-affinity.

---

Fortran is a miracle in itself.
It's really simple and lightning fast at the same time.

BUT - I would not recommend that someone starts his way to software development with Fortran.
Fortran legacy code is often packed with bad habits that have survived from punch card time, which could be a job killer if picked up in a modern language - cryptic identifier, low comment density etc.

To write industry strength Fortran it needs an experienced developer, which transfers his good coding skills developed writing C,C++ or Java (or whatever modern language) to Fortran.

Also Fortran is not a general purpose language; it's a workhorse for numerics.

But given - likely still the best workhorse for that.

---

goingmeta said:
[...] assembly [...] I would say that's really poor advice. It's really not a marketable skill.

is that so...

In twenty years in the industry I've never met a good programmer who had not also had a liaison with an assembly dialect once in his career.

Let alone that I had ever been tempted to consider someone lacking that experience for a a job.

---

In addition, I'm quite surprised that many folks recommend python for beginners.

That's a very powerful, but also very complicated language; and from what get from a over a decade experience with that, one of the most often badly used as well.

Regards, Solkar
 
Last edited:
  • #33
Solkar said:
BUT - I would not recommend that someone starts his way to software development with Fortran.
Agreed, but this is not the typical "someone" I targeted with my list. My list is aimed at physics graduate students whose research involves computation and who want to make themselves marketable as a programmer / numerical analyst as a backup plan in case the climb up the academic ladder doesn't pan out. The same applies to meteorologists who have to deal with old Fortran weather simulations, and in a few other areas where Fortran still rules. In most areas Fortran is at best a niche language. Fortran still does rule in a small handful of highly numerical, highly intensive, and computationally large domains. Computational physics oftentimes is one of those domains.
 
  • #34
I don't think there was any attachment or commitment to finance just because he enumerated it in a list of options. Maybe you should pay attention to what's actually being asked instead of gratuitously telling us about what physics grad students have to go through.
 
  • #35
goingmeta said:
I don't think there was any attachment or commitment to finance just because he enumerated it in a list of options.
Sure there was.

Perhaps you aren't aware of this, but Wall Street and PhD physicists are: The very same numeric codes that describes what happens inside a star also can be used to describe what happens to a hedge fund. Wall Street has hired lots of physics PhD graduates to work as quants because of this.

Upsides: A six digit starting salary, sometimes with a non-unitary leading digit, and working at the very heart of the engine that drives our economy.

Downsides: Ridiculous work hours (no chance to spend that huge salary), living in New York City with its high cost of living (that huge salary isn't as big as it seems), and working at the very heart of one of the more despised industries in the country.
 
Last edited:

Similar threads

  • STEM Career Guidance
2
Replies
37
Views
6K
  • STEM Career Guidance
Replies
16
Views
3K
  • STEM Career Guidance
Replies
4
Views
1K
  • STEM Career Guidance
Replies
4
Views
1K
  • STEM Career Guidance
Replies
20
Views
1K
  • STEM Career Guidance
Replies
5
Views
849
  • STEM Career Guidance
Replies
2
Views
1K
  • STEM Career Guidance
Replies
3
Views
1K
  • STEM Career Guidance
Replies
27
Views
1K
  • STEM Career Guidance
Replies
30
Views
2K
Back
Top