Log in

No account? Create an account
About this Journal
Friends & Feeds Game, Simulation and Web Development
Current Month
Feb. 16th, 2014 @ 08:57 am How null breaks polymorphism; or the problem with null: part 1

Preface: After talking to a number of people I realize that somehow I managed to misrepresent myself with respect to type systems in this article. This article is an attack on null, and to point out that null is still problematic in many (if not all) strongly typed languages. Many who prefer strong types and static types feel they are more immune to certain runtime type related inappropriate behaviors. I feel the ability to use null in most languages in place of an object breaks polymorphism in the most extreme possible way. I am in no way implying that dynamic or weak type systems are better at handling these issues. As for me – I prefer languages with stronger compile time type checking.

This is a difficult concept for a lot of died in the wool strong statically typed OO programmers to fully digest and accept. There is an immense sense of pride in the strong statically typed community about the fact that unlike untyped languages, strong statically typed languages protect them from run-time errors related to type mismatches and unavailable methods. Unless you do a dynamic type cast (frowned upon heavily) you should be safe from at least this broad class of error. But they are wrong. Type mismatches and unavailable methods occur all the time in strong statically typed languages. And it is a common form on runtime surprise. What causes this common problem: the null which can be used with any type yet breaks polymorphism with every single one.

Unlike types in loosely typed languages the null is guaranteed not work polymorphicly thus requiring a specific type check. Did I say type check? But I have no dynamic casts, I’m following all the rules. Why should I have any type checks? Checking for null is a type check. It’s the mother of all type checks. Instead of having code littered with conditional checks for types and branches based on those types (an OO worst practice) you have code littered with conditional checks for null having branches based on whether it is null or not.

Now granted, life in a world without nulls isn’t easy and I use null often myself. It’s too tempting to use this magic value instead of writing code more appropriately. Some will mention the null object design pattern that “does nothing” with pride as a solution to this problem. These are in fact polymorphic. The only issue is that null objects only work in special circumstances. If you really don’t have a thing you shouldn’t be pretending you do and having it do nothing. You should have a separate chain of logic that doesn’t use the thing you don’t have.

I have talked to a number of coders that think that removing null from a majority of their code would be difficult to impossible. A difficult to grok kind of problem perhaps but intractable, no. Consider the following function:

int DoSomethingSpecific( int x, int y, int z);

Now I will asked the magic question. Do you check z for null in case you don’t have it? (or x or y for that matter). In C++ that isn’t even possible because it’s passed by value. If an appropriate default exists for z you may set z to that default before it is called. However plenty of times that concept isn’t the one you are looking for. What do you do? You simply write another function that doesn’t take z.

int DoSomethingSpecific(int x, int y);

Now let’s use generic objects:

int DoSomethingSpecific(object x, object y, object z);

int DoSomethingSpecific(object x, object y);

Using this approach doesn’t break polymorphism. You only call the appropriate function when you actual have the parameters in question.

Of course this brings us back to a more fundamental problem. The concept of null is so burned in to most OO languages that visual inspection of code reveals that most any object should be nullable and thus checked for null. C++ has a way around this with references that can not be null or checked for null (yes I know many compilers will let you assign null but you make clear your intent in using a reference:it should not be null). The C++ reference being used this way is at best an afterthought in the language. These references can’t be reassigned and thus are limited to incoming parameters on function calls in many cases.

Even if you create a class which prohibits non-null assignment casual readers of your code in many languages will miss this fact and do gratuitous checks for null anyways; defeating much of the purpose. The key is supporting syntax that makes clear the fact that an object can not be null. But that discussion is for another day.

In part two of this article I will explain many of the misconceptions and supposedly intractable issues related to removing null. It’s not as hard as you might at first think. I will also further explore the syntax issue, or without language support at least a possible naming convention.

About this Entry
Feb. 16th, 2014 @ 08:33 am Scenegraphs and Openscenegraph for 3D Software Development

I get a lot of questions about scenegraphs and 3D development. Many people either aren’t sure what they are or have misconceptions about them. For this article I will explain the concept of scenegraphs from the standpoint of OpenSceneGraph, an amazing opensource scenegraph inspired by the granddaddy of the modern scenegraph – SGI’s Performer. For purposes of this article I will use the terms OpenSceneGraph and scenegraph interchangeably in many places. It is beyond the scope of this article to explain all possible permutations of the scenegraph concept.

Standard graphics objects and a spatial graph

At their heart, scenegraphs are nothing more than a graph of nodes representing the spatial layout of a 3D scene while encapsulating primitive graphic characteristics in objects. This sums up the two greatest strengths of the scenegraph – spatial organization for culling and encapsulating graphics characteristics in a data format.

Standard graphics objects

Why is this such a great thing?

When model data is read into memory to be utilized in OpenGL or Direct3D using non-scenegraph solutions, proprietary formats are often used that are suited to the exact needs of the application. While this isn’t a bad thing in many respects, it makes it difficult to impossible to grab libraries and pieces of code you need from sources and use them without significant modification. Many times graphics programmers will see a technique they like and be forced to dig into the code and rewire things to work with there data structures. Scene graphics enable users to create code that works with the basic object primitives out of the box. This can quickly lead to a huge amount of code that is available for just about any graphics technique or purpose, ready to use out of the box.

Many ask, “What if you choose the wrong data format for these objects? Why is one superior to another? Scenegraphs choose a format that encapsulates the lowest level graphics primitives and states into unique objects. These objects are combined in the graph to visualize anything that can be procedurally generated in a lower level graphics API. Various graphics states such as material attributes, blend modes, textures, etc. each have a corresponding object that is applied when the scenegraph itself is drawn. Because of this flexible “standardizing” of basic graphics operations it is both possible to represent most anything the graphics sub-system can create as well as allowing new objects to be built to utilize them in a standard way.

Culling of the scene, optimization, transform stacking, billboards, LOD management, texturing are all able to have powerful, simple and standard code to manage them.

A spatial graph

By setting up the scenegraph as a spatial non-acyclic graph culling can be more easily managed as well as graphics state. A node with children can set the state for the children without the need to redundantly specify it in the children. A scenegraph is traversed as it is drawn and state is popped and pushed to both minimize setting state without need and to simply the organization and management of the scene as a whole. Scenegraphs are often used in a complimentary fashion to other more “automatic” and hardboiled culling and spatializing strategies such as bsp nodes. I have seen many scene graph systems over the years that use bsp structures at various levels in the scene graph strictly for collision detection. The main thing about this approach is flexibility. Scenegraphs can build very sophisticated scenes in a way that is logically consistent, as simple as possible and easy for the (relative novice) to learn and understand.

What scenegraphs don’t do

Scenegraphs are very powerful but not much easier to learn than the underlying graphics API’s themselves such as OpenGL or Direct3D. They are not “game engines” that the novice can pick up and with little understanding create 3D scenes from.

You may ask yourself what the point is. The point is to not reinvent the wheel. The scenegraph is so flexible a tool because it doesn’t try to hide capabilities or oversimplify them. However, it mirrors the kind of system one would generally have to write themselves through much trial and error to achieve the same functionality. Many of these concepts are “classic” at this point. OpenSceneGraph, for example, is chocked full of appropriate and useful design patterns. Performer used these design patterns long before the term became a buzzword. SGI spent a lot of time and money developing Performer, and like OpenGL, the results were impressive. Most modern scenegraphs are directly influenced by Performer and can be seen at their core to be “Performer-clones”. Those who try to build fast and flexible graphics solutions will eventually come to something close to a scene graph on their own eventually. But why reinvent the wheel. With solutions like OpenSceneGraph already waiting……

The choice seems obvious

Use an existing scenegraph solution. You wouldn’t try to write your own graphics API in today’s world. In just the same respect you shouldn’t try to think you’ll create a better scenegraph. If you need a fast, flexible graphics solution and use one of the scene graphs out there today. I personally prefer OpenSceneGraph, something I mention often. It has a huge user base and an unmatched set of features for an opensource project. Other commercial options include Gamebryo or Renderware.

In short the benefits of using a scenegraph are numerous. A reusable, flexible and fast object system and a graph structure for hierarchy give it a strong user base and an ever expanding collection of useful code.

The next time you think about doing a project coding in a low level graphics API think about bumping up to a scenegraph. They sit nicely on top of the underlying graphics API’s and make your job much simpler at the end of the day by allowing you to focus on the problem at hand and avoid reinventing the wheel.

About this Entry
Feb. 16th, 2014 @ 06:57 am The Top 10 Attributes of a Great Programmer

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


    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.

      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. </p>

      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.


    About this Entry