In movies, programmers often get depicted as keyboard ninjas. Frantically tapping away at their keyboards, backs arched, leaning into the screen, almost fully immersed in it, ideas seem to flow seamlessly. This is simply not the case in reality. Although I type rather quickly, most of my programming involves a lot of reading. Reading my own code, reading documentation, reading textbooks, copy and pasting errors into Google Search and reading through the solutions on Stack Overflow. So programming mostly involves looking at a screen with a blank expression on ones face trying to figure out the location of bugs.
It’s currently summer and warmer weather means mosquitoes, flies and all manner of other creepy crawly bugs. I will need to stock up on my insect repellent to dissuade the ones who become too invasive and although I’d much rather be sipping an ice cold drink on the beach, I will have to do the same to my code.
The term bug in programming was popularised during the time when computers used to fill rooms and naturally their components were huge. So much so that when an error was found in one of the programs and was investigated, an actual bug was found in the computer. This was documented and the actual bug was stuck to the paper.
Whenever your program has a problem, we say that it is buggy. And if you want to rid your program from these bugs, then you debug. This used to mean combing through lines of code to find a missing semicolon, which in a cascading mess broke everything else and your computer shouted at you and you wondered why oh why did you ever choose to become a programmer.
When I first started programming in C (an older language which most modern languages like Python are built on top of), I had many frustrations with missing semicolons. Despite this I fell in love with programming and only gave it up because I didn’t have a computer at the time. C is a very strict and hard to learn language but it gives you direct access to the computer’s memory which can be a good and a bad thing simultaneously.
Luckily, things are much simpler these days. Most modern IDE’s (Integrated Development Environments) come with built in debuggers that catch things like missing semicolons and other syntactical errors. What is harder for these debuggers to pick up though, is logical errors. This is because the semantics of a programming language is harder for a computer to interpret.
This is where the rubber duck comes in. Often beginner programmers are encouraged to explain their code to someone else so that the ideas therein seems less abstract. It is often during the explanation that one finds the solution to the problem. Because finding someone else to explain your program to may be a feat in its own right, programmers have taken to explaining their code to more receptive audiences. Inanimate objects, like rubber ducks for example are extremely attentive listeners. So much so that when it’s their time to talk they instead listen all the more.
This is perfectly okay because their presence alone aids the programmer in debugging and feedback from them is entirely optional. The novice programmer thus learns an important lesson. Explaining something to someone (or something) else requires that you understand what it is you are talking about. It also forces you to look at your explanation from a different point of view because the person you are explaining to may not be a programmer. It is in this breaking down of the problem that we inevitably find the solution and with it the ecstatic AHA moment which makes all the pondering over a computer so deliciously satisfying.
It is perhaps this satisfaction that led one of my professors to exclaim that “Programming is the most fun you can have with your clothes on…”
I concur 🙂
Documentation in software development is like a user’s manual for a programming language, library, framework, etc. It gives you details about how to use elements of the language, library or framework.
Errors created when writing code. These can be syntactical or semantic.
I recently found that you can have bugs in UI (user interface) design as well. So perhaps there are many more places where bugs can be found of which I am not aware at present.
In C and some other languages, a semicolon is often used to terminate a statement. This is mainly because the full stop is often used as something else (dot operator).
Integrated Development Environment
An integrated development environment (IDE) is an application which assists software developers to write programs.
The syntax of a language defines which strings of characters and symbols are well formed.
The static semantics defines which syntactically valid strings have a meaning.
The semantics of a language associates a meaning with each syntactically correct string of symbols that has no static semantic errors. In natural languages, the semantics of a sentence can be ambiguous.
The last two definitions are taking directly from my “Introduction to Computation and Programming Using Python – MIT Press 2013” textbook.
Where am I with my app
I am currently doing an amazing course on iOS development from Udemy which I always wanted to do but couldn’t afford. The course was on sale on Cyber Monday (which is the Monday after Black Friday). This course is teaching me many amazing things like connecting to the web for dynamic syncing of changes made on my app or the linked databases. For those interested you can find all the code for the app on GitHub at https://github.com/mojo35/ChemCount
Title: The First “Computer Bug”
Description: The First Computer Bug Moth found trapped between points at Relay # 70, Panel F, of the Mark II Aiken Relay Calculator while it was being tested at Harvard University, 9 September 1945. The operators affixed the moth to the computer log, with the entry: First actual case of bug being found. They put out the word that they had debugged the machine, thus introducing the term debugging a computer program. In 1988, the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia. Courtesy of the Naval Surface Warfare Center, Dahlgren, VA., 1988. U.S. Naval History and Heritage Command Photograph.
Catalog #: NH 96566-KN
Thanks for reading 😀