Saturday, 3 October 2009

Simplicity.

I started this post after thinking about simplicity in general. It doesn't have to do with the theme of the blog except when those thoughts escalated in computing. I will start by giving some short examples starting with life and then computers and programming.

I was walking down the road thinking about what I need to buy for household needs (as I am now a foreign student who recently arrived in London) also worrying about things I bought and maybe I will not need at the end or foods that might rot in the fridge. I also tried to understand the reasons I sometimes buy more than I think I need.

One reason is that I very frequently confuse the "must reason" with the "need reason". For example, I first thought I should buy a set of plates and utensils because a house "must" have all the essential. But then I thought, what the hell, I am just a student in a student hall with a shared kitchen. I don't usually cook (even if I should) I just buy something outside or make a sandwich with pure bread and salami. I would just need one of each kind (fork, spoon, knife) and maybe those paper plates (and one plastic bowl for cereal) but not a complete set. I also bought a bread with the thought that I "must" have some bread but now I didn't ate from it at all and I preferred some toast bread I bought later for my sandwiches. It's hard like a stone now and I doubt I will touch it. I didn't thought naturally here about the most practical food I will need but just that I need some bread because a household always needs some bread.

Immediately I started thinking at other aspects of life (not only about buying stuff but also organizing your time and choosing the essential while filtering the things that are a waste of your time) and how the laws of simplicity applied to everything and could also be a great savior of time and could make my life easier. Actually, one grand rule of life or programming simplicity looks very similar to occam's razor. You should avoid what is unnecessary, unneeded, redundant.

I still concentrated on thinking on the reasons to why I want to do something in my life or if it's not necessary to spend time on specific things and concentrate on others that are more close to what I need and less to what they told me I must. Using this tool could be a nice way to review my demoscene and other hobbyist activities and maybe find better solutions that both gives gain in time and happiness.

Yesterday I installed Ubuntu. I almost never have Linux in my system and I get those curious looks and comments. "But you are a geek, how can you not have Linux installed?". This is a "must" motive. I think that some people have Linux just because it's geeky or it's a rebelous thing or they MUST. I have no problem with that. But when they ask me why, I have my answer. I never needed it. Of course, some things in Linux may have the simplicity I am talking about (if you tell me that the linux API is simplier than windows I tend to believe you because the windows API is a mess (although I have just tried to code some MFC applications, I don't know how things are in the core)) but I got used to work fine on windows and it has everything that I need. Why change it (except from curiosity)? So what was the reason I installed it this time? A "need" motive of course :). There is no gamepark wiz devkit released for windows yet. Although till I start a true project on wiz they might have done that already. I just couldn't wait :)

So, the rules of simplicity are helping a lot when you start thinking what you are supposed to need for your computer and what apps you should use and which operations are necessary for a user or even a geek who just wants to do his job and doesn't currently have the curiosity to look deeper. And the most interesting thing is when you try to think about an application you are developing yourself. Or an API you work on to use on your future programs.

I have bumped into the question several times when I tried reusing my own demo framework that I started from scratch since my latest demo Quantum Retrofuture. I am currently trying to redesign some stuff but I think I will have to seriously stop programming for a while, take a piece of paper and a pen and actually ask myself: "If I was scripting my new demo right now how exactly would I want things to work? How would I like to set up shaders, load textures, models, move the camera, sequence the demo parts, time the transitions, call the music player? How simple can my functions and structs (or objects) be so that maybe a programmer newbie could script a demo out of it? How easier can it be for me to reuse this engine to script new demos during a strict deadline? All this simplicity without sacrificing the functionality of course."

Needless to say, currently to load a shader or initialize a texture from an image I have to edit at least three different source files, two header files to enumerate an ID for the shader or texture and the location in the disk and at least one to load and initialize it if not two for the image to texture case. Of course I had organization in mind when I designed this framework and so I had one source file for image loading, one for texture management, etc which is ok but somehow trying to be more organized than you think you can be can be messy sometimes. Maybe if I made a wrapper with simplified functions that did things directly using the non-simplified framework would be a solution but I'd prefer to think more about a new solution from scratch. The same complicated was my newest software rendered that I stopped working on it because of the complexity I wanted to integrate with different source files focused on an hierarchy of 3d meshes connected to objects connected to scenes connected to worlds connected to a screen struct for viewports and all these interconnected with other things. I had a big time of thinking to imagine this one. Maybe I will create from scratch a tiny 3d engine based on simplicity and live the other one for a bigger project (this was originally planned as an engine for GBA or Gamepark demos that need a fast software renderer).

I keep bumping in this question and each time I fix something although a redesign might be needed. I am not into object oriented programming yet, it's all pure C mostly and one question is whether I would need to create some classes and move more towards OOP for my next demo or I could nicely stick with C. Personally I think that with proper planning and having simplicity always in mind, also keep down the keyboard for a while and carefully plan in a piece of paper, a very easy to use demo framework could be feasable in C.

Why complicate things when you can easily make them simple?

1 comment:

  1. I totally agree that simplicity should be the driving force behind any plan, be it "real life" or program design.

    If you look a little bit deeper into UNIX and its system calls you will find that this "simplicity" permeates most of the design decisions there. A good indication would be to skim through the MSDN "porting from UNIX to Windows" section, where there are side by side examples of how to do stuff on unix and windows. Most often than not, the UNIX code is 2-3 lines, and the corresponding win32 code is more than 10 lines with weird functions taking 6-8 arguments or more.

    Case in point: process creation. Take a look at this example of spawning a compiler and waiting for it to finish on windows and unix: http://nuclear.dnsalias.com/tmp/proc_spawn_unix_win.c.html

    You already discovered the simplicity of C, and I agree, and it's the main reason why I use C whenever I can. Remember that C and UNIX where designed by the same people at the same time. C was written specifically in order to write UNIX in it.

    -- Nuclear

    ReplyDelete