I've taken the liberty to remove the projects link on the left side of this page as I'm heavily rethinking my library design and all the stuff. Stuff like not calling everything itk and so on. Some of the ITK is really cool but most don't really mix if you just want to use on part of it. I don't care about uniquely prefixing stuff anymore - everyone's free to modify and rename it for another project. Yep, I really don't care about this anymore. My libs are designed to be sorta monolithic in function - I don't intend to create miles long identifiers. However, it may be an idea to used a prefix macro for such cases. Whatever.
One advantage about programming in C only for personal projects is that you can get a deeper inside in all the awesome syntactical possibilities mostly ignored by C++ programmers for various reasons. This starts with comma in expressions and goto for alternative flow control. Ever really entered a situation where goto would be highly valuable to have? If not, you're fine leaving it this way until you need to. There's a reason why the art of goto is not taught anymore but you'll appreciate it's existence if you're just getting far enough. Think about seperation of a function's algorithm, error reporting and success handling. If an error happens, you just jump to an error handler cleaning up everything that was created during runtime and returning or filling an error struct. Same on success to avoid a million repeated success handlers. Expanding this by using more than only success and error labels makes it even more interesting. It can even make stuff more visible and easier to understand - provided you don't spaghetti code and know what's controlled use of goto. RAII (Ressource Acquision Is Initialization) is another good example of where goto fulfills an important role: if an error occurs within a block, you'd jump to an error label cleaning up the created garbage. As all error labels are listed in a way that later occuring errors will also trigger error labels of possible previous errors, you can cleanup all kinds of allocated ressources/memories in exactly the same order. Nice, huh? Well, that's an old trick you can learn via some hidden Wikipedia knowledge or by letting an old C nut teach a few tricks. Or you can find it out yourself, as I did with most of it. Of course does it depend on what you're programming, but more than often you'll benefit from leaving aside contemporary code wasting techniques I can tell you!
Every tried how to really break the thinking cycle of some fellow programmers? Personally, I rather like to know how people work in what sort of internal schedule - what will stop their concentration and so on. Some just sit their and you can do nothing to distract them. Some try hard to have influence be part of their thinkage, though the output is the same - with or without. Personally, I'm more of a dude thinking all the time until I code something that will work fine for a while. Therefore I often think during off-work times and code when I'm at work. However, I get distracted by people talking loud, desiring my attention or anything like that. but I like distractions from time to time and I know that it's never a good thing to cycle over one thought. Some distraction is always good to feel the wind blowing again. Anyway, how does detect what kind of thinking cycle another colleague has? Difficult I have to say. Sometimes they get distracted extremely fast or just yell at anyone disturbing them. If you're alternating departments often, this is a tricky part as it may damage later relationships. My current tactic is to distract them in different situations until I find out more about their cycle. Of course do I not want to do any actual damage, but it's good to know whether they have a similar focus pattern. I really feel sorry all the time I disturb them, but do you really know whether THEY know what kind they are? Most don't. They just follow what's driving them.
Ever tried writing a parser to parse a language easing the creation of further parsers? No? Well, certainly nothing really need to do in your life, but a very interesting experience I can tell you! It's a good test whether your own parser is versatile enough for a reallife parsing task - it can enable you detect stuff you've never seen before! Seriously, the best thing is to the stuff you need to invent using either the actual you wanted to archieve or by writing something that'll fully depend on it. A parser will depend on beeing able to parse what he should parse - if the parser's designed to parse other languages... do so! Invent something descriptive! Go wild! It's like optimizing for what it's supposed to be optimized... Exactly what you want. I really love doing this at the moment. It's a bit slow but the more you try from time to time, the better it becomes and it's eventually able to do everything you'd do with a parser. Totally awesome! Plus you can work on beeing able to parse every shit you want. I wonder whether it's possible to abstract this a bit and get a binary version of it - think about the possibilities! One format to fit all! Load stuff optimized without caring about writing algorithms anymore! Just tell your parser how it works! I truly start to love the idea. It's what I code for.
Sometimes I think about the few times I found something really worth posting. Something substantial, something that's so real nobody ever should miss. So let's talk about complexities in video game projects. You know, games logics are actually simple. Before there were those massive game dev studios, developers usually had to worry about how to create amazing games with limitations. And they did very well - atleast those who made it to the top. However, in every contineous system development there comes moment where goals get more complex than what's technically necessary to achieve it. Trust me, that's a dangerous place to go! Power-of-n and further uglifications are good ways to start measuring complexity on an RPG were every action has unique consequences. Interestingly, this is also the worst worst-case scenario you can ever get when listing all possible events across three possible event situations. Anyway, there's no way you get the project running if you want a lot of influencing factors. Designers may float from beginning to end in an illusion where they don't get that someone had to cut design complexity so hard that linear gameplay becomes the only decision. You could write the most awesome engine ever - if you can't deliver the actual content, your plan needs to get rid of illusions. You may have the freedom to realize them by yourself in a private project, but commercial projects needs to get done in time - that's what you usually get your money for. The higher your position, the more you need to be aware of this. Think about if your favorite video games series will be cut down to a linear action game. Too complex goals may have played their part.