Wednesday, 7th October, 2009
Debugging
So this is my first post in a while, and any following ones will probably be slow coming, too. Currently, I’m visiting my girlfriend for this week, so I’m otherwise occupied being taken out to see the local bars and what not.
Next week is freshers week, and I’m a STYC. This means I’ve got to help a bunch of 17/18 year olds get drunk in a new city. Yey! :-)
Anyways, the programming bit of this post.
Part of the reason for no posts is because of by Brainfuck interpreter. If you’ve looked at the code you’ll know I’ve incorporated it into a genetic algorithm and I’m trying to evolve something useful, it’s working, very, very slowly.
I’ve been trying to make it multiprocessor using the multiprocessing for Python. No good so far, the current code in github is broken. And during this time, a thought occured to me. Debugging has been steadily getting harder and harder.
This is not just in the “My program is more complex, therefore where’s the bug” harder, I mean conceptually harder. Imagine an assembler program with no OS. It’s just you, the code and the metal. Either the error is with you, the code or the metal, take your pick.
Contrast this with Java. There’s you, the code, the compiler, the JVM, the OS and the metal. When something really odd or intermittent happens, where do you point the finger? And if you’re 100% sure you’re code is right (For example, you’ve got the same code working on a different Java compiler/stack) how do you go about fixing it? Do you write your own library class? Do you inform the developers of said compiler and JVM? Do you ditch Java and try again with a different language? There’s just so much more to go wrong. Hell, it could be worse, there could be a client/server situation. Does the issue lie with the client or the server? Did the client (Assuming it’s http like) send the right POST/GET variables? Was there a networking error.
Now you can argue, if you had 2 asm programs, client/server, some of these issues would be replicated. Hell, what if nasm or gas had a subtle bug that you triggered?
My point that I am very laboriously trying to get to is, layers of abstraction are very good for code readability, maintainability, size, reducing development time and a whole host of other things. But you have to assume that the libraries and compiler stacks you’re using are very well written and tested. I’ve run up against what I think might be a problem in this sort of area with C# .NET and Python. Python I think the specific library’s documentation is not clear enough. And when I tried to use a library class with C# it just plain failed on Windows, but not Mono (I was trying to use exclusively MSDN documented classes, as little Mono as possible).
Don’t write code without a vague understanding of what’s going happening on the metal because of your code. You don’t have to know x86 asm like the back of your hand (I certainly don’t). But at least understand what type of things are happening down there.
Done! :-D