Interesting things

The evolution of programming languages from the electromechanical 0GL to the advanced 5GL has fundamentally altered human-computer interaction. High-level languages and Low-Code/No-Code platforms have democratized programming, leading to the recent integration of AI tools which challenge traditional programming roles. But now, the confluence of AI with coding practices may not be merely a further incremental change but could represent the inception of a new paradigm in software development, a symbiosis of human creativity and computational efficiency.

The human/computer interaction

How humans program computers has only changed a handful of times in the last 130 years. The first tabulating machine was electromechanical. It was first introduced by Herman Hollerith’s company in 1890, and in fact these business machines put the BM in IBM. They could do limited digital processing on data provided to them via punched cards. An operator would program them with jumper wires and plugs on a pin board, telling the electricity where to flow and thereby which calculations to carry out. Let’s call this programming approach the Zeroth Generation Language, or 0GL.

The first large computers that followed borrowed Joseph Jacquard’s loom approach from 1803, using a defined instruction set encoded by ones and zeros; these were the First Generation Languages (1GL). Often they were implemented by giant roles of black tape with holes, a technology dating back to Basile Bouchon in 1725. The computing power was limited, but the only limit to the size of your application was how much tape your roles could hold.

The Second Generation (2GL) assembly languages increased human usability by replacing 0’s and 1’s with symbolic names. But in fact this was a small paradigm change, because these languages were just as tied to their hardware as were the wires in the tabulating machines 50 years before them.

The next great jump was FORTRAN (in 1957) and COBOL (in 1959). These languages were more human-readable than assembly, but that was not the key point. The key point was abstraction, achieved via machine-dependent compilers, so that one FORTRAN or COBOL application would presumably give the same answers on any machine on which it was run.

The transition to Fourth Generation Languages (4GL) was all about a leap in usability. Invented around 1970, SQL is the most notable example, using a human-like syntax: you tell it what you want, and it figures out how to get it. Despite its age it’s never been replaced and remains the gold standard for interacting with relational databases today.

Many computer scientists argue that the newest Low-Code/No-Code programming environments, such as Microsoft PowerApps, are the latest addition to the 4GL cadre since they similarly require little knowledge of traditional programming structures. This paradigm is exploding in popularity and transforming the enterprise IT landscape: business users (not IT professionals) create ephemeral applications to solve specific and often short-term business problems. But how ironic that with their GUIs and controls and connectors, they are the modern digital equivalents of the 0GL tabulating machine pin boards from 130 years ago!

Some people have argued there are now Fifth Generation Languages (5GL), used for artificial intelligence and machine learning, where the focus is on the results expected, not on how to achieve them.

From coding by hand to AI collaboration

The evolution of 0GL to 5GL is all about the leaps in how humans interact with machines. But not unsurprisingly, the advent of ChatGPT (and its cousins like Bard and GitHub Co-Pilot) has brought about a new paradigm in how we develop applications. As the new generation of college computer science students now well know, you don’t have to write your own Java/PHP/Python… code anymore; instead, you can ask ChatGPT to write it for you. Or for example, you can feed ChatGPT buggy code or code lacking in quality, and ask it to remedy the situation, or to create the tests and documentation. To be sure, there are limits, and a good human understanding of the language is essential to avoid errors and ensure you get the results you want. But the technology is advancing rapidly, its limits are contracting, and the degree of user-needed corrections shrinks every day.

If we project this situation forward – even just a bit – its ludicrousness becomes self-evident: humans asking AIs to create human-readable code for humans that no longer need to read the code! This paradox underscores a new era where the traditional roles of human programmers are not just assisted but fundamentally altered by artificial intelligence; it marks a significant evolution in computational development.

With Artificial intelligence now a key player in the realm of code creation, we need to examine its repercussions on this craft. This present state may be the start of a larger change, where artificial intelligence becomes a collaborative partner in code creation and the relationship between developer and programming tool is increasingly indistinct – in other words, a symbiosis of human creativity and computational power.

Sorry if I have become a Java-hater, but I really did not expect a language with so many deprecations to run after all these years!  As explained here I was one of the first people to write a rather large application using the relatively new “Swing” library,

If you are interested in downloading it, here’s the link: DataScan V357. Just don’t make fun of my dirty code!

Continuing the series, now I want to summarize where Constructive Alignment as a didactical tool falls short – and how I would fix it.

I said it in my last blog. Whereas John Biggs did a great job of connecting learning outcomes with learning activities and learning assessments, a connection to the real world — to the WHY — is completely missing.

Fortunately, this seems very easy to fix, as shown here:

 

In other words, the real world goals — the WHY — feed into the learning outcomes.  In my next blog I’ll give a concrete example of how this could look in a real-world teaching situation.

 

Continuing the series, I want to show why I think Constructive Alignment falls short – and how I would fix it.

Always start with the WHY.

Maybe there are teachers who teach in order to teach. Fair enough. But as a scientific and engineering oriented guy, I’ve always thought teaching has a very applied aspect. In this context (and I admit it is not the only one!) students should be getting skills and abilities that they can use in real world situations.

So in this blog, let’s focus on an IT student that graduates from an IT program and joins the IT industry. Working in this IT industry will require knowledge that she has learned.  Probably there are existing maturity models that can classify this situation, but this one seems pretty reasonable to me:

Now if you jump back to my first blog about Constructive Alignment, perhaps you can see where my discomfort is beginning. Constructive Alignment seems to be a very practical tool; indeed, the whole “didactical” world seems to love it!  It clearly connects learning outcomes with learning activities and learning measurements.

But to my the most fundamental and important point of dissatisfaction: a connection between learning outcomes and real-world skills and abilities — in other words, the WHY for learning — is missing!

More on this in my next blog.

Let me start with a disclaimer.

DISCLAIMER: I spent more time in my life working with computers than any other topic – and I am no computer expect. I spent more formal time in my life studying physics – but I am no physics expert. So considering that I have only been dabbling in educational research (known as didactics – which sounds more scientific than I think it really is) for a few weeks, the reader is well-advised to take what follows with a massive 20-ton block of rocksalt!

OK, having appropriately disclaimed myself, in this blog I present a leading didactical idea called Constructive Alignment.  In my next blog I’ll talk about why I don’t like it – and how I would improve it.

Within educational circles — and please let’s park the discussion about how scientific these circles really are! — the idea is known as Constructive Alignment. It’s due to a fellow named John Biggs, who even has his own website. As a simple guide to preparing very effective teaching materials, he proposed linking the learning goals and the learning activities and the learning measurements. In his own words, “In constructive alignment, we start with the outcomes we intend students to learn and align teaching and assessment to those outcomes.”

[ASIDE: If you have some time, surf to John’s website and you’ll be glad you did. He has a wonderful collection of essays and a general Asian perspective.]

I found this very pretty picture of Constructive Alignment here:

As far as I can tell from Mr. Google, whether it is scientifically justified or not (I’ve seen no experiments) this model seems to have found widespread application throughout the academic world.

In my next blog I’ll say why I don’t like it – and how I would change it.

The idea of a Googlewhack has been around for a long time: it’s when you stumble on a search phrase, no quotes, that returns exactly one result. It’s called a Googlewhackblatt when you do it with just a single word as your search phrase.

Well, not only did I stumble across a Googlewhack, but I did it in one word!

 

I was just writing a lesson about “computer drivers” and “database drivers” for my database class when the following idea occurred to me.  Not sure if everyone will agree.

A driver is like a slavedriver

It sounds a lot like slavery, and it is.  The driver does all the work. It does not ask any questions. It does not get paid. Most people don’t know it exists. And it only complains when it is asked to do something that it cannot.  Probably one day, if you are born again, then in a future life it is better to be born as a computer rather than a driver. Unless you really like being a slave.

Here’s a good picture of a slavedriver:

The Product Owner (also called PO in the agile world) is the guy in the background wearing a gold armband and indicating where he wants the big stone moved to.  He doesn’t care about the details: what kind of rock, how many slaves are needed, or how many ropes.  He just knows where he wants the big stone.

The slavedriver (called ScrumMaster in the agile world) is the big bald guy with the earring holding a whip. The slavedriver gets his very generic instructions from the Product Owner, then uses his detailed knowledge of the specifics (type of rock, how much friction, how many slaves, what kinds of rope, whether to use a lubrication such as water or sand, etc.) to “motivate” his team to do what the Product Owner wants. It’s all about motivation.

If the people are all suffering, we call this slavery. If the people are all having a good time, we call this the Agile Methodology. But both are the same.

A mathematician would say “slavery and the agile methodology are topologically equivalent to each other.” In the field of computer science or enterprise architecture, we use the term “separation of concerns.”  The Product Owner is concerned about getting the big stone to where he needs it; the slavedriver and slaves are concerned about the details to make that happen.

In short, the slavedriver makes the connection between the generic world (of the Product Owner) with the highly specific working world (of the slaves). The computer driver makes the connection between the generic world of the operating system, and the specific details of the hardware. And the database driver makes the connection between the generic world of the programming language, and the specific details of the specific database product.