terça-feira, 1 de agosto de 2023

Technology's Language Problem

Let’s be honest. Technology has a language problem. Since we lack the words to describe our excitement about original ideas, we do the next best thing (according to ourselves): we borrow words from other areas. We have been doing this ever since the first Software Engineer graduated. We continued to borrow names when we began to describe our architecture for software, data, processes, and everything else we want to give the impression we know how to piece together in a logical, reproducible way. Once again, when we called algorithms intelligent, despite not knowing how to define intelligence ourselves.

Overloading words with new definitions and uses has been a constant in our evolution as humans, and we have been doing it for ages. We began doing it to reduce the trouble of having to explain everything from scratch. Because of this, we have words like “muscle”, in English, that came from “small mouse” in Latin. Apparently, someone thought some of these structures resembled mice and the name stuck. Eventually, Latin died out, but muscle remains not only a noun, but also as a stand-in for force. The disclaimer here is that this example is valid for our, so called, Western world, historically influenced by Rome. For other languages, these examples don’t hold, but I guess there are parallels.

Borrowing words from other areas is not bad practice, in principle. It allows us to quickly show a rough overview of what is intended and also provide catchy titles for media outlets. We began with “expert” systems. Software developed to emulate a human’s decision process for business needs. These systems began to be developed in the 1950s and by 1960, LISP was the dominant programming language in America, with PROLOG being favoured by European developers. By the end of that decade, we already had medical diagnosis “expert” systems developed to assist doctors in their work. By the 1980s, expert systems were used by most large companies in their daily business decisions. We still use them today when interacting with a loan application or an investment decision. Stock exchange robots make million-dollar decisions in automated trading in less time than it would take a human trader to blink an eye. All this development was the result of transferring the decision processes of a human specialist to computer code.

Because the world evolves, these systems have to be maintained and updated. Their knowledge base evolves through the inclusion and removal of decision parameters. Despite being fast, the knowledge contained in the software is static. It requires maintenance to evolve. To overcome the costs of maintenance, we began developing algorithms that would keep the knowledge base current, extracting patterns from existing data without the need for reprogramming. These were the new “intelligent” systems that were able to “learn” from existing data. Or at least, that is how we explained it to the public.

We now have computer systems that find patterns in data by themselves and make decisions based on these patterns. We call the process “machine learning” and happily label the systems as possessing “artificial intelligence”.

These expressions allow us to avoid explaining how the data mining algorithms classify and tag information. They also hide complexity from view behind expressions we know. Overloading these expressions with new definitions, however, prevents us from understanding what is really happening in the code, leading to the perception that we do not know how the systems reach a specific conclusion. Images of evil, or alien, intelligence making decisions that affect the lives of millions creep into media feeds and apprehension grows. I believe this all happens because, once more, of borrowed and misused words.

Since we are talking about the interaction of algorithms in computer code, we do know how the system reaches an output. We may not be able to reproduce the exact steps since most of what happens is in the realm of probabilities, but we do know how. The problem is that we tend to use “how” for “why”, and “why” is a question for which the developers may not have an acceptable answer.