In many fields of computer science we are progressively building upon the previous generation of toolsets. These incremental advancements, in many ways represent the corner stone of how we operate as engineers however, there seems to be controversy in what tools are used and how they are used. Some look to higher level and scripting languages such as python or javascript with disdain because they do not perform as well as other languages. The same can be said on the other side where engineers may view the counter side as clunky and tedious. Like everything else, there are specific use cases for each level of tools but how do we define what is right or wrong? Both are correct and both are incorrect.
Lets consider and embedded systems software engineer. Their language of choice is likely to be embedded C or the like however, they might view their language as the better language because it requires that the user have some deeper level knowledge of how electronics and by extension computers in general, work. But if we follow that logic, why not simply write in C and program everything by hand? We could take it even further and write in purely assembly language. I am fairly confident most developers (me included) would wince at the thought of writing in an assembly language and are comfortable leaving that to the few individuals that are interested. The embedded systems software engineer writes in embedded C because it is the correct tool for that use case. The chips that are used are not as powerful as say a phone a full computer so efficiency is necessary. There must be no waste in power or memory. On the other hand, embedded C is and extension to C with packages designed to aid in development in that particular field. This might be a contrived example, but what about the packages that are built on other packages. If we take that paradigm to an extreme, we might eventually arrive at a scripting language which allows users to perform certain tasks with very little effort based on a myriad of packages. Of course, the cost of creating such a tool is to build in flexibility and protections since that layer is abstracted away. However, that might be irrelevant since a second user might not need the efficiency and would prefer to focus their efforts are larger problems at hand.
Perhaps the issue then isn’t that the lower level knowledge is abstracted away, but the implementation of abstraction is done incorrectly in the eyes of some users. This is true in some regards yet with the introduction of languages such as cpython, golang, or even rust in the recent years that distinction might continually shrink until that argument is no longer valid. I believe that is the natural course of things. The higher level languages are relatively new and are in constant development whereas C has been around for over 50 years and has had time mature. Assembly languages are even older still and yet like C, has a thriving development culture because other newer tools depend on its success. I can foresee several decades from now, engineers might view higher level languages in the same way engineers view C now. Once they have matured and can fully utilize the path paved by the previous generation, we might see the advent of an even higher level of abstraction and those that use the previous generation of tools will complain that the new paradigm does not do what was done by their generation justice. Those die hard engineers will continue to improve upon their own craft and those that come after them will and by all means should take advantage of what they do to improve upon the new tools.
With that said, that higher level of abstraction might already have arrived in some ways. There are autocompletion softwares to help improve speed of typing, GitHub copilot which automates much of the boiler plate or skeleton code that is a necessity to developing software, and of course the now popular tool, chatgpt which can write entire sections of code given a specific prompt. While these tools still require the user to have some programming experience, they obviously provide and entirely new experience for software engineers. In addition, though clearly incomplete, they beget another question which might not be easy to answer. Let’s consider in the distant or for all we know near future when these programs have blossomed into what we would consider mature and fully fledged tools. If a “software engineer” were to use exclusively one of these tools to program, would you still consider the user a software engineer? Are they something else entirely? I don’t know. Partly because I don’t know what the tool might eventually become but also, I don’t know what people would consider a software engineer then. Cultures, definitions, and standard practices change to adapt to the current environment as they should. One of the tenets of software engineering is efficiency and the creative ability to solve a problem in the best way possible. Would that tenet still hold strong or would a different sort of creativity take precedence over what is the norm now?
Clearly the world of software engineering and computer science is changing and it is changing rapidly. The knowledge is no longer exclusive to a select few academics and the widespread application of this knowledges invites new and exciting ideas. It is a field of collaboration and building upon the ideas of the previous generation as with any other field but, it seems we are accelerating quickly and I’m unsure of what might happen in the future.
Leave a Reply