Coding is a buzzword, being able to write computer programs is a highly sought after skill and something that can come in very handy from time to time. There are many ways to write code that depend on a myriad of different constraints and requirements. There is undoubtedly an art to writing computer programs. Here I would like to share the philosophy and techniques that I have come to use and find useful over the many years I have been programming.

To start of, I'd like to talk about the types of programs usually found on 'modern-day' coputers. Some of the types of software you will know, some you may not have heard of, but all of them will most likely be prevalent on your machine (especially after you start programming). If you have not heard of them, that may be because they are normally hidden from the end user or because of a very limited usecase.

Types of software

Programming encompasses a large variety of tasks and environments that programming is done in. Programs are written for a variety of reasons and for manydifferent purposes. So here I would like to describe the different purposes programs are written for and how these programs differ in style and scope. Most importantly I'd like to give a rough guide that helps you in deciding what context you are in and what kind of requirements that translates into.

Some types of software are not often found on 'consumer' devices, as they require at least some 'expert' knowledge to get running. So you will for example not find scripts on many windows or mac computers. You can't really buy scripts as they are so low effort and limited in capabilities that it does not make sense to buy or sell.

The Application

An Application is a type of software that was popular during the time of the home computer but before the internet became wide spread. An application was and still is a program that combines fairly many related functions and is often used to aid the user in a specific task. Applications come with graphical user interfaces and many 'content creation' tools such as Adobe's PhotoShop or Microsofts Excel are stereotypical examples of Applications.

Applications are often written by many people that work as Team on various aspects of the Application. There may be a graphical designer that is in charge of how the application looks. They design the Icons, decide on the layout of the buttons and menues. Together with a technical writer, they might decide how to name the different menu options and write up help texts for the different buttons. Then together with a UX (or user experience) designer they would decide on and optimize typical 'workflows' to make them as intuitive to the eventual user as possible. Keep in mind that besides the user interface, there still are all of the technical aspects that need to be defined and implemented for the Application to work.

Applications are intended to be used by many thousands of people to spread out the often very high cost of creating them. They are therefore mostly commercial products and their prices range from a few Euros to thousands of Euros (for example for Engineering applications). Applications initially where designed to run on a single computer (the computer that the user was sitting in front of) and had only limited network dependent functions. Their spiritual successor, the App changes this significantly.

The 'App' and Networked programs

The 'App' started out as an application that was mostly target mobile devices. Because of the limited recources of early mobile phones they sometimes ended up being 'stripped down' versions of Applications on the desktop computer. There where email apps and applications that tried to replace paper organizers with a digital conterpart (PDAs). As mobile devices (smartphones) became ever more powerfull, the applications where able to extend their functionality to the point nowadays where they rarely lack behind their desktop counterpart. Apps coincided with the rise of the internet and ever expanding celular networks. This made it possible to do much of the actual computational work on a remote computer. This means that the actions that where triggered by the user where not actually performed on the users computer (or more likely their smartphone) but the command corressponding to that button press of the user was sent over the network to computers that where operated by the company that had built the app. This makes apps fundamentally different from 'classical applications, because they are only part of a 'distributed' program that is execudet by multile different networked computers. The 'App' that runs on a phone is therefore often nothing more than a user interface connected to a 'service' that provides the many different connected user interfaces (the other apps) with the funtionality that the user uses the app for.

A diffrerent story is the story of how these 'Apps' are monetized. Instead of charging the user a fee for the services provided (which of course can be the case) many companies have moved away from that approach to one that sells the user information to interested parties (mostly advertisers). Other approaches include integrating advertising into the user interface of the app or incenctivizing puchases 'inside' the app that mostly sell minor feature packages or let the user customize the appearence of the app.

The general rule for most monetization approaches is to keep the purchase amounts small and recurring. This tendency has led many apps to encourage usepatterns that have been shown to be addictive.

This trend has deeply transformed the way that programs are written and designed. Programs are no longer a single monolithic unit that runs on a single machine. Instead there are dozens or even hundreds of different programs that need to cooperate. The goal of these programs is no longer to help in a specific task or do a specific thing, but to become a service, like for example the telephone network, that is allways running in the background and used by many people (or even other computers) at the same time.

The script

The script is the program with the lowest barrier of entry. A script is a type of program that most often relies on a lot of other components (like interpreters and 'built-in' functionality along with so called libraries). Scripts are not used many times. They are usually executed maybe a few dozen times, after they have been fully 'developed'. Scripts often solve a single very specific problem, execute on a single machine and do not have a sophisticated user interface. Most of the time, they simply display some short sentences describing their progress. If an error occurrs they simply stop working and display the 'raw' error text that refers to the line number in the script where the error occured. The script is often only used by it's creator. Writing a script is similar to a blacksmith forging the tools to help them in their work.

Many tasks that involve data processing are script based. In scientific contexts there is often to much data to process it by hand, but as the data was gathered as a single chunck there is no continual data flow. Scripts are used in such cases becaus scripts keep the effort on the part of the programmer low, placing that burden on the user. This can be done in these contexts because it is assumed that the users will be fellow scientists that have the necessary knowledge to figure our solutions to many of the problems themselves.

This concludes the introduction. I hope you have been able to get a glimps of the different programs out there and their variety as well as their purposes. Next I'll try to guide through the different ways programs are normally executed.