Skip to content

Tools and how they corrupt the mind. Programming languages, thinking, and doing

Keep in mind that it is the craftsman and not the tools that solve problems and create solutions and that tools are the product of craftsman, too. Tools not only enable and facilitate, they also communicate. They are one craftsman sharing ideas with another. How you can do something influences how you think about doing things and that is the corruption of the mind in a process called learning. 

FORTRAN. Formula Translation, was a first step out of machine programming by twiddling bits in registers. The programming language made it easier for mathematicians to tackle the process of solving an algebraic problem with a computer. Much like the bit twiddling was simply a concrete expression of Boolean algebra, FORTRAN was a standard mathematical process with some glue and grease to be able to ‘read’ input data and present results. Know algebra and you pretty much had computer programming handled. This has been true for most mainstream programming over the years with a few oddballs thrown in now and then by revolutionaries (think Lisp or SmallTalk).

The fact was that differences were mostly glue and grease. FORTRAN, BASIC, C, Pascal, and even Assembly with macros all worked in pretty much the same way. Abstractions were limited and the program was all built on expressions of algebraic nature without much nuance. The first evolutionary step was in the bundling. This is where macros and libraries come in. Further down this line was the concept of inheritance and object oriented programming. That led to Java, C++ and others that implemented these ideas in program syntax but, still, these languages didn’t really need much mental corruption to understand and use.

Another evolutionary path was that of the mathematical purists. That can be seen on the war on the ‘Go To’ command and the development of control structures that hid the jumping around in loops or decisions. Another outcome of that is called functional programming where called procedures operate in a carefully delineated manner to assure data cleanliness. Forth might be considered as a purist approach to a stack based algebra, too.

Python is an example of trying to implement many concepts and ideas learned between 1950 and 1990 without straying too far from the basic algebraic language. It has done rather better than many other similar efforts and that may be due to supporting the old style while still accommodating new ideas in a way that appealed to enough of the right sort of people to build a community and a wealth of resources. Python supports object oriented structures, but you don’t have to use them. It supports functional programming but you don’t have to use that, either. It supports several abstract methods of bundling that simplify expression but boggle the mind and you don’t have to use them. 

A lot of this is what is called “syntactic sugar.” That’s easy to learn. When functional capability starts to meld with this syntax, the paradigm changes and that is more difficult. Finding out what has been bundled for easy access to previous work is even more difficult but this can be done with a bit of research. Assembling the bits and pieces can be a real challenge which you can see if you look at the make file for a significant project or at all of the options supported by a modern compiler.

So, as always, the choice of tool boils down to what do you want to do. Do you want to learn or to teach or to illustrate or to document? What’s the target platform? What are the limitations and constraints imposed by the platform, your resources, and needs? Do you want a public or a private solution? 

Now its time to dig in and get something done. That’s the best way to figure out what to do next.