I’m afraid of low level programming.
It’s running right now. Beneath those fancy windows. Under the hood. Shifting bits. Moving words in memory. And its scares the crap out of me.
Why? It’s a facet of human nature: what you don’t understand, you’re afraid of. But what can a novice programmer do about it? One of the main reasons I chose software engineering as a major is because I don’t want to have to think about the lowest level of computing power if I didn’t need to. I want to solve problems, help the company I’m at succeed, and enhance my knowledge of the craft.
However, I’m starting to learn that I may need to return to the ‘roots’ of programming. I’m taking a computer graphics course this semester, and it will be the most C/C++ programming that I’ve done in a while. Now grant it, I have had other classes where we did assembly and C, but not the entire course. It just seems to me that in order to really solve a problem efficiently, you should understand some of the underpinnings and inner workings of what you are programming.
So, what’s my solution to this? Well, for now, tinker around with C++ and maybe even poke around the Managed C++ Quake port. Being in the Kingdom of Nouns ruled by Java and .NET is nice though, and it really does let you focus on the problem at hand. Sometimes though, I wonder if escaping from those magical places allows the programmer to really dive into the task at hand and nail it down. I don’t even want to get into some of those esoteric languages that I happen to see way too much about.
One day I’ll get around to reading K & R or CIL Under the Hood, but until then…Are there any other ways to dispel this fear? Let me know what you’ve done to get over it.
Valgrind is your friend.
The downside of that is Valgrind only runs on Linux/*BSD at the moment. Which is perhaps a good thing, because there’s nothing like learning to port code across to different platforms to learn what are good and bad assumptions in low-level languages.
November 27th, 2007 at 1:39 amI was a “high-level” developer for a long time, innocently coding away in .NET land blissfully unaware of what was making everything tick. Now, I produce software for a switching shop in C, and let me tell you, life’s never been so good.
They key to getting your hands dirty and liking it? It’s hard to say, really. The biggest thing for me was, in part, my love of math, and in particular, my recent exploration into higher level maths such as abstract algebra and other theoretical topics. Once you begin to see how mathematics and CS interconnect (from a deep theoretical perspective, not silly binary logic), the whole world opens up. Also in part was an exploration into how hardware really works (try “Essentials of Computing Systems”… 100 level stuff, but it’s an great take on CS education for the hardware-ignorant programmer).
There’s a million avenues you can take. Literally. Tons of books on kernels, compilers, systems architecture, gate logic, algorithms, etc. More fields of mathematics than I’ll ever be able to name, let alone understand. Nothing has ever helped me more, though, than a good project that a) is beyond my current ability, b) involves subjects I need to learn, and c) interests me. MUDs filled that role for a long time. Currently, it’s robotics, compilers, and physics simulations that are pushing my knowledge forward.
But without a sound interest in advanced math and/or without pet projects that drive interest in lower level concepts, there’s no hope. Read what you can before it puts you to sleep and hope some of it sticks.
November 27th, 2007 at 3:35 amRead K&R. It is short, and easy to understand. All the examples will also leave you with a lower-level understanding of memory and pointers, something that is sadly lacking in many new programming courses.
Of course, you may never need to use a pointer in anger. But by understanding pointers etc, you will have a much clearer grasp of what is happening under the hood.
If you want to understand the lower levels, I’d also suggest some exposure to assembler, but most people shy away from it. Learning some unix shell tricks is also time well spent - not only will you be able to be more productive, but you will also learn how to string simple actions together to complete more complex ones (the Unix Way!).
Don’t be afraid to try new languages - they almost all have some lessons to be learnt (even if it is just ‘don’t use that one’).
November 27th, 2007 at 6:39 amHey Nick, didn’t I point you to that “Execution in the Kingdom of Nouns” post when I was on a particularly anti-OO kick?
Anyway, I’m currently doing Plan 9 kernel hacking and stuff in C and assembly (x86, amd64, and PPC), and I’ve got to say it’s pretty great. I highly suggest that you dig into C some more, and it truly can be fun to play with assembly.
I can’t say I agree with Michael’s comment that you may never use a pointer in anger–if you do ANY non-trivial C programming, expect to use them a lot because they’re one of the most useful things in C. I do, however, second his recommendation that you read K&R, dabble in assembly, and get familiar with the bourne shell (sh). Try AWK if you ever have some text processing to do; I’ve recently discovered how incredibly powerful it can be, especially when combined with sed and grep.
Oh, and learn Lisp.
January 24th, 2008 at 1:05 pm[...] XP, while the visualization helps on Vista.
March 18th, 2008 at 9:21 pm