#hardcore programming

In the decades to come, we will more and more see that the complexities of the libraries of ready-made program modules, embedded in much of commercial computing, is likely to reach such levels as to make it even far harder for a single programmer to get any real sense of overview over what is going on in the computer or computers. And because of the economical pressures, and intensity of computing in the world, there will be a large quantity of programmers whose main concern is to put parameters into these existing modules. They won’t have much time to do programming in the sense of creating real new code and do so in a context where they have a fair overview over, and insight into, the entire library of modules invoved.

  So we might as well distinguish between the two activities. One concerns a surfing, we might say, upon existing programs, so as to put together a little bit new stuff that is more than anything a ‘soft’ touching of existing libraries. This we can call Softcore Programming.

  Then there is programming where, perhaps to stimulate thinking, or perhaps because it is useful, or have a role in an academic writing process, no more libraries are used than absolutely necessary, and what is used, is pretty well understood. The CPU is almost ‘touched’ in this programming process. It may relate to bits directly, and avoid fancy menues, and overdone call on prebuilt editing tools and so on. It is hard core. We can call it Hardcore Programming.