Saturday, April 28, 2012

Why OO programmers need to understand structured code

Its a natural tendency of people to want to imagine that what they do is somehow revolutionary and breaks with all that came before.  It makes them feel important and justifies laziness in learning history.  But nothing occurs in a vacuum and those who do not study history DO repeat it.

There are many places I take people to task for this today, but the focus of this blog is on object oriented coding and how, far from being revolutionary, it descends in a direct evolutionary path from structured code.  (Note that i am talking about code design and architecture, not so called "Object Oriented Design' which is actually a fad development methodology.  I'll leave that for another rant.)

There are two fundamentals of structured coding that define it. The first is the data structure. A data structure is defined as an organization of data in memory and a set of procedures to act upon it.

The second tenant is top-down design/bottom-up implementation. You start with what your code needs to accomplish and design the data-structure for it. This data structure will then require further data structures beneath it to implement so you design those, and so forth til you get to the bottom most level. The creates a clean multi-layered encapsulated design. You then "bottom up implement", starting with the most primitive data structures in your design and work your way up, testing each structure as it is built.

The first "high level" languages had no direct support for the concept of data structures, so we built them ourselves. In C code this generally meant a .h file to define the public interface and then one or more structs and procedures in a matching .c file. (We did similar things in Pascal.) The limit to only using a data structure's intended public API was a convention that good coder knew to follow but was not enforced by the language.

In response to this came the modular languages-- most notably Modula2. Modula2 added two very important ideas. The first was that it added import/export control. The .h file was replaced by the interface file. The interface file defined the publicly visible API to a code "module", which was just a data structure with some syntactic sugar. Other modules could only see what was published through that interface file. In addition, a module could control what other modules it saw with an import command. (In C and Pascal, all code was globally linked and saw all other global symbols in other files.)

The other important thing Modula2 brought was the concept of an opaque type. This was a publicly usable struct but its definition was hidden inside a module. To the rest of the code it was simply a reference to an instance of a data structure. As you can see, Modual2 was really the half-step between the procedural languages and OOP languages.

OOP languages came next and, just as Modula2 built on simple structured languages, OOP built on the modular languages. Modules became "classes" and the opaque type was formalized into the idea of class instances. More syntactic sugar was added to make such classes easier to define and use, and the level of control of imports was increased.

Fundamentally, however, all an object is is a formalization of a data structure. And good OOP code still has to follow the rules of good data structure design and use. Which, unfortunately, are not getting taught as much as they used to.

Saturday, April 14, 2012

Welcome to the Casino

Its time for another rant... and this time it is on the shambles of our national economy.

The legalization of Casinos all over america is an apt metaphor for what our entire economy has become. Investment has grown passé, replaced by speculation. Which is to say, hard work and dedication to a goal are no longer fashionable, instead gambles and throws of the dice to "hit it big" are all the rage.

This has been true of our national investment structure the stock market, for quite awhile. When it was originally constructed, the idea was to let the common people own a piece of a business and share in the profits of that business. Today, a company that generates steady profits is a public failure, growth is all important because the goal of the investor is for their shares to be worth more then when they bought them so they can re-sell them.

This is speculation, which is another word for gambling. Its is also what creates economic bubbles as everyone tries to buy and resell higher, and the last suckers holding the goods take a huge loss to pay for everyone else's profits.

Its not just the market though, we can see this kind of bubble/gambling mentality infecting every part of our economy. When I started in high-tech start-ups 20 years ago, it was about building exciting new products and creating new opportunities. We were creating the world we wanted to live in. We poured our heats and souls into those companies and their products. We *invested* ourselves.

With the $1B buy out of a 24 month old company with one, nascent product by Facebook, that world is totally and thoroughly over. The buzz on the street is all about "quick hits", jump in, release a half-assed product as fast as you can and, if it doesn't hit it huge, dump it and try again.
This is rolling the dice, gambling rather then investing.

Even the business models are slanted towards this, now. The "Free to Play' market is all about a few huge winners and lots of losers. Nowhere in the space is there room for a lovingly crafted niche product. It used to be, a game that sold 5,000 copies could be considered a moderate success. An F2P game with 5,000 users is a dismal failure.

Gambling moves money between pockets, but creates no new lasting value. Its a false value based on others' losses either now or in the future. Thats why bubbles burst. Investing on the other hand builds value, which is why Warren Buffet's shares have never 'burst'.

Investing takes time, and commitment. Where is investment happening today? In the "emerging economies". China, as an example, has been doing a remarkable job of investing in their economic future.

Firefly was probably right. The future language of trade, is probably Chinese.