Programming (explanations for the non-programmers, mostly)

Okay, so, I figured I'd give it a go.

Programming isn't magic. Programming is telling computers what to do. Programming is generally done using special languages designed for it. The issue here is that, at the level we're currently working at, computers don't understand anything. So you can't use natural language and expect them to know what you meant. Rather, you have to have a language which is formalized enough that you are expressing exactly what you want done, and then the computer follows those instructions. Exactly. Blindly. Without any kind of awareness.

When I was a kid, some of the teachers did a lovely demo of this, although they didn't know it. They were just talking about assumptions. So they had us write instructions for making a peanut butter and jelly sandwich, and then they followed the instructions.

So, for instance: "Take two slices of bread. Spread butter on one side of each slice of bread. Now spread peanut butter on one slice, and jelly on the other slice."

Do you see where this went wrong? It never tells you that the peanut butter should go on the buttered side, not the other side. You could easily end up with each slice having goo on both sides. For that matter, why are we assuming that "side" means "the large flat sides" and not one of the thin sides with crust? What do you mean "spread"? Do we use some kind of utensil? How do we use this knife?

So imagine that it's just like that, only even more extreme, and you basically have programming.

 

That sounds like a really unhelpful teacher.

I like Lua a lot. It's a good example of what I call a "small" language, meaning, a single person can actually fully understand the language. Contrast with something like Java or C++, where no one person really fully understands them, I don't think.

There's a lot of things that are close-to-common between languages, or generally true, but I get fussy about oversimplifications.

At a very broad level:

What the computer is actually executing, in general, is called "machine code". The idea is that the machine has a set of operations it can perform, called "instructions". Each instruction has a way of being encoded as a number, and then you give it a series of instructions as a series of numbers. (Secretly, everything in computers is numbers. Text? A series of numbers denoting letters.) So the next layer of abstraction up is that instead of the raw numbers, you use what are called "mnemonics" for them, which are a sort of representation. Like, "add" or "jump". ("Jump", sort of generically, means "instead of executing the instruction after this one, go somewhere else and start executing the instructions you find there.) Machine code, and the mnemonics for it, are specific to a given CPU family. Most desktop computers are using Intel or AMD CPUs, based on the x86 or derived chips, but there's other architectures; for instance, most tablet computers are using ARM chipsets.

Instructions can have parameters that affect how they behave, and which are then encoded in the final number. So, for instance, there might be different instructions for adding numbers using only one byte of storage per number or using 4 bytes of storage per number, and they might be called "add.b" and "add.l" (for "long word") or something like that.

The general category of "instructions expressed using mnemonics" is often called "assembly language", and is... well, also way lower-level than we usually work these days.

Higher level languages are further from the way a specific computer works. If I'm writing C code, my code will look the same when I write it, but can then be "compiled" to run on ARM or x86 hardware. Historically that used to imply being "compiled" to assembly, then run through an assembler to make machine code, but that's not always the case in modern compilers. But C code is still pretty close to describing a series of operations that are at least somewhat like what the machine does.

Past that, there's a few directions things go. Java targets a special computer called the "Java virtual machine". Java is compiled, not to the native instructions of a given computer, but to instructions for a theoretical computer. When you run a Java program, your computer runs what's basically an emulator for that computer. (This would be horribly slow, but there's some pretty amazing magic to make it reasonably efficient in practice these days.)

Some languages are "interpreted", which means that in general, they're not expected to be compiled in advance, but are read by another program that reads those instructions and executes them. Python and Lua are typically interpreted languages. (In fact, the boundary here is fuzzy, since "interpreted" often means "compiled to code for a virtual machine", which is roughly what Java does, but there's some stylistic differences.)

 

BTW, negativekarmaengine has done some writing about teaching programming using origami, and honestly I sorta want to take that class just to see how it works.

 

I think Java is a shitty teaching language. Way too much stuff you always have to type that isn't the program you're trying to write.

Object-oriented programming is sorta weird, but mostly I think things like Java massively overcomplicate it.

So, a quick summary of what "object-oriented" means.

Imagine that you are used to giving the computer instructions. And you can define sets of instructions, and name them; these are typically called something like "functions". So if I'm making an RPG, and I want a thing that prints your character stats, I might write something like (using Lua for example):

Code:

function print_player_stats(character)
  print("Health: " .. character.health)
  print("Armor: " .. character.armor)
end

And if "character" is a table that has "health" and "armor", this will do what I mean. This is called "imperative" or "procedural" code; I'm writing procedures that are invoked when I want to invoke them, and it's up to me to figure out which ones to invoke and when.

The object-oriented approach is more complicated (by far) to set up, and full of magic stuff. But! Once it's done, I end up writing something like:

Code:

function Character:print_stats()
  print("Health: " .. self.health)
  print("Armor: " .. self.armor)
end

You might ask: How is this any better? Well, here's where it gets cool. What if there's more than one kind of thing? What if there are characters, and monsters, and so on. And the thing is, they might not all have the same stats.

So in a non-object-oriented world, I would someday end up writing something like this:

Code:

  if critter.is_player then
    print_player_stats(critter)
  elsif critter.is_monster then
    print_monster_stats(critter)
  else
    print("Got an unknown critter, no idea how to print it, help!")
  end

In an object-oriented world, I write:

Code:

critter:print_stats()

Because each kind of critter has defined its own print_stats, and each specific critter knows which print_stats() to call.

This is not something that a language has to have explicit support for in order to benefit from it, although it helps when the language has support for it to at least some degree. Lua really technically doesn't, except that it has a few neat features and some syntactic sugar that allow you to fake it well enough for most purposes.

Ruby and Python and friends are all pretty big on OO, and unlike Java, they're comparatively terse about it.

 

You might find higher-level languages more appealing, because they can cut down on that some, but... yeah.

 

Lots of extra fiddly bits, I think. Comparing Java to Scala can be interesting, because Scala really is targeting the same machine (Java and Scala code can intermix, even), but it's much easier to see what you're doing, I think, in Scala.

This page on scala stuff shows a comparison between Java and Scala for a few things.

Java strongly encourages designs which end up with tons of stub functions which have to exist but aren't actually useful.