s/technical reason/technical education/

thank Zarkon not all developers *are* engineers but there are some, like you, that have an interest or education in humanities. As computers pervade almost every aspect of our lives more and more, I hope they (the linguists, historians, philosophers etc.) become more common in this field.

I say this for two reasons:

1. People with a technical reason have a tendency to think that everything is the way it looks, i.e. to believe what their senses tell them. They often forget that what counts is how the human brain interprets the input. And every human brain is different. So it’s not only important about *what* you are talking but also (probably more) *how* you talk about it. I think that was your main point too.

2. The process of creating software consists, as we all know, not only of actually writing code but to a good part in analysis, specification, testing and constant adapting. All this requires a fair amount of communication skills. Also, you are basically trying to *translate* the ideas of humans (the clients, the system designers, whoever) into the language of the computer. There is, as you and the people you cite point out, a distinctive mismatch between the two.

But IMHO it is misleading to think that in computer languages everything has a well defined meaning. For the computer maybe, yes, but after all these languages too were created by human beings and are written and read by human beings. Every human brain connects slightly different concepts with the same line of code. If code was totally unambiguous to everyone, why would we need so many different programming languages? Why do say that one language is more “expressive” than the other? Why do I have difficulties in wrapping my head around Java, but Python seems to fit my mindset very naturally?

So, my point is, although natural languages and programming languages may seem very different at first, their usage (by us) is very similar. We could not do otherwise, it’s how our brains work.

That’s one way of looking at it, but I think that it has an overly pessimistic tint.

“Ambiguity” is not necessarily a bad thing. As I said in the article: “Without ambiguity and metaphor we couldn’t communicate complex new ideas, and we couldn’t extend our base of knowledge from one area to another, and we would be entirely unable to communicate anything about huge swaths of human experience at all.”

Metaphor (and therefor ambiguity) is at the core of how we learn and assimilate new information. And software development is about a lot of things, but it’s certianly about extending the conceptual scaffolding that we use to think — which means we need metaphor.

Here’s an example from science education. We know that electrons don’t orbit nuclei the way planets orbit the sun — but that metaphor connects with something we already know, and it provides a stepping stone to further understanding. If we tried to teach quantum states, orbitals and all of electron cloud theory at once schoolchildren’s heads would explode.

In fact, this isn’t just about the way kids learn science. It’s also true of the history of science. I think the whole pattern of scientific discovery is the about discovering, tweeking, and sometimes switching the metaphors (sometimes called paradigms) we use to process the way the world works.

So, I have a high view of metaphor and ambiguity. I understand why programmers in general don’t, but I think that very little could be done or discovered if we were only able to communicate in unambiguous code.

I’ll add another metaphor: software development is like carefully phrasing your three wishes so that the Genie can’t screw you somehow.