Programming for Engineers!

In my Mechanical Eng. degree I'm currently taking an intro to Fortran class. From what I hear, Fortran is getting outdated though.

 

Matlab is a great program to master. It is very powerful and, after you learn its intricacies, relatively straight forward. Mathematica's Maple software is nice, but not necessary, it is a great tool for solving differential equations as well as multivariable ones; far more intuitive for those types of equations than matlab, but also not as powerful for higher complexity stuff and not really useful for iterations and systems analyses.

Any C language will be extremely useful if you will be programming, and with avionics you sure as heck will be. Become familiar with them all, master C++. Fortran is a great language from what I hear (I'm no programmer) but as you say it seems many industrial leaders are heading away from it.

Matlab and C++ have very similar structures. They differ in syntax, but if you can master the structure and logic of one, the other will come relatively easily.

 

I want to have a little rant about this and hope you don't go down the dark path so many have gone before.

If you want to write software that anybody else might use, or if anybody else might want to read/modify the source code, then you should look at software engineering too. UIs are also handy. VB makes that fairly easy.

These are things that I've noticed engineers tend to overlook. There's a lot of complete mess software around that does some fantastic calculations, but nobody has the time to understand how to use it or to untangle the spaghetti code inside it. Then when it has mysterious failures due to numerical instability or some obscure bug, it has to be thrown away and done again from scratch.

If you find yourself doing these things, you might be programming like an engineer:
- Using ii and jj as variable names
- Using goto
- Making a function with more than 5 parameters
- Using abbreviated function names like STG3B
- Storing numerical data in strings
- Inventing a file format with data stored in the same sequence it gets processed
- Inventing a new file format for every program, even if they should be used together
- Making tools to convert between those file formats
- Inventing abbreviated commands for the user to memorize
- Hardcoding constants
- Optimizing

I'm guilty of some of these myself. But they're still bad because they waste people's time.

 

Well expressed Unrest. Having been programming for engineering over the past 40 years all programming languages have evolved. A good example is Basic. It started with a version called DEC Basic with only 2 characters allowed for variable names, subroutines could only be called with a GOTO statement, ETC. Today visual basic is a powerful language. Fortran is still relavent if only because many engineering programs were developed using it and in the days of the IBM 1130 with Fortran one and two and limited menory (16K), Frotran had a unique command which was "call link" allowing programs of any size, if you could limit the items that had to be passed from on segment to the next. C from Bell Labs was good with a little different syntex but very capable. To be a good programmer a knowledge of assembly for the processor you are working with is helpful but not a necessary as it was in the early days of Intel's 8080, there was no math processor so it was necessary to program in assembly to add, subtract, multiply and devide. Now no one thinks about it. To make an engineering program usable the input and output format is most important to the user, as well as a way to verify the results is most important.

It really doesn't matter what language, more inportant is how transportable and the logical structure of the programs. If the program is for one time use it makes little difference but the results must be verified. Good luck and have fun!