Programming Matters

I have been reflecting a lot on the age old question of the “optimal” programming language for a while now. First I’ll issue the usual disclaimers about apples and oranges and how they need to be fit appropriately to the problems they need to solve. But more than anything else one thing stands true. This one thing I rarely see mentioned:

The optimal programming language is the one the programmers who will be using it are best suited to.

This doesn’t mean that it’s the one they already know. This means it’s the one that matches their skill level and the way they think. It’s more important to match up the language with the programmer than the problem that is being solved or any other criteria. There has been a lot of talk lately about “bondage and discipline” languages, dynamic typing and expressive power in programming languages. People think in different ways for different reasons. People have different skillsets. And others can be productive in an environment with rules and can create spaghetti in one without.

If I had a small team of top-notch programmers I would love to fully embrace and use a language like lisp or a purely functional language. That being said I have worked with a large number of programmers who can’t understand the basics of object oriented programming. They know the syntax but klduge the code into something that grinds to a halt and is unmanageable very quickly. The thought of the meta-languages those same programmers would create in lisp send shivers up my spine.

I hear a lot of crap about “the heat and the kitchen” and “if you don’t have the highest quality programmers you are doomed to failure”. Frankly that is pure crap. A certain percentage of programmers are “beyond repair”. But a large number of programmers are extremely solid when in the right environment. Frankly they need more structure and less wiggle room. And then maybe 1 in 10 programmers is the type that can be given full range to “be trusted” to use the full set of programming paradigms in any way they see fit. It may seem a little heavy handed, but show me any experienced team lead who disagrees.

Personally I find “bondage and discipline” languages to be best suited to the real world. We’ve all heard the statement “Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.” That statement is almost correct. I would redact that statement to the following “Any sufficiently complicated and well engineered program contains an implementation of Lisp.” The first statement simply isn’t true by itself because,if nothing else, many implementations of Lisp have been written in C. “ad hoc, informally-specified, bug-ridden, slow” - these added bits certainly don’t have to be the case.

I’ve done a lot of game programming in the past. A very common technique is to have the core in C++/C and have a scripting language sit on top of it. Often times it’s LUA or a Javascript-like language. The programming teams working on the scripting languages vs. the core C++/C code are different groups.

Design patterns are another way of embedding these principles in the language that’s being used. You often hear, “Design patterns! - those are bad smells! The programming language is insufficient - this is the only reason the design patterns are important”. I disagree. Design patterns may involve “wordier” constructs than a language that supports those concepts natively.  This involves less expressive languages having more lines of code to express the same concepts.  This part always makes me laugh. I don’t care what the programming language is - the number one problem I have seen again and again is TOO MUCH CODE and not enough THINKING. I’m not talking about lines of code - I’m talking about code control points or cyclomatic complexity.  Your XP junkie would cry foul but some programmers should learn using a punch card type mentality. Once they have mastered their craft only then should they be able to rebuild and modify “on instinct”. Carpal tunnel syndrome should never be a programmers fear.

I have worked with C code that was object oriented. Yes, I can hear you coughing. It is wordier than any language that embraces some form of OO but it can be done. And once it’s done it isn’t that terrible. Encapsulation using static inside compilation units, function pointer tables and a system to manage it, the whole 9 yards. Turing complete is turing complete.

Sometimes creating a barrier to entry to implementing more advanced concepts can be a good thing.

How many languages could be an optimal number to have at our disposal? With all considerations taken - hiring new coders, etc., etc. Some contenders based on popularity, power and potential include ones from several camps:

1. Java/C# - These guys are today’s C++. And they pretty much shine for the same reasons. Any good programmers you hire will be able to code in them with reasonable proficiency.

2. Lisp and it’s spawns - These guys seem great for that core of coders that will be building domain specific languages and need the expressive power. It’s hard to find programmers that will do it justice (as opposed to kludge up something truly clumsy), but when you do you will have some terse truly elegant code that is both flexible and powerful. But throw the code into a normal pool of programmers and they will beg to rewrite it in Java/C#. So definitely don’t do that.

3. Javascript - Sure it’s Lispy. But it is stands apart because of its ubiquity. You can find plenty of coders who think they can do it justice. And under constrained environments they may be right.

4. Truly functional languages - Haskell, etc. - I’ll be frank. I really can’t say I fully grok the trade-offs with these languages. I definitely don’t see these languages ever going mainstream simply because of the difficulty in finding people to use them appropriately. In certain domains they will rule, in others they will simply be overkill.

Those languages seem to have strong enough support and be sufficiently different to justify their utility.

That being said a lot of the conclusions I have come to are based on “justified” instinct based on my background. The languages I’ve coded in extensively since 1982 include (chronologically) 6502 machine language, “Bill Gates” Basic, Borland’s Turbo Pascal, 80×86 assembler, C, C++ and C#. I have also done some commercial projects in Visual Basic, PHP, Java, and Javascript . I have written code for a large number of languages but my career has involved those listed above.

I feel that in today’s world specialization is in order. Programmers should be able to choose different tracks and learn different languages in school and for their careers. We draw a distinction between digital logic design and programming languages. I think we should also break programming into specialties.

The programming paradigm should fit the programming audience (those who code to it). Like math or any science, programming is becoming a broad enough discipline that specialization is needed. After all, would you want your brain surgery performed by any doctor? I wouldn’t think so.

Preface:

Please read Programming Paradigms and Programmer Audiences for a more through explanation of the metaphor below.

Driving:

Freedom…..

1. I know how fast I can safely drive and don’t need a speed limit to govern this.
2. I should be able to make a u-turn on the highway if I need to.
3. If there are no oncoming cars at a red light I should be able to drive through.
4. When there is space to park right in front of my destination and its not marked as a parking space, parking lot spaces are truly inconvenient.
5. Turn signals aren’t useful for someone who is paying attention.
6. A driver’s license doesn’t actually help me drive any better.
7. I’m aware of my car and don’t need to have it inspected constantly in order to know it running properly.
8. Having tags on my car isn’t useful to me - if I commit a driving violation pull me over and I’ll give you that information.

I am clever enough and good enough to master all of these things.

Constraints…….

People are inconvenienced by them.

However,

1. I feel safer knowing others have to obey the speed limit.
2. I don’t want people making u-turns on the highway.
3. People driving through red lights are accidents waiting to happen.
4. Parking spaces don’t impose perfect order by any means, but the order they do impose is good enough to prevent parking congestions.
5. Turn signals are reassuring because it seems like no one is paying attention.
6. Having a drivers license makes certain things more uniform and less arbitrary.
7. If people weren’t required to get their cars inspected the road would be a dangerous place.
8. People feel accountable with tags on their cars, they are more likely to play by the rules and abide by their contracts.

I don’t feel people are clever enough and good enough to master all of these things without rules.
Programming:

Freedom………

1. Rapid code generation and prototyping gets things up and running faster.
2. Lambda functions make it possible to elegantly solve some otherwise difficult problems.
3. If I know it is safe I should be able to do it …. period.
4. I should be able to organize data and code any way I’d like, flexibility and true macros are a good thing.
5. If I call a function it will see what I’m passing when it gets there - signature signaling is gratuitous.
6. I don’t need formal class definitions….. I’m not sure what the point is.
7. Compile time checking is pointless - run time checking does it all.
8. Static typing enforces rules that would be enforced anyways.

I feel I am clever enough and good enough to master all of these things.

However,

Constraints…….

1. So people create some truly terrifying prototype code.
2. Some people find lambda functions difficult to grok.
3. A lot of people will shoot themselves in the foot if handed a gun
4. Programmers can create some truly obscure metalanguages, and given the flexibility create masterpieces in obfuscation
5. When functions have explicit contracts they are more likely to at least try and follow them
6. Formal class definitions make it easier for most people to understand what is going on.
7. No matter how much you test you probably haven’t tested enough.
8. Static typing makes people more aware of what the rules and contracts actually are.

How do I think I drive:

I’m streamlined, clever and carefree. I bend the rules when I can to get the most flexibility I can.

How do I really drive:

Sometimes those rules and regulations really save me. And I am extremely glad they are there for others. There are some idiots on the road.

SOLUTION:

Why won’t these idiots just get off the road (not going to happen).

If programmers aren’t up to the tricky stuff they should be coding (not going to happen).

REALITY:

Everyone obeys the rules but bends them when they can to get the flexibility they need.

Languages need to support multiple paradigms to truly be safe and useful.

If you haven’t read the first and second parts of this article, you’ll probably want to check them out here and here.

So I was working with a company that did 3D development for games! It was 1998 and things were still fresh and new in that area. The three API’s of mention were Glide, Direct 3D and OpenGL. I was working with some amazing artists and programmers and was glad to be learning more about the ins and outs of 3D development and tools. This was my first taste of a scene graph using Paradigm Entertainment’s Viskit. Scene Graphs are amazing things - and I was learning everything I could. Viskit was based on SGI’s Performer and like OpenGL - they had done something really, really right when crafting this API. Viskit sat effortlessly on top of OpenGL or Direct3D. I ended up working quite a bit on our Multigen loader to get all the bells and whistles supported. We used Max for our prerendered scenes but at this point Multi-Gen creator was huge in developing real-time models. It was a great app that made both programmers and artists feel immediately at home. Scene Graph nodes could be mapped very easily to Multi-Gen nodes. It was a perfect match.

As usual my dedication ran high. I was able to entice a truly stellar programmer from my time in NJ to live with me a significant portion of the month so he could code on the team as well. I worked with two artists that two this day I have to say are second to none. We created an amazingly beautiful world with truly stunning environmental effects. It was enthralling. In the end though small companies with only one project are fraught with peril. In 2000 Aeon closed it’s doors and my love for Viskit took me to my next job at console developer Paradigm Entertainment. They had built a version of Viskit that ran on all the next-gen consoles including the X-Box, Game Cube, PS/2 and even the dreamcast. It could still be baselined on the PC as well. This was my first time working with consoles - a fixed format machine, finally!
It was now 2000 and I found myself in Dallas, Texas, In typical game industry fashion several weeks after joining Paradigm they sold themselves to Infogrammes. However, they still were able to call their own shots for my time at the company. It was awesome having 3 or 4 teams working with 3D technology for multiple consoles. This technology was developed by a dedicated core technology group - I hadn’t been lucky enough to work with a company big enough to have this luxury before. They were the think tank of the company always getting all the heavy pressures but coming up with some truly stunning innovations. All of our artists were using Maya - which worked well, it supported a group hierarchy for scenes like Multi-Gen creator had previously.

Consoles are truly outstanding beasts to develop for. In all the years of working on the PC I had always dreamed of being able to develop for fixed platforms. You could know that once your testing was done it was good to go - no surprises based on machine configurations later in the pipeline. C++ was still the defining factor in game programming, although plenty of PS/2 code was written in Microcode as well. Common acceptance of scripting languages for high level prototyping was still a few years off. The best part about working at Paradigm was access to resources. When teams ramped up they could have 8-10 artists and almost as many coders. Things could really come together fast.
2003 found me back in Virginia where I started working for ITSpatial - a company that did 3D representations of cities a la Google Earth … before Google Earth had been around. In fairness there was Keyhole, but what ITSpatial offered was a different kind of thing all together. ITSpatial built a product that provided data integration and fusion in an environment that supported 2D and 3D mapping. This was perfect for command and control applications, situational awareness and emergency training. It was really one big serious game and had many of the elements of a full fledged game development effort and content production pipeline. The only thing difference was the price point of the product and the number of shipping units.

ITSpatial was strong and knew a lot about sales and business development. They were phenomenal sales people. I will always be amazed at how effortlessly they were able to get potential clients in the building, looking at demos - 3 or 4 times a week some weeks. They really were devoted to finding and wooing clients. This is a skill I’ve still got a long way to go on. I guess in some ways I’m still 100% a programmer at heart:)

In 2005 I broke away and this time started my own company Eureka 3D, Inc. I’m more of a hired gun/contractor with the luck to have access to a lot of other proven hired gun contractors. Eureka3D has worked on entertainment 3D, GIS and I’ve really boned up on my web programming skills in the last two years. Deep down inside I’m still wanting to get back “into the game” and sink my teeth into that big 2 year development project. Right now my pipeline is very full and I really am enjoying what I’m doing - so no complaints!

Here we are in 2007. What have I learned from the game and serious game industry after all these years? So much… I’ve worked with top notch programmers, others who couldn’t program their way out of a paper bag; I’ve worked with great artists, and a young up and coming project manager who was one of the sharpest guys I’ve ever met. I’ve worked with some truly genius biz-dev types that knew how to sell and pitch to clients. In 24 years every theory on project management for software/hardware/games has been debated, turned over and debated again much to my chagrin. I’ve seen every element of the business from pitching the contracts, building proof of concepts to final testing and delivery/deployment/distribution. I’ve learned a thing or two about politics and how important it is to avoid if at al possible. I’ve literally seen programmers in drop-down, drag out fights (visiting programmers from another company no less!). Religious wars over version control systems, graphics api’s, and taking on the latest new technology - been there, seen that.
The main thing I’ve learned however is that I thrive on the high-intensity, creative, ingenius environment that games and serious games involve. Finding a team that works well together, or a few truly brilliant individuals makes it all so worth while. I know I want to keep raising the bar and never lose the adventure. Because in the end it’s about the product, the team, and the experience. What an amazing 24 years it’s been!

With all the latest attention again on what does and doesn’t make a good programmer, I couldn’t help but put together my own top 10 list.

1. Being a great problem solver.
2. Being driven and lazy at the same time.
3. Ability to understand other people’s code
4. Having a passion for programming
5. Loving learning for the sake of learning
6. Being good at math
7. Having good communications skills
8. Strong debating skills
9. Extreme optimism
10. Extreme pessimism

After putting together this list some aspects surprised me, and I was the one who put together the list. So let me explain each in detail.These attributes describe those I’ve found in pretty much every great programmer I’ve come across. There were a number that fell through the cracks and I’ll explain those later.
1. Being a great problem solver - Hopefully everyone recognizes this one. Most good programming is all about being able to find solutions where others can’t see them. If you don’t have this skill the others matter far less.
2. Being driven and lazy at the same time - This one surprises some people. Programmers question things and are often “too lazy” to take the long route. The will spend countless cycles trying to simplify the problem and simplify their task. That said they having a burning need to get the job done, they just want to do it as efficiently as possible.
3. Ability to understand other people’s code - This point is essential but cuts some good programmers off from being great programmers. It doesn’t matter how well you can rewrite everything yourself - you need to be able to work with other people’s code on existing projects, lean on opensource in new projects, and learn good techniques from the code base that is already out there.
4. Having a passion for programming - on some level you have to love programming for programming’s sake. I suppose to be truly great at anything you have to love it in most cases.
5. Loving learning for the sake of learning - Programming is a moving target. Unless you love the art of edification you will sink fast. There are no laurels to rest on and no one cares what you did yesterday. Unless you are aware of the techniques on the horizon, you won’t be ready to embrace them when they become relevant.
6. Being good at math - Different people will have different opinions here - but at the very least having a strong grip on pre-Calculus math. I’ve never seen a great programmer without a solid grasp of at the very least algebra and trig.
7. Having good communications skills - This doesn’t mean that they can communicate with anyone and everyone. Specifically this means that they are able to clearly express their thoughts on their own terms. I’ve met plenty of great programmers who couldn’t communicate well with the world at large. However, given someone to talk to who understands the problem domain, they were all able to clearly state the problem and the solutions proposed.
8. Strong debating skills - This follows the same logic as #7.
9. Extreme optimism - Great programmers I have encountered have an insane certainty they can get the job done once they have chewed on it a bit.
10. Extreme pessimism - Great programmers I have encountered have an insane insistence that when they lack the information needed to make a good judgment that they won’t be able to make one at all.

Some of the things I instinctively wanted to put on the list but couldn’t say were true of at least 95% of great programmers include the following:

1. Being extremely organized - Understanding when and where organization is important, yes. But anal attention to detail is something present in great programmers as often as it is people in other disciplines.
2. Being good at managing other people and or programming projects - Somehow these skill sets are wonderfully synergistic when they sit side by side, but management and programming are often completely different disciplines.
3. Being able to write good design documents - Same as #2. This skill may make some people better programmers and I am in favor of learning it. However, plenty of great programmers I have encountered couldn’t write a coherent design doc if their life depended on it. This will know doubt be debated by heavily by some.
4. Having an ability to estimate time frames - Once again like #2. This is an acquired skill and a very useful one. However, I have seen absolutely zero correlation between great programmers and estimation skills.
5. Prolific reading of tech books - I do this all the time myself, but many great programmers don’t. Let me be clear though - most programmers who aren’t all that hot could definitely benefit from bootstrapping their skills with some good reading.
6. Ability to transfer their programming skills to any programming domain - Although many can, some great programmers can’t, or refuse to, grok other programming technologies. I like to think that this is a “refuse to” situation.
7. Write code that is correct the first time around - Many great programmers commonly have syntactic issues flagged by compilers or at runtime interpretation. Some are zealots about the details the first time out, others are much more “extreme” in this area.
8. Having other areas of great skills - some great programmers are good at only one thing - programming.
9. Social or antisocial - Great programmers come in both forms.
10. Are someone you’d want on you team - Unfortunately some of them just can’t work with others well.

Wonderful (web)blogs, evil sp(am)logs and now entertaining c(orporate)logs. We’ve come a long way since the .plan files that internet users made publilc to keep people up to date back in the day. Each popular thing evolves - this is the nature of technology and the net. And .plan files evolved with the power of html to the force of nature they are today.

Blogs, splogs and clogs. Technology has a way of coining cute terms and sticking to the theme. The latest in the series, the clog, a new breed of corporate advertising log. What’s a clog and how did they get here? Let’s look from the start.

When blogs came on the scene they changed the landscape over night it seemed. Who would have thought that such a simple concept could have such impact.? I remember years ago when online diary sites were a minor hit. And I do mean minor. It was inconceivable that in the future many, many people would be busy posting their ideas and feelings about topics on the web on daily basis. But that time came. Networks and communities sprung up overnight. Social networking sites like myspace and livejournal became 10 pound gorillas. At some point it seemed like everyone had a blog. It didn’t take for that crafty breed of annoying innovator , the spammer, to take notice.

Enter splogs. Spammers scraping sites to generate the appearance of personal, fresh content. They usually smell bad like all spam, but they proliferated all the same. Spammers were sprinkling bot dust on real blogs and even creating deep scraped blogs of their own. They did this of course to fool people into clicking on and buying products. Or to generate enough raw pages and links to get pagerank and get their affiliate sites high up in search engine rankings. Google and blogging software were finding themselves fully occupied to combat this. At around the point where everyone had a blog and was complaining about the prevalence of splogs….. clogs start to come on the scene.

These not so distant relatives of splogs and blogs are unique in their own right. Companies paying money to increase their search engine rank and presence on the web by creating high quality corporate blogs. Typically the polish of their content was higher than blogs, however, their motives were oddly similar to sploggers. They wanted to add real quality content and value to increase search engine placement, create more interest and generate exposure. Sometimes the lines get blurred. Everybody remembers the Blair Witch online hype from before that movie. This was the grandmother of cloglike thinking, studios themselves creating interest using efforts that appeared to be grassroots . UTube has been hit by the same kinds of things in their arena. Nobody likes deception. But oddly enough many of these high quality paid or encouraged clogs are starting to take hold. Many companies let their employees blog about their jobs online at work. The line is blurred in a good way.
Today there are quite a few companies clogging and adding real value to the web. They are entertaining and providing the information using the informal setup of the
blogs. In many cases they are visually appealing and contain great content. The web has grown up like all industries do. At first pioneers break new ground, prove their concept and gain notoriety. Then the corporate world catches on and takes the concept, polishes it and runs with it. This is certainly the case with clogs.

Think about Joel Spolsky or Matt Cutts… personable bloggers who mention their companies in each passing breath. But this is all good. Content is still king. And everyone has come to the table willing to share. Blogs, splogs and clogs….

The overriding question is where will it end and what will be next in this evolution?