Sunday, December 12, 2010

Why I gave up on static types

I like programming language theory and how to use typing to do some pretty impressive things, but I'm getting older now and I just don't give a shit about types for day to day stuff. I also gave up on object-orientated code. I also said F-U to relational database theory. Why?

Because people using your product don't give a shit about how it gets done. That's the reality. They don't care if you use assembler or JavaScript. They just don't. The question is: can you make people happy. The more important question is: can you sell? can your team sell? can your sales team make compromises to make the sell?

This last question is the question that I ponder about since it affects my profits. Do I want to put up some academic/aesthetic wall in front of a sale? Or, do I want to enable them to make a sell?

This is where all that rigidity breaks down and I ask a new question. Is this methodology or technology better for sales?

Static typing? No.
Object Orientation? No.
Relational Databases? No.

There is a lot of bull-shit technology out there (especially built on .NET or Java) that is simply a wall to sales. Now, it does depends on what you are doing, but ultimately it comes down to sales.

My issue with static types is that I can't add new members at run-time; nor does it propagate. Everything I do now is basically a giant JavaScript object that I pass around with JSON. I don't care what is in it. From a business point of view, I know that if everything in the system doesn't try to map the JSON into a static class, then I keep all the data; it just propagates. This enables me to change elements at the data store like adding a boolean named "my_sales_team_is_awesome_and_sold_a_feature_that_can_be_added_by_a_bool", then I can sleep knowing that the entire system will just deal with it and pass it along. I don't need to deploy a binary nor compile across an entire system to add a little bool.

My issue with object orientated code is that most of my stuff is non-inherited. I have things that can not be objects. While I do use the JavaScript object a bit, I don't use prototypes. I just treat it like a map and move on with my day. I don't give a shit about binding code to data; this is the worst possible thing you can do. I need all my data in a format that it is (a) obvious what it is and (b) easy to transform by looking from the outside. This is my data model guide line; if any idiot can look at the data and know what it means, then it is a good data model.

My issue with databases is the same as static types. I don't want to plan out how my data is going to look. I don't want to think. I want to be agile and just capture data and throw it into the database. I want to capture as much data as possible then organize it later. I don't want to think about normalizing which I can always break (show me your schema, and I will find a feature that will break it). I just want to put my data somewhere safe and have it replicate. This is why I use CouchDB. It's very relaxing.

Looking back at my life, I realize that I was wasting a bunch of time and energy trying to reach a goal with stupid means. My goal was to enable crazy fast development, and I achieved this goal by simply changing my outlook and aesthetics.

Having said that, I realize that there are reasons these things exist. If you need them, then you should use them. I love static types, but only for raw performance. There are performance patterns that can be implemented as a server that are very flexible, and those are important things to learn as they enable you to deploy safe services. The problem thou is always with specifics.

Oh, it also helps to have mastered grep and write code that enables grep to be useful; this is an amazing productivity boosts for when static types are actually very useful.

I haven't completely given up on types, I just now realize that their place is not where I would have liked it. If you look at my github, then you can probably tell where I've been spending my time in terms of type system.

That's right, I'm a node.js junkie. I just spent a weekend cutting a new version of my platform, and I have to say that I get amazing velocity with it. So much so that I can focus on leveling up my design rather than painting yet another bike shed.


  1. For object programming, I tend to agree. I'am against too much object programming, design pattern or polymorphism. Best to use it when it is really needed.

    But for databases schema & static typing, I think it highly depend of the size of your projects.

    If you are alone on a project, the project has only a few thousand lines of code it's ok to go for a dynamic language, to not go too much into design and just perform what you need to do. Bascilly, you have in mind the whole design, all the types and the behaviour of your software.

    But where I work, there have been 850 people working on it for ten years. Here the main concerns are totally different.

    First the bottleneck is not the size or complexity of the new code you add. Most of the time you just correct bugs or add small functionnalities.

    What you spend much time is understanding existing code, see potential impacts of changes and on configuration.

    Configuration is not the main mater here so just forget it.

    But static typing, database schema help a lot on maintenance. It help a lot on huge codebase. You clearly see what expected, what is the flow without needing to go on a debug session.

    In that sence, too much polymorphism is as bad as dynamic typing with the same effects. If there is 10 possible implementation of an interface, you dont know the one that will be used.

    So I'd say for personnal projects or small projects you are totally fine with this way of programming.

    For big softwares, I'am tend to think the oposite.

  2. I had to work with an older relational database with no foreign constraints, and what happened is that it was full of junk, and I had to write a lot of code to check what happened when a relationship which should have been there was actually not.

    I routinely work with code which passes around pointers to "everything-and-your-granma" objects, and it's all very easy, until you look at it 6 months later, and that field which you added as a quick hack is now used everywhere, and you really should slightly change the meaning of "0", but all over the place "0" now means something else.

    These things exist because they have a value on the (not so) long run. "Agile" does not mean "throwaway".

  3. "Agile" does not mean "throwaway".
    I really understand your frustations. But running software is not all you have to delivery.
    As Favio said, you read the code thousands of times more than you write it. So, being able to grow and fix bugs in the systems are very important. By developing in a insane velocity, most of the time you will have bad quality.