Ergonomy of programming languages: abstractions

Pretty much all the major programming languages have a way or another for creating abstractions and for a good reason. They enable programmers to deal with programs in the same way as engineers deal with large designs: design and build larger parts from smaller parts and reuse those in even larger parts. Abstractions let programmer to trade details for a chunked, large scale, view of part of the software.

Different languages have different capabilities for creating abstractions. When I started programming BASIC with SVI-728, abstractions were limited to subroutines that shared global variables and user defined functions that could return a single value. Building any meaningful abstractions was hard and most programs I wrote were just tangled mess of code.

Contrasts this with a modern programming language like C#, where programmer has lots of different tools for creating abstractions of all kinds. There are classes, interfaces, functions, methods. Programmer can pass around functions to other functions and construct new data types and so on. Such a power comes with a price though. With MSX BASIC it was enough to turn on the machine and start writing some commands to try them out and programs (at least the ones I wrote) were pretty short, only some hundreds of lines. With C# there is considerably more things to learn before one can get started with programming and different tools to master.

Data can be abstracted too. MSX BASIC gave you option to use integers, floating point numbers, strings and arrays of them. If you wanted to represent a character with name and age, you had to use two variables that weren’t tied to each other in any way. With Turbo Pascal I learned about objects and other ways of packaging related data together. Haskell took this to the limits with its type system (that I regrettably haven’t really learned to utilize).

Abstractions aren’t only about the things that the programmer can create. They’re also about design decisions made while creating a programming language. Different languages have different takes even on such a mundane tasks as performing an operation to each and every item in a list. With MSX BASIC you had to know how many items the list (or rather array) has and iterate over them using for-loop. With C#, you could use foreach-loop, that automatically looped through each and every item. In Hy, one can just use map that runs given function to each and every element in collections and returns a new list.

What does all this have to do with ergonomics of programming? Abstractions are useful way of handling large problems. By dividing problem (or the program used to solve a particular problem) into logical parts and solving those parts individually, programmer can tackle complex problems. They only have to concern themselves with a particular sub-problem (and maybe some adjacent ones) at a time, instead of tackling the whole problem in a one go. A language that makes making abstractions easy is usually well suited for solving complex problems.

Earlier I made distinction between abstractions that programmer can make (functions, methods, data structures and so on) and abstractions language designer can make (essentially language features, syntax, core library), but always this distinction isn’t so clear cut. Some languages like C/C++, Lisp and Scala have macros that can be used to generate code based on small snippets of code and parameters fed to them. This allows programmer to extend the language with new syntax and features, that the original designer didn’t think of including. Other languages might have extra libraries that add similar capabilities to the language, like Roslyn for C#. Such a great power comes with a great responsibility (as always). Extensive use of exotic and home-brewn macros quickly makes code hard to read to everybody else than the ones initiated with the specific jargon or dialect.

To conclude: to build large scale software, is to manage complexity with a way or another. Language that offers rich tools for abstractions is a language that is well suited for large scale software (other things like performance still apply of course).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s