Classical programming

The classical education model is based on the trivium of grammar, logic, and rhetoric. See, for example, Dorothy Sayers’ essay The Lost Tools of Learning.

The grammar stage of the trivium could be literal language grammar, but it also applies more generally to absorbing the basics of any subject and often involves rote learning.

The logic stage is more analytic, examining the relationships between the pieces gathered in the grammar stage. Students learn to construct sound arguments.

The rhetoric stage is focused on eloquent and persuasive expression. It is more outwardly focused than the previous stages, more considerate of others. Students learn to create arguments that are not only logically correct, but also memorable, enjoyable, and effective.

It would be interesting to see a classical approach to teaching programming. Programmers often don’t get past the logic stage, writing code that works (as far as they can tell). The rhetoric stage would train programmers to look for solutions that are not just probably correct, but so clear that they are persuasively correct. The goal would be to write code that is testable, maintainable, and even occasionally eloquent.

 

Parthenon replica in Nashville, TN.

4 thoughts on “Classical programming

  1. This reminds me of the quote about deficiencies in software design:

    There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

  2. Hello,

    This reminds me of a first year software/algo class question from the teacher:
    Given an array and a location/index in the array, swap the left and right side of the array (with regards to the location). Of course, like lost of these scholl exercises, the aim, as much as possible is to do things in place/with no memory use…

    For example: [1 2 3 4 5 6 7 8] index 3 would return [3 4 5 6 7 8 1 2]

    I think that the teacher gave us this exercise in spite as some of us were being ‘slightly unruly’. However, as we had just studied how to invert an array (ie: [1 2 3] -> [3 2 1]).

    [Before the spoiler below, take a second to think about a 'nice' solution to this problem]

    In a stroke of genius (for my programmign experience), I just stood up and said: SWAP RIGHT, SWAP LEFT, SWAP and sat down…

    It took the teacher nearly 2 minutes to realize that I just provided him with a solution that he had never seen for the problem…

    (indeed, if you take an array, ‘invert’ the part on the right of the index, ‘invert’ the part on the left, and then ‘invert’ the whole array, you will have effectively swapped the right and left parts of the array)…

    This is a great example of a ‘rhetoric’ level solution to a problem…

    Another of my favorite ones. That I had to exaplain at least 3 or 4 times to my math teacher as he did not get it was my unusual demonstration for sum(1/2^n)=1. Here it goes…

    in Binary, 1/2^n is 0.00…0001… (insert as many 0 as needed for the n)…
    therefore, sum(1/2^n) is going to be 0.1111111…… (in binary)
    Using the same demonstration as we used to prove that 0.999999…. is equal to 1 (ie: there is no epsilon !=0 that result in 0.99999…+epsilon=1), we prove that 0.11111… (in binary) is equal to 1 (still in binary, but also in decimal)…
    therefore sum(1/2^n)=1….
    clean one, isn’t it?

    Cyrille

  3. I’m glad you bring up testability and maintainability in the “rhetoric” component. These are important aspects of software (particularly software that actually gets used) that are hopefully getting more attention these days. Having software that is maintained well and testable is generally higher in quality, but it can take some convincing to get there :)

  4. I like this thought a lot — however, just as it’s very hard to teach a person to produce their own eloquent rhetoric, it’s very hard to teach a programmer to write elegant code. In fact maybe neither can be taught without putting in the proverbial 10,000 hours. There is a bigger difference though between people who are average at something and people who excel in it (e.g. between people who play the piano and people who become virtuosos), and that is passion for it. If you’re not passionate about doing something, including writing code, no amount of forced practice will raise you above averageness. If you love it, nobody will be able to *stop you* from writing code, you’ll do it every chance you get — it will consume you, it will feel like play rather than work, and given enough time, code will flow from your fingers that will cause both you and others to weep for joy (and not out of pain).

Comments are closed.