Lambda the Ultimate

...software is fluid. It is in constant evolution under the influence of ever changing conditions; software development is sandwiched between a technology that is evolving at breakneck speed, and requirements that must follow the economic vagaries of modern society. In this, the commercial product called software is unique; the closest professional activity to that of software developer is that of composer in 18th century Europe. At that time, relatively widespread knowledge of harmony or counterpoint made up for the necessary skills to use and reuse fragments of sophisticated musical artefacts. For instance, [LD96] offers insight on how invention, a term borrowed from rhetoric, drives composition according to a process which bears a striking resemblance to building complex computer applications. Unfortunately, equivalent skills needed to master a software artefact are today in far more limited supply than 250 years ago.

Bach had his own students work on developing what he called "good inventions." Many writers have assumed that by an invention Bach meant the theme at the beginning of a piece - a fugue subject, say, or the opening ritornello in a concerto. Dreyfus shows that there's more to it. A Bach invention is a sort of musical "mechanism" that "ensures its own transformation." It includes, in other words, not only themes (more accurately, "thematic complexes") but also their implications for development and elaboration. In a fugue subject, for example, typical implications might include what happens when the subject is turned upside down or combined with itself. In a concerto theme, they might include what happens to the theme's constituent parts when transposed to the relative-minor key. Thinking through such implications was part of what Bach did when coming up with an invention. These implications were themselves part of the invention.
Bach and the Patterns of Invention

In this, the commercial product called software is unique; the closest professional activity to that of software developer is that of composer in 18th century Europe: This is a claim, not a fact.

Unfortunately, equivalent skills needed to master a software artefact are today in far more limited supply than 250 years ago.: In my view, this is patently false. Today's smart developers and researchers, in limited supply compared to the vast numbers of smart 18th century composers?

http://threading.2038bug.com/threads/http,,,www.faqchest.com,prgm,perlu-l,perl-99,perl-9909,perl-990900,perl99090715_07786.html

Here's the relevant section of the text:

Here's another way of looking at how multithreading is harder than single-threaded programming: musically. It's certainly easier to compose a piece of music for an instrument that's only capable of producing one note at a time, such as the recorder or the human voice, than it is for a full orchestra all playing in parallel. It's also a lot easier to play. Even the members of the viol family, which have several strings, are usually played with one note (or pair of notes) occurring sequentially after the previous one, since simply playing upon two strings at an interval a third or a fifth apart is not the separate, independent melodic motion I'm thinking of.

Compared with violin, it's much harder to write and play something for the piano where you have multiple simultaneous agents, but it does allow for contrapuntal polyphony unreachable by a single human voice. Consider now a full orchestral score. Not only is it hard to write, it's hard to even read, because you need to keep track of what's going on by multiple agents in parallel. That's harder to hold in your head all at once.

Designing a multithreaded program can be a lot like designing a fugue or any other bit of counterpoint. In both the musical and the computer cases, you have independent agents making linear progress through the work, as the hardware clock or the metronome relentlessly marks off one tick after another. At the same time, the individual threads can seldom get away with completely ignoring one another.

The vertical, harmonic reading of the piece is as important as the horizontal, melodic one. This isn't just because of abstruse concerns based on music theory, like avoiding parallel motion especially in perfect intervals. Contention for shared resources was as much a practical concern to the composer as to the programmer. You don't want to write something that the physical constraints of the instrument would render unplayable as your fingers got all tangled up crisscrossing over the same instrument. J. S. Bach, uncontested master of musical counterpoint, produced his contrapuntal works for a variety of "processor types", if you would. Not all operating systems were equally amenable to these multithreaded applications. Consider a fugue written for a keyboard instrument such as a piano, harpsichord, or clavichord. There is only one way to access each note, so you have data contention between different melodic lines, much as you have in a multithreaded program. Some algorithms prove particularly challenging to elaborate, resulting in not only overlapping fingers, but crossed or tortuously overlapping hands.

Yet take such an arduous piece and play it upon an organ, and sometimes something miraculous happens: it becomes easy! That's because unlike the aforementioned keyboard instruments, which all have but a single keyboard, an organ can have several, both manuals and pedals. This can allow the amateur organist to execute multiple threads of overlapping access with hardly a blink. That's because while one hand is dancing upon one manual playing one of the fugue's melodies (that is, executing a melodic thread), another one can be executing a melody in a different manaul that tonally overlaps the first one in a way that even the most accomplished of pianists to throw up his hands in defeat. Add in the pedals, and you get yet another line.

An organ is like three (or more) separate cooperating processes, two (or more) with five threads each and the last one with two threads. Because of the organ's unique property of being able to produce two completely distinct but overlapping melodies, the organist can do things the pianist can never dream of. And much as a process can after a fork set distinct, per-process attributes in each process such as euid, open FDs, cwd, etc., so too can the organist set different timbres in the different keyboards, even when these would otherwise sound the same pitch.

How else can multithreaded parallelism in the form of musical counterpoint be achieved? You could of course use multiple instruments, as we see throughout the Musical Offering or in some of Bach's choral works. But that doesn't do you any good if you want to perform a fugue for a string quartet or an SATB-scored vocal piece when you're all alone.

Setting aside uncommon cases like the PVM library, searching for Mersenne primes, and SETI analysis, using completely separate instruments is the exception to the normal state of using one computer to run one program. But just as you do not truly need multiple CPUs in one computer to execute a multithreaded program, to compose a piece of musical counterpoint neither do you absolutely require a strongly multithreaded instrument like an organ nor even a loosely multithreaded instrument like a piano.

At least, not if your name happens to be Johann Sebastian Bach.

It's often easier to split a task into three separate programs than it is to do all sub-tasks at once in the same program. Certainly it would be easier to execute a three-voice fugue that used three separate violins than it would be to do so using just one instrument. In fact, it's incredibly difficult to use just one violin for this task. The cello and the violin each have several strings, and unlike the piano but like the organ, the same note can be played on different strings. But these are still essentially single-threaded because there is just one bow.

Despite this apparently fundamental restriction, Bach also wrote contrapuntal works for instruments that would otherwise appear to be inherently single threaded. Consider Bach's six cello suites, or his partitas and sonatas for unaccompanied violin--some of which Larry Wall can occasionally be badgered into playing for you on his own violin. The violin fugues are particularly notable, for here the Master has deftly created the aural illusion of parallel execution by multiple agents despite the inescapable fact that only one is actually present.

How was this remarkable illusion created? The same way it's done on a uniprocessor computer system: with time-slicing, or if you would, through coöperative multitasking.

Employing all the artifice of a mind intimately acquainted with parallel elaborations on instruments built for that kind of parallel execution (consider the St Anne Fugue for organ), Bach in his works for unaccompanied violin used the humble fiddle to produce astonishing cognitive effects on the human mind's musical processing centers. It's not just simple time-slicing as your bow quickly switches back and forth between the two or three different melodic lines, although certainly there is plenty of that going on.

No, it's much more, something almost magical. Astonishingly, there are some notes in those pieces that literally cannot be played upon that instrument--and yet he wrote them in despite this! In some cases, the listener perceives notes that aren't truly there, as the mind fills in the tones it expects to encounter at those points.

Most of us, myself certainly included, can only regard in abject terror the musical intelligence that could conceive of creating so convincing a work of multiple voices upon so single-threaded an instrument as the violin. When I see a tightly integrated, highly parallel,multithreaded application running in a single program without any of the modern mechanisms of protection and separation that we have all come to rely upon, something of the same awe is conjured up. Just because master kernel designers can perform such feats doesn't mean you should immediately expect everyone else to be able to so just as easily.