I’ve been around software and technology for a long time now. My early days were filled with coding in Assembler. From there, I graduated to C/C++, then Java, .NET, and lately Ruby. There are a few others in there as well, but not enough to get excited about. I don’t code much these days, but still I jump in on occassion. Each language has its strong points, but the progression is always about removing control from the programmer and moving it to the language or framework. In the vast majority of cases, I welcome not having to deal with memory management or pointer arithmetic. However, there are times when I long for knowing exactly what is going on when I look at code.
After many years away, I recently did some consulting for an old company of mine. They were having some issues with a C++ service I wrote a while back. This service handles distributed caching and session management. It’s complex code to get all the threads and distributed machines synchronized. The system has grown considerably since I wrote it, but it was years before the service started to have issues with scale. Sure enough, I had a comment in the code that mentioned the potential for a future problem, but it wasn’t worth solving it then (premature tuning is a subject for another post). After 4-5 years, it’s now an issue. I bring this up only because I was amazed at how quickly I knew what the code was doing. Other than C++ constructor/destructors, there was no magic happening behind the scenes — no AOP, no thousands of lines of framework, no garbage collection, nothing. I know I wrote the code, but I haven’t looked at it for many years so I barely remember what I was doing. If this had been Java with frameworks and AOP, it would have taken me a lot longer to figure out what was going on.
The ironic thing about my point above is that as programming languages have simplified the coding process, they have also made things more complex. No longer can you read ten lines of code and know what is going on. You now have to understand the underlying framework and know about all the AOP hooks that may be in place.
Now, where is that Ruby book again?
Leave a Reply