Best Programming Language for an Engineer

September 24, 2008 12:52 PM

What would be the best programming language for me to learn for use as a Water Resources Engineer?

I am a Water Resources Engineer, and I do a lot of modeling. In college, I took a class in which we used VB and a class in which we used Fortran. In grad school (masters) I used mostly matlab or just excel for problem solving. I am considering getting my PhD. and if I do, it is likely that I'll have to do a good bit of programming (Its very likely that I'll be writing some finite element method code). I am trying to determine which would be the best programming language for me to learn. I didn't really like VB or Fortran, and believe that they are both too limited. IF you have any question for me please ask. thanks.

posted by warriorengineer to computers & internet (11 comments total)

Sounds largely academic. That being the case, you will probably be using a lot of MATLAB. If there is a lot of finite element work, you will probably work with a package for that purpose (ALGOR, Ansys, CosmosWorks, . . . ). If you are doing a lot of experimental work, you may run in to your fair share of LabVIEW.
posted by milqman at 1:06 PM on September 24, 2008

It depends on the size of the calculations you intend to run. Matlab is perfectly suitable to do FEM stuff, and it comes with easy visualization and pre/post-processing tools. However, if you want to run very large (i.e. week-long CFD runs on hundreds of CPUs), you best bet would be Fortran (or maybe C++). Do you have more details on what you will be modeling exactly?
posted by swordfishtrombones at 1:09 PM on September 24, 2008

Well, C++ is everywhere, so if you don't know that, you should, especially if you're interested in something with a little higher performance than matlab. It really depends on the specific packages you're working with. If a library that you want to use is designed for use in a specific language, you're probably better off trying to use that language.
posted by demiurge at 1:12 PM on September 24, 2008 [1 favorite has favorites]

Let me first state that I failed to mention that I want something that will be practical for me to use at work also. Second, I'm looking for something that can be compiled and run stand alone, leaving MATLAB out.

As for what I would be using it with: a piece of software that is growing in popularity right now is the Army Corps of Engineers' ADH (Adaptive Hydraulics). It is software that creates a basic mesh for a rough bas run and then refines the mesh in areas where values fluctuate steeply across an element, again and again until things stabilize.

As far as what I wil be modeling. HOPEFULLY, it would be something along the lines of the flow of water and sediment ina river through a large river diversion into coastal wetlands.
posted by warriorengineer at 1:37 PM on September 24, 2008

Programming languages aren't specialized like that. What are you trying to do/build?
posted by wongcorgi at 4:53 PM on September 24, 2008

Python + numpy = standalone Matlab.
Get the Enthought distribution. Batteries really frickin' included.
posted by signal at 6:32 PM on September 24, 2008

Seconding signal's suggestion. See here for python learning materials.
posted by PueExMachina at 7:27 PM on September 24, 2008

The MATLAB Compiler allows you to generate stand alone programs with MATLAB. Not saying you should or shouldn't use it, but it's there.

I like python a lot though.
posted by markr at 11:16 PM on September 24, 2008

What makes Python so good?

wongcorgi, I will be building computer models to do CFD and visualization.
posted by warriorengineer at 8:03 AM on September 25, 2008

Wait a little while, and then grab onto Fortress when it comes out for reals.
posted by sandking at 9:51 AM on September 25, 2008

What makes Python so good?

• Easy to learn
• Powerful
• Tons of libraries
• Interactive mode
• Great community
• Really good free documentation
• Cross platform
• Fabulous 2d & 3d visualization
Plus, if you type "import this": The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

posted by signal at 12:44 PM on September 25, 2008