And people managed to do just what you are describing procedurally for a couple of decades, it just takes a little more thought (something thats always a good practice in programming) about how you want to structure your code. See Stefano Toninel’s dissertation about using an object based approach for a CFD code.
You obviously didn’t get my point. The point is to build “software LEGO bricks” that you can combine into many different applications with minimal hassle. In the same way that kids use real LEGO bricks.
I think your argument is that OOP is not needed in the first place, or if it is, it should be used sparingly. Sure, but that’s a different argument, although I agree with it. @kkifonidis and I had a lot of discussions about that. The main point however is that since Fortran decided to add OOP, let’s figure out the right way. What I really like about @kkifonidis’ proposal is that it works with the existing language, just adds a few improvements that allow to use the interface-based OOP well. Which leads me to:
@kkifonidis’s proposal doesn’t break stuff, it’s purely additive. I agree with you that for production codes today, one can only use existing features, and that’s why it is crucially important to do a good job designing those features (compilers first, etc.) and design such features where languages and programmers are heading, not add features where it was already known at a time that this is not the way. Which leads me to:
The standard added some nice features, but the OOP I think felt short of staying relevant, and it should be improved. Yes, it would have been better to do it 20 years ago, so that it’s an existing feature today. But it’s still better to fix it today, so that it can be used robustly in 20 years (hopefully much sooner!), than give up and never fix it.
5 Likes
My argument is not that its not needed. It does have uses. My position is that its not needed to the extent that some folks advocate it is. Code reusability and maintenance (usually the two reasons most OOP advocates mention as to its superiority to other methods) is really more a matter of code design and organizations willing to enforce correct and proven coding standards and maintenance practices. Again, I just believe the areas where you gain a lot by using OOP are not as great as some OOP advocates maintain they are. One area where they do help is in defining material models for CFD and CSM. This is an area where there are clear “is-a” associations and using some inheritance can help with implementing a variety of (sometimes vastly different (think concrete and air)) models. Other than that (and a couple of others like maybe linear solvers), I prefer to limit OOP to what I call “command and control” functions. Ie, handling memory management, error control, IO functions and wrapping procedural functions (sometimes several decades old) with something that provides a more user friendly and less error prone interface. Repeating myself, I just think that trying to make OOP the end all and be all of a program (in some cases just so you can say you are using OOP as a marketing tool) is a mistake.
2 Likes
And that exactly is also what OOP is about in software engineering. You just add stuff that conforms to interfaces. You don’t change anything that already exists, and thus you don’t risk to break anything that already works.
1 Like
Oops is just syntactic sugar around procedure pointers. Therefore many patterns can be performed using pure procedure pointers. Of course I prefer them with sugar to decrease the possibility of shooting yourself in the foot.
Recently I was forced to work with 1980s codes (they keep me in the cellar and don’t let me out until i refactor). We are focusing here complaning how bad OOP is in our language. Yet this is a bit of a detail compared to codes where inputs and outputs are passed through common blocks, equivalence tricks make you totally confused what goes where and the control flow is non-local and unclear.
I was thinking recently for 10th in my life about what good code is. Good code is when you can make a modification to one functionality without needing to read the whole repository. If you are there, you can do very solid design even using purely procedural, without any OOP. If you are not there – there are much bigger issues to solve.
Why am I writing this? Because you see then these codes being “modernized” to Python or Julia, because “Fortran is technical debt”, but the code design is never changed, and same unmaintainability is propagated to the new code, simply swapping common for global.
THAT is real asbestos!
2 Likes
I think this is sort of the point I’ve really been trying to make. My views on OOP in Fortran were initially shaped by Ed Akin’s book and paper. Akins breaks OOP down into separate parts. Object-Oriented Analysis (OOA), Object-Oriented Design (OOD) and finally the actual programming using language features that support OOD (thats what most folks think of as OOP). Of the things that came out the Object Oriented movement, the two I think are the most important are OOA and OOD. They force you to think about how the various parts of your program will interact before you write a single line of code. As you say, how you implement them is just a function of whats most comfortable to you and more important what is supported in your chosen language. With respect to bad code, most of the really bad code I’ve seen in my life comes from academia or organizations that didn’t enforce rigid coding standards and practices. After you’ve tried to refactor enough old code, you can almost always identify code that was written by a graduate student or a post-doc as opposed to someone who had to conform to standards and peer review of your code before its accepted into the larger program.
1 Like
My son-in-law was contemplating a degree in computer science, I strongly recommend he take COBOL if it was available as he was guaranteed a job for the most part.
Imagine entering the field as a C++ or Java programmer, you would be competing with SO many other applicants.. then imagine actually trying to get a job as a COBOL programmer.. more than a few options but also few applicants to compete with.
Given my age I learned all the classical languages.. Fortran / Pascal / C / Lisp… but if I were a programmer looking for just “a job” I would seriously consider picking up COBOL.
The son-in-law is now becoming an electrical engineer… I still push for him to learn C, Fortran.. but he should also learn COBOL just in case he needs a job.
1 Like
I did not want to read this whole thread, I assume folks have seen the commercial on TV where the two technicians are watching the automated factory breaking down and the gal says. “We need someone who knows how to program Cobol” 
You mean this one.
3 Likes
Like many people I guess, I played a lot with Fortran OO features at some point. Then I realized that I was over-complicating my codes by doing so.
Now I have a light use of OO features within mostly procedural codes, and it works the best for me. If you ask me, I think that Fortran already went too far in the OO direction.
5 Likes