How the story has changed for programmers. The jump from those punched out to the modern programming environments used today is staggering, and in fact many veteran programmers probably remember those magical times? in which the spaghetti code, the code that shouted at us in capital letters or the presence of line numbers as an indivisible part of a program were normal.
Many of those elements have disappeared or have evolved to become a memory of a time that undoubtedly marked a before and after in programming and that today those programmers (and non-programmers) will surely remember with a little nostalgia.
Don’t yell at me, I don’t see you
The case of the capitals was something curious. In assembly language its use was very common, although the convention was to capitalize variable names and use lowercase letters for instructions. The normal thing was to have variables limited in length, which also forced the use of acronyms that made the reading of that devilish language even more characteristic.
Many other languages continued to be used almost exclusively with capital letters, and that made this a hallmark for many of them. FLOW-MATIC, the language with which programmers were finally able to program “in English,” that is, with a language that was approaching natural language for the first time.
The case of FORTRAN is also very special: in that language there was some freedom to use lower case in some keywords, but it was not normal. Suddenly FORTRAN was renamed Fortran, and its compiler became a much more liberal compiler that didn’t care if one worked in upper or lower case. Still, the social conventions of the programmers were re-imposing: the normal thing was to use lower case for local variables and upper case for native terms of the language, much more important and therefore it was necessary to “say screaming”, of course.
COBOL, as a natural successor to FLOW-MATIC, was also dominated by screaming: everything was capitalized … except for comments, something the developers’ own conventions recommended.
And then there was, of course, BASIC. Many of you who read us will surely do your little things in BASIC, a language with a very bad reputation in many sections but that was undoubtedly very important in attracting the interest of children who would later dedicate themselves to computing. Although later versions made use of uppercase and lowercase letters, the use of these was common for several years
The limitations of 6 bits and the debate on case sensitive languages
Part of the blame for that obsession with capital letters was with the 6-bit character codes, which could only encode 64 different characters and therefore “settled” for including capital letters, numbers, some punctuation characters, and occasions control characters. These codes were especially extended thanks to the first IBM computers and mainframes, which used them in several of its first machines.
There is also one of those polarizing debates between developers and programmers: that of case sensitive languages and those that are not. Jeff Atwood, co-creator of Stack Overflow, already explained years ago how this has become a “religious issue” and how the arguments for and against are notable.
For Atwood, though, case-sensitive languages ended up being enemies of productivity, and here he cited the example given by another well-known programmer, Scott Hanselman, who recounted how he had spent an hour debugging a problem in case-sensitive code and he had realized after that time that the error was that “SignOn” was not the same as “Signon”.
The GOTOs and the spaghetti code
Another of the curses that some of the first programming languages imposed was the one that was baptized as spaghetti code (‘spaghetti code’). The reason, its lack of programming rules, the complexity of its flow control, and that analogy with that bunch of intricate, knotted threads that make up spaghetti.
If there was a clear architect of this type of code, it was the GOTO statement that was used in a large number of programming languages - with BASIC as one of its referents – and that for many made any code that used it unmanageable and difficult to maintain. .
These languages also used to make use of the numbering of the lines of code (again BASIC as promoter of these mechanics) that were an obligation since the operating systems of yesteryear did not have interactive text editors, and the editors worked precisely based on that. numbering to be able to refer to a certain line when editing it or insert something between one and the other.
Unstructured languages such as Fortran or BASIC made this type of mechanism, and were the trigger for the need for the appearance of structured programming that sought to improve the clarity, quality and development time of any program.
From there we go to other philosophies such as object-oriented programming that, by the way, saw its own evolution of the spaghetti code and had the so-called ravioli code: the code had well-structured classes that were easy to understand in isolation, but difficult to understand as a whole.
Nice game, nice code
Programmers have learned a lot from that time, and programming languages have long tried to offer all sorts of aids to make programming take less time and produce clearer code to study and analyze.
Not only that: the work of programming itself is seasoned with elements that help achieve that goal and produce beautiful or, rather, clean code.
Among these aids, indentation or indentation of the code stands out, which allows moving text blocks to the right to separate them from the left margin and better distinguish it from the adjacent code.
This technique is part of the so-called secondary notation techniques that are designed to improve code readability. The highlighting of the syntax with colors is another common way of offering this improvement that, of course, also introduces redundant information.
The use of comments in the code – which goes back a long way, and in BASIC was present with those famous “REM” – is also another important element for many developers, and they are usually very useful to be able to analyze the code afterwards, although for many they introduce the danger of abusing them. Without a doubt, many aids that have evolved and changed the way of working of programmers.