My last degree is in Computational Engineering. To start out on acquiring such a credential at an age when most people are either thinking about their last job or retirement isn’t easy. That’s one reason why I never intended the STADYN program–the most important outcome of that effort from a research standpoint–to be the last word as much as a conversation starter to move pile dynamics forward. It wasn’t easy writing a three-dimensional wave equation program–forward and inverse–from the ground up, and I doubt that the ultimate outcome–wherever it comes from–will do it that way.
In the process I got caught in the “language wars” which dominate high speed computing. Which is better, Fortran or C? Or Python? Or something else? This can result in heated debate without enlightened discussion, as is the case with many more conventional topics in geotechnical engineering. There are passionate partisans on all sides.
The whole discussion was put in perspective by my PhD advisor and professor of the two finite element courses I took, Dr. James C. Newman III. One day in class he gave us one of his memorable monologues on the subject. His observation was simple: looked at in the long view, when it comes to programming languages, it’s always something different.
FORTRAN was the first scientific high-level programming language developed, and pretty much “ruled the roost” for many years. I think that the lack of change in the language (FORTRAN 77, for example, dominated with its fixed arrays from the late 1970’s to the early 1990’s) invited competition, and both C and its later version of C++ filled the void (sorry!) Fortran caught up somewhat with Fortran 90 and its later versions, but C++ was predominant in the program I was involved with. The C based languages were never intended for intensive high speed computation but improved compilers gave them an edge. Now we have Python and other languages competing for programmers attention.
Newman’s point, however, was simple: the language of choice changes over the years. By the time a new generation of programmers starts their education, there will be another one to take the place of the language(s) we’re arguing about today. The key is that the language or method being used gets the task done. But as for languages and computer methods, it’s always something different. So today’s desperate fight for superiority will be tomorrow’s quaint tempest in a teapot.
In reality, that’s the way it is with all technology. The technology–operating systems, applications, networking, all of it–we have now is “the latest and the greatest” but soon will be considered “legacy.” In spite of this obvious fact, some employers expect engineering schools to train their students in their pet application, and make a big deal out of that when given the chance. So what happens when that application gets left behind by something different? The now-practitioner either needs to learn something entirely new, get left behind, or perhaps be in a position where their legacy skills are still needed to maintain whatever installed base their employer needs to be kept up.
But that’s going to happen sooner or later to everyone, right? It has always been my idea that engineering schools need first and foremost to teach people how to think, which includes an understand of the basic physics of their field and how it is applied. Our calculation abilities and methods will change and the specific skills required will also change, but the core remains.
My first exposure to computers in engineering was FORTRAN programming. Programming of some kind was de rigeur for engineers and computer users alike for many years until packaged applications took the helm (which themselves were the product of programming.) Programming, from an educational standpoint, is a useful skill in that the student a) is forced to learn to think logically and think problems out and b) comes to realize how easy it is for computers to make mistakes, which is one of the chief lessons my PhD program strove to inculcate in its students.
That leads to the one application that virtually any engineer encounters: spreadsheets. I’ve used a wide variety of them over the years: Visi-Calc, Works, Excel, Quattro Pro, Star Office, Open Office, Libre Office, and Google Sheets. The problem with spreadsheets is that they’re really a better business tool than an engineering one. The strength of them is that they enable the user to program a wide variety of tasks and to present the results in a reasonable manner. But I never cease to be appalled at the lack of spreadsheet skills some of my students demonstrate, which is why I’ve made spreadsheet use central to my Fluid Mechanics Laboratory course.
For engineering education–or any education–to be successful, it needs to identify its basic goal and then pursue that goal in a focused manner. Putting too much emphasis on learning one software package or another will not accomplish that. Learning to properly use software applications is a skill students must acquire to survive (and one that the advent of the smart phone has unfortunately dulled.) But acquire they must, because for student, engineer and employer alike, sooner rather than later it will always be something different.
vulcanhammer.net 