Lingua XML

How do you represent data? How do you exchange data on heterogeneous networks? How do you share representations of data between systems?

Since the dawn of modern computing (somewhere back around timestamp 0000000001 at the dawn of the epoch) we've had different methods for representing essentially the same data. Whether it was little-endian versus big-endian or variations on floating point numbers we haven't had a single common way to represent data.

This was a problem that has been attacked from several different angles. One was standards such as the IEEE floating point standard. CORBA was developed to create Interface Definitions that were mapped to platform specific implementations across machines and networks. Another approach was to declare plain old text as a standard and process it.

The plain old text approach had problems, one of which was not endian issues. The plain old text approach lacked structure. Without structure interpreting the text between programs became a chore. The parsers were brittle breaking each time a slight change occurred in one program's output. So structured text was introduced... And after a few iterations of this we get XML. The real power of XML is its ubiquity.

Obviously, ubiquity isn't something a computing standard gets automatically. People have to agree to use it. For example in the world of international languages French was once "lingua Franca" an expression meaning universal language but literally meaning language of the Francs. There was an attempt to create a new universal language but Esperanto is little more than a curiosity in practice. It isn't universal if people don't use it universally.

Just because a project uses XML doesn't make it better. You can do terrible things with an elegant tool. XML just gives us a universal tool to work with. It may not even be optimal for some tasks. Things such as JSON work better than XML for the specific task of asynchronous server to browser communication. XML, however, will probably win in this arena just because its power is its universality.

Competing Mental Models: Object-Relational

In order to deal with complex issues, humans create models. The models we make deliberately ignore certain aspects of a real-world "thing" we deem as irrelevant. In this way we simplify a more complex problem enough to deal with it.

For example, when you try and solve the classic "If train A leaves city 1 at 8 am traveling 60 mph and train B leaves city 2 traveling at 40 mph at 8:30 am and the cities are 100 miles apart, when will the trains pass each other?" You ignore many facts about the trains, the cities, and train travel. How big are the trains? Was it raining? Did the passengers enjoy the ride?

In mathematics we have various models of the universe (sometimes called maths). Each new type of math has its own symbols and rules. Different kinds of math we find our selves using in computer science include graph theory and set theory. These different views of the world have generated different paradigms of computing that can compete with each other in the mind of the programmer.

In particular, I deal with (on nearly a daily basis) the competition between the non-complimentary techniques used in modeling data for Relational Databases and Object Oriented Programming languages. The term for this mental conflict is called the Object-Relational impedance mismatch.

I've observed this mismatch to yield some pretty strange ideas in the heads of my peers. I've seen designs that match one table per object with inheritance declared illegal because you can't model it "properly" in a database. I've seen developers completely ditch the concept of a database in favor of "pure" object designs that persist data in either serialized files or XML. And, I've even heard of doing away with Objects entirely in favor of "Data Oriented" designs.

If the model makes for more complexity than it solves... isn't it a bad model? At the end of a long day, it appears to me that the problem isn't in our heads it's in our languages. What our languages can communicate molds in part what our minds can model.

Programmer = Communicator

I think it was Mitch Roth whom I first heard say,

"A good programmer is a good communicator."

I took MIPS assembly from Dr. Roth and he would grade our assembly not only on coding content but also on the grammar and spelling in our comments. Whenever students would complain about how this wasn't an English class but an assembly language class he would repeat the above quote. "A good programmer is a good communicator" was a common mantra at my university.

The programmer communicates their thoughts and ideas to both the machine and the other programmers who read their code. If your comments and notes don't leave a clear picture of what your code does and what it was intended to do, then you have failed as a communicator. If you are clear about your intentions and vision then you are more likely to have success.

Lingua

If the language you speak in part constrains your thoughts, then isn't the same true for languages you code? If the language you speak can facilitate certain modes of thought, then isn't the same true for programming languages? Are there thoughts impossible to think in English that you can think in a programming language?

The computer is the first technology to act upon thought outside of a human mind. These thoughts are not the same as what the "analog" thinker thinks. The act of learning to program is transformational and forever alters the way that the student thinks about things. The thinker becomes a digital thinker.

Software Engineer

Somewhere along the line we created the position of "Software Engineer" and distinguished it from other software roles such as Programmer, Developer, and Architect. Somewhere along the line we got the idea that software should be engineered.

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

-- Frederick P. Brooks Jr.

This seems to me that the Software Engineer is an engineer unlike any other. Instead of having a physical world which will respond as expected or clearly not the Software Engineer must shape thought itself into a disciplined structure. The material that is to be formed, welded, shaped, beaten on, or engineered is the minds of all the people interacting with the software.

What is a Website? A Torrent? A Blog? Or an Instant Messege? How are they different? Why do we care? These ideas are the stuff of the Software Engineer, the raw materials of the builder of castles in the air made of air.