In the old days when there were just computers and no ‘devices’ you would code something like this,
form.Height = 300
form.Width = 300
and there you were. Your program had a nice square form (window) 300 by 300 pixels. If this was a Windows program, you were programming for the Windows system on a Windows PC. A pixel was a dot on the video display and a line 300 pixels long was 300 dots long.
Those were the days, not necessarily better, but simpler. Today, screen resolutions differ widely as do the devices they run on. The code above (bearing in mind ‘300’ equates to ‘300 dots’) is in itself quite inadequate. The thing is, 300×300 is clearly intended to mark out a region of the screen and, when a pixel was a pixel, 300 dots did the job. But nowadays there are dots and there are dots. More and more dots are being crammed into the modern screen. This is Hi-Res (or some such term as ‘retina’ in Applespeak). You want to say, ‘this screen should take up this amount of space’, but you can no longer specify the number of dots.
On Android, for example, the problem is solved via ‘virtual’ pixels. These allow you to indeed specify a 300×300 screen, but behind the scenes, the giants are calculating how many dots there will be in that 300 amount.
I came across this pixel-issue recently when I used WinForms to write a quick utility program. (WinForms is a now-old Microsoft technology for building UI screens.) I hadn’t used WinForms in a long long time, as all my home projects use WPF (Windows Presentation Foundation, pretentious moi? and WPF is supposed to have been the new replacement for WinForms for over a decade now). WinForms does things the old way, where screens and their text boxes and checkboxes and buttons have a fixed size specified in pixels. WPF is more modern and flexible and generally less pixel-centric. WinForms is designed for programming on a PC running the Windows system and how refreshing it was in terms of knocking out a quick app. Here you have — you really do — a WYSIWYG design system. You create a form (screen, window) and it looks just how you designed it when you run your program! You see what you design! Except I didn’t, for all of a sudden the screen would shrink when I clicked on it.
Times and screens have changed since I last used WinForms. The assumption of a generic PC running on Windows no longer holds. It’s the pixels, of course. Some screens are more blessed with pixels than others. The WinForms team have implemented a fix for it, rather hacky and inelegant I felt. The fix was also what was making my screen shrink. It was ‘compensating’ for — well, what I am not exactly sure in my case, as I don’t have either a new or a Hi-Res monitor. As is so often the case in modern computing, there was a one-line fix, here with a configuration setting, but in searching for the fix it struck me how even old tech like WinForms must fit in with the new tech world.
The point is that in this NTW there are computers and computers. The different resolutions of modern devices is only the beginning. The tablet and the phone are essentially computers. Each of these has a tiltable interface that can be switched between portrait and landscape. A phone is also moreover very small. You nowadays have to code your program to make nice with all these sizes and tiltings.
At least though you do still write apps for a PC or a tablet or a phone (even if you write a single program with a version for each, each version is an independent app). What about the Internet, though? A website is loaded into a browser, and the popular browsers have a version for pretty much any popular device. Here we have ventured far beyond mere pixels. A website ought to look good on both a large Hi-Res screen for a PC and a phone on a phone in portrait. Even watches can be little computers these days. Does your site look good on a watch, be it Apple or Google? And what if you wrote the following code?
button.Text = "OK"
Kerrang, don’t do that! A perhaps overlooked counterpart to globalisation is localisation. Even little programs are often localised these days. So your button text should be able to be configured into the local language of the user.
// set text to 'OK' in the local language of the user
// in German fex 'Wiederholungsanpassungswertantwortverschliessung'
button text = localised.OK
Just these three things — screen resolution, device type, localisation — illustrate how far we have come from programming for a computer.
There is more, though. The earliest web pages were written in HTML, a ‘mark up’ language that formats text. With HTML all the basic formatting functionality is there, making it possible to create a simple ‘word-processed’ document. The early www was thus a matter of downloading documents. But the limitations of this were soon realised and so the giants invented the ‘gateway’. This was a gamechanger and the foundation of the modern www. For this gateway existed on the server — the central exchange that sends web pages to your browser. The gateway was a place pages could be sent to for processing before being returned.
Take a product page, for example. With HTML you could design a product page, but you would need a separate page for each product. With the gateway, you could now design a product page template and pass this to gateway. The product details were retrieved from a database and the template filled in with the data. The gateway then sent the HTML page back to the server which forwarded it on to you. The significance of this new toy was huge, for it can safely be said ‘no gateway, no Amazon’.
Meanwhile, in browserland, the giants invented the idea of scripting. In its earliest days this was termed DHTML : Dynamic HTML. The markup in a web page was converted into a DOM (‘Document Object Model’), a tree-like structure that defined the layout of a page. The scripting language was first called LiveScript and then — this was during the glory days of the Java language — JavaScript (though, marketing aside, JavaScript and Java have nothing in common). It was JavaScript that could read the DOM and alter it. A simple example of this can be seen in the following code:
// HTML
<p>This is a paragraph</p>
// DOM + JavaScript
p.innerHTML = "I have just modified the paragraph text!";
All of a sudden, annoying animations appeared in web pages. Web pages were now dynamic. They could be programmed on the client (that is, the browser).
Of course, the giants didn’t leave things like that. Web browsers have become more or less like a ‘Windows on top of Windows’, unfeasibly complex systems with a host of programming possibilities.
Today, then, the web is more or less a case of ‘client, meet server and server, meet client’. A web page is still in the end an HTML document, but this end result is almost always produced by a myriad of technologies both on the client and at the server end. The document is, of course, sent to the device that requested it, any of the many types of device in use today. It may be viewed on a gigantic monitor, or maybe a tiny watch-computer.
That, in a nutshell, is a million miles away from the old days of a generic PC running on a Windows system. The old WinForms days. The path of your web-programming activity might now look something like this :
yaml
XML
SASS
React.js
TypeScript
Node.js
SQL (or NOSQL)
IIS/Kestrel
Razor
REST API (or GraphQL)
JSON
> server > client >
JavaScript
CSS
WebAssembly
> HTML > browser > system > (peripheral)
Even the basic apparently tautological definitions we began with — that programming is ‘programming a computer’ or ‘writing a program’ — are now mere dust. The notion of both ‘computer’ and ‘program’ have vanished. This does not mean to say that a web site is not a specific thing all in all, or that it does not in the end run on a computer. But just because a particular car’s destination is Penzance and all cars have a destination, that does not mean all cars have a destination in Penzance. That is important because you can’t run your website on your computer and say, ‘That looks perfect, all done’, for the destination of your live website is not limited to your computer (your ‘Penzance’, if you like). These days you are, if you like, ‘programming other people’s computers’.
What is programming, then?
So what then is programming nowadays? Before anything else can be done, it is planning and designing and thinking. Plan in place, then it is writing code, perhaps the core activity or at least the sine qua non of it all. Code written, then it is assembling codes into a running unit. Unit created, then it is testing the runnable. Tests done, then it is fixing code. This is a feedback loop — writing, assembling, running, fixing — until the glorious Day Of Beta. Beta built, then it is reviewing the app by all the interested parties. Fail? Back to the feedback loop. Pass? the hallelujah Day Of Release. Release done, then it is maintaining the app, more or less an as-and-when process (as and when an issue arises).
So,
- planning
- coding
- assembling
- running (testing)
- fixing
- reviewing
- releasing
- maintaining
Only the second stage is focused on writing code. Fixing and maintaining are based on code too, but not necessarily writing it. We could therefore define ‘programming’ as all this or offer up a narrow definition of ‘coding’. Which is a how long is a piece of string question and either way of looking at it makes perfect sense. Perhaps it is best to say that programming is both coding and a whole lot more.
Whichever and whatever, it is on that hallelujah Day Of Release — as your little app is at last sent out to become a part of Ymir, the World Giant, the giant of the giants who created the code your app runs in and on — that you become a programmer. After all, you have a program so ergo even M. Descartes in his deepest doubt would agree that you have programmed.
Programmo ergo sum programmator/trix.