Is object oriented programming unnecessary for scientific applications?

[Simfish]

After all, fortran isn't object oriented and it's used a lot by scientists.

And a lot of scientists also use C, which isn't object oriented either.

So someone told me that the four languages to know (for theoretical biology) are C, Java, Perl, and Python.

 

[CRGreathouse]

Being object oriented, arguably, makes larger programs more manageable. So if your concern is making a very complex program, being OO is good. If your concern is making a program run quickly, then you don't want the intermediate/bytecode layer of Java & friends and don't need the object-oriented features.

I write 'scientific' programs in both object oriented languages (mainly C++ and C#) as well as non-OO languages like Forth and C.

 

[D H]

After all, fortran isn't object oriented and it's used a lot by scientists. And a lot of scientists also use C, which isn't object oriented either.

Personal opinion, based on years of observation, interaction, and reading some incredibly hideous code: Scientists (excluding computer scientists, of course) are some of the *worst* programmers on the face of the planet. They are even worse than engineers (excluding software engineers, of course). Scientists are trying to solve a problem. The quality of the code and the sophistication of the techniques used to write the code are of tertiary importance. Engineers tend to write garbage code as well, but they can be educated by relating software engineering principles to basic engineering principles. Scientists' programming knowledge is often limited to numerical analysis techniques. An upper level undergraduate computer science major is likely to be more informed regarding software techniques than is a scientist who occasionally writes a program to perform some numerical analysis. Scientists continue to use Fortran and C because that is what they learned as a graduate student. Learn a new language? Why bother?

Scientists (more precisely, scientist's indentured workers (aka graduate students)) write code to solve a problem. Ofttimes this is throwaway code. Write once, run once, use the results in a paper, done. In their defense, why should scientists care about the quality, maintainability, readability, portability, etc of this throwaway code? A silly mantra of the 80s/90s was "quality is free". It is not free. The payback occurs with reuse. If the code will truly never be used, why bother to make it generic? The problem is that more often than not the code is not throwaway code. The techniques applied to solve one problem can help in solving the next problem.

So far I have addressed choice of language and 'ilities' but not object-oriented techniques. Programmers use object-oriented techniques in part because the orientation on objects is natural for many of the problem domains they are asked to attack. The algorithms are simple, but interactions can be anything but simple. The situation is often reversed in scientific programming. The algorithms can be hideous while interactions can be trivial. All that object-oriented techniques do in such a regime is get in the way.

It is still worthwhile to learn object-oriented techniques. There will be times when you find them to be incredibly useful, even in the domain of scientific programming.

 

[D H]

Forth

Is that still in use (other than postscript, of course)? I view the invention of Forth as the one of the worst mistakes made by computer scientists, ever. This includes JCL and APL.

Maybe not APL.

 

[CRGreathouse]

Is that still in use (other than postscript, of course)?

No. It's really, truly, completely dead.

But it can be fun to write in sometimes; it's like assembly language with training wheels.

 

[D H]

APL is another dead language much beloved by scientists. APL is an example of why scientists should be kept away from keyboards. This is particularly so with APL because APL users need to remap the keyboard.

A fun object-oriented programming exercise: write an APL object so that one could generate a list of primes p up to some integer N via the simple statement

p = r=drop(iota(1,N)), r.in(r.outer(r)).not() / r;

Not quite as elegant as (∼R∈R∘.×R)/R←1↓⍳N , but the use of the C/C++ comma operator and overloading / to mean select helps make things almost as clear as the APL original.

 

[rcgldr]

It depends on the actual application. In the case of Fortran, you have a couple of issues. One is a huge library of Fortran routines, some of which are huge, mathematically complicated, and known to be "bug free", for many specific applications. The huge number of libraries represent the "reusable" code for Fortran. The second issue is that Fortran is often the most optimized compiler available for some super-computers (Cray series for example), partly because of the acceptance of proprietary extensions to Fortan to take advantage of machine specific implementations, such as vectors on vector oriented super computers (although Cray seems to be the last maker of vector type machines).

Take a typical scientific application like the sensing of air velocity and pressure upon an object in a wind tunnel, and doing some lift, drag, temperature, and related calculations. There are hundreds or thousands of sensors on the object, and most of this task isn't too complicated other than the fact that a lot of parallel but independent processes occur at the same time and at a high sampling rate, which is ideal for usage of super computers. The code is rather straight forward, and I don't see any advantage to making such code object oriented, as the objects in this case (the sensor data) are too simple to warrant encapsulation and other common object oriented programming methods.

Every language has it's purpose. I'd hate to try and code the equivalent of Cobol's "move corresponding" (moves and formats elements from one structure to another structure, using another structure for the formatting desciption, based on having identical element names in the different structures), in another language.

There are good cases for object oriented programming as well though, usually when there are widely used structures in an application. In the case of Windows, there's a huge object oriented library for it's GUI interface. The standard template "library" for C++ is another example, although it's not really a library but actual source code that is included with the programmers code. Several C++ compilers offer the standard template "library".

I've seen a few applications where C++ is used for the user interface part of an application, while standard C code is used for the internal part of the same application. This was fairly common in the 1990's, I'm not sure if it's still that typical today.

I did use APL in the 1970's, but mostly as a glorified calculator, although I did do some more complicated stuff with it like writing a few programs to solve puzzles like this one.

http://en.wikipedia.org/wiki/Zebra_Puzzle

The method I used was to create a 6 dimensional "tensor" for the 6 qualities: (house order (left to right), house color, nationality, drink, smoke, pet), with 5 elements in each dimention. This "tensor" starts off with all elements set to 1, then the puzzle statements are tranlated into APL statements that clear the 1's to 0's based on inequalities (equalites translate into a set of inequalites). After inputing the statement facts, some possiblities would be eliminated, for example, if a Spaniard drinks coffee, than no one else can drink coffee and vice versa, the only true "deductive" logic in the program. I then added code manually to handle the "next to" cases instead of trying to solve them generically. Trying to implement this in another language would have taken much longer than it did with APL.

Most of my currenty programming is embedded firmware, and the only sophisticated stuff I do is ECC, compression, and multi-tasking type stuff. I don't do a lot of math programming, but for my coworkers that do, it's clear that MatLab is the way to go, although it's very expensive for non-students.

 

[Hurkyl]

After all, fortran isn't object oriented and it's used a lot by scientists.

That simply means that fortran doesn't offer many syntactic tools to support object oriented programming -- a programmer can still write object oriented code in fortran. (And non object oriented code in C++)

 

[-Job-]

Unrelated - Microsoft is introducing F# (a functional programming language) to .NET.

 

[CRGreathouse]

(And non object oriented code in C++)

(Raises hand) Guilty. Probably less than 25% of the C++ code I write is OO.

 

[minger]

I work in CFD using Fortran 90/95. We write everything object oriented to keep the code as "safe" as possible.

Plus its very advantageous to have objects/classes that can used for other purposes and not changed to be useful.

 

[jim mcnamara]

I have a lot of C libraries that I've gathered/coded over the years. All have been QA'd and have been in production for 15+ years - exactly what you want to use if you have them.

C++ provides these painlessly and they work beautifully. So either spend years finding what you need if you want to stop blowing your feet off during runtime, or use an already-to-go OO compiler. And learn sane coding. The actual language is less important, except as already noted - some languages are much better for certain tasks.

The alternative - seat of the pants cowboy code - does not fly. I've spent years fixing that cr*p and wishing I could find a way to get even.