Physics Most Common Programming Language in Physics Career

AI Thread Summary
In a physics career, the most commonly used programming languages include Matlab, Python, Fortran, and C++, with Matlab being favored for data analysis and Python gaining popularity due to its cost-effectiveness and extensive libraries. Julia is emerging as a contender but faces challenges in displacing established languages. The choice of language often depends on the specific subfield and job requirements, with research positions typically favoring Matlab or Python, while simulation and modeling may lean towards Fortran or C++. Understanding programming concepts is more crucial than mastering a single language, as compatibility and project requirements dictate language selection. Ultimately, developing strong programming skills across multiple languages can provide a significant advantage in the physics job market.
Sheikhzaadi
Messages
10
Reaction score
4
HELLO ALL,

First off, my apologies if this topic is redundant, but I was wondering which programming language is widely applicable to a physics career. What positions in a Physics related career use what specific languages? What is one's best option if one is pursuing a research position versus someone who is looking at a simulation/modeling-specific job?Thank you for your time in advance.
 
Physics news on Phys.org
it depends. Where I worked it was Matlab with some folks using and tweaking Fortran modeling code or C++ modeling code but primarily Matlab for data analysis tasks. There were other groups who didn't like the high cost of Matlab subscriptions and decided on using Python with Jupyter notebooks for their work (ala the Anaconda Python distro)

Julia is now making strides into physics work too but they are fighting against a formidable foe in Matlab and its hard to get folks to change their habits and coding workflows.

Checkout some job descriptions of places where you'd like to work and see what they are looking for.

Personally, I think you should focus on Matlab and/or Python both good for data analysis and machine learning tasks followed by Fortran and C++ for certain modeling and lastly Julia for the future.
 
  • Like
Likes Astronuc, DeBangis21, Math100 and 2 others
It depends completely on what subfield we are discussing. I don’t think it would be healthy to generalize.
 
For someone doing research work, sorting and analyzing data
Orodruin said:
It depends completely on what subfield we are discussing. I don’t think it would be healthy to generalize.
Say someone doing research work, sorting and analyzing data geared toward their research. What language would be best?
 
Sheikhzaadi said:
Say someone doing research work, sorting and analyzing data geared toward their research. What language would be best?
What programming languages have you used so far? What kinds of programming projects have you done so far?
 
I have always felt that it is better to learn how to program rather than being able to cobble something together in one particular language.
 
There’s no best programming language. Programmers choose or use the language that best fits the project. If you are working on a web project and much of it is in Java then you use Java. If it’s a machine learning project and most work is in Julia then you use Julia. if it’s python project then you use python.

you need to worry about compatibility issues and using the same project language eliminates these kinds of issues.

When I write tool scripts for project maintenance I’ll use python. While slower than using C its arguably more readable and likely less lines of code.
 
jedishrfu said:
There’s no best programming language.
FORTRAN!
 
jedishrfu said:
While slower than using C its arguably more readable
<cough, cough>

jedishrfu said:
likely less lines of code
Fewer lines. "less" is a float, "fewer" is an int. <evil grin>

Stupid grammar niggles and jumping on you for a typo aside, there is more value in understanding the difference between an integer and a floating point number than knowing whether it's an INTEGER, an int, a short, an i16, etc. Understanding concepts is more important than just understanding syntax.
 
  • #10
berkeman said:
What programming languages have you used so far? What kinds of programming projects have you done so far?
I haven't done any projects. I have some experience with C ++ and am self-learning python. Just trying to gain some edge to land a physics career-related job.
 
  • #11
In FORTRAN using implicit rules fewer would be a REAL and less would be an INTEGER ie variables starting with the letter I thru N are implicitly INTEGER unless explicitly defined otherwise and variables starting with any letter other than I thru N would be considered REAL.
 
  • Like
  • Haha
Likes hutchphd and Vanadium 50
  • #12
After learning the language, you to branch out and find uses for your skill. You could consider writing different types of games or doing some numerical simulations. Things that would get you to explore third party libraries commonly used with the language.

Some python devs use Anaconda Python which ships with Numpy, Scipy, Pandas and other cool libraries. Anaconda provides the means to do data analysis, machine learning and numerical simulations with these libraries.

when you get to that level, you can feel confident that you understand the language.
 
  • #13
Sheikhzaadi said:
Just trying to gain some edge to land a physics career-related job.
The problem is that if you spend a little time at it, you will only gain a little edge.

If you want a serious edge, you need to program noticeably better than your peers. That doesn't happen overnight, and learning the syntax of one language won't quite do it.
 
  • #14
jedishrfu said:
In FORTRAN using implicit rules fewer would be a REAL and less would be an INTEGER ie variables starting with the letter I thru N are implicitly INTEGER
The above isn't relevant to V50's niggle about the grammatical use of fewer vs. less, which is the difference between discrete amounts vs. continuous amounts. E.g., the difference between "less sugar and fewer calories." It wasn't about the somewhat arbitrary division of alphabetic letters used for the first letters of Fortran variables.
 
  • #15
Mark44 said:
The above isn't relevant to V50's niggle about the grammatical use of fewer vs. less, which is the difference between discrete amounts vs. continuous amounts. E.g., the difference between "less sugar and fewer calories." It wasn't about the somewhat arbitrary division of alphabetic letters used for the first letters of Fortran variables.

My apologies. I didn't understand @Vanadium 50 ‘s comment. As I reread it, I can see I was sloppy with my English use of less. English was never my strong point in school.

In the context of programming, we often use the less than operator with integer values so one argue while its a poor choice, the meaning is understandable here.
 
Last edited:
  • #16
Mark44 said:
less sugar and fewer calories
I'd argue calories are discrete too. "Fewer raisins" would be something I would call discrete. (The line can be blurry - "half a bottle of beer".)

My real point, not just the fun-poking, is that it is more important to understand variable typing than how any particular language does it. We have a whole thread going on right now in another section because people don't understand how floating point variables work.
 
  • #17
I didn't see that thread did I?

But yes floating point can be obscured by folks using integers in a fixed point manner making it even more confusing as in keeping money values in pennies and dividing by 100 for dollars.
 
  • #18
jedishrfu said:
In the context of programming, we often use the less than operator with integer values
... because there is no "fewer than" operator.
 
  • #19
Vanadium 50 said:
I'd argue calories are discrete too.
Calories (in the context of food) are almost always given in integral values, so "fewer" is appropriate while "less" is not. Recall the old ad (for some brand of beer, I think) -- "Blatz Lite has less calories."
 
  • #20
Mark44 said:
"Blatz Lite has less calories."
Looks like there is mix of use when it comes to beer... LOL

1669665396036.png
 
  • #22
To my ear only "fewer" works for the enumerable and only "less" works for continuous stuff.
But "more" works for either! Is this so? Seems strange..
 
  • #23
Yeah, but some dictionaries say you can use "infer" and "imply" interchangably too. (inside Mentor joke)

But, @hutchphd that's how it goes in most cases. Less emphasizes quantity, and fewer emphasizes number. It is similar to int and float in C or Integer and Real in Pascal. There are some rare exceptions - long or long long ints sometimes take less.

One are where clarity is usually needed and often missing is the difference between an enum and an integer. Part of the reason is that lots oflanguages don't have good enums, and part pf the reason is that integers usually do everything an enum can do and more. But you really don't want that: x = Sunday*Thursday - Monday should throw an error. If someone codes that, they probably didn't mean it.

This is why I think it's important to learn how to program, rather than only being able to cobble something together in one's favorite language. It helps one spot errors and things that were unintended. As I said on the other thread, the plausible but wrong answer is dangerous.
 
  • Like
Likes Mark44 and hutchphd
  • #24
Mark44 said:
Calories (in the context of food) are almost always given in integral values, so "fewer" is appropriate while "less" is not. Recall the old ad (for some brand of beer, I think) -- "Blatz Lite has less calories."
That’s the difference between advertising and science, right there. Anyhow, not to put too fine a point on the whole business, both fewer than and less than are Boolean valued operators which any sensible language design should both be applicable to floats, into, scalars, or cardinals, accommodating mixed operand types where possible.Your fave language may vary, too bad.
 
Back
Top