Scott Yang's Playground

Having learned C first before any other language I’d have to Joel on this one, the reasoning behind it is you have a much better understanding of higher programming languages and how they work. It can also allow you to program more efficiently in the rare case you decide to use them ;)

It was often the way in years gone by that students would start low and work their way up into richer languages, I followed that route.

If I were to do it all again – I don’t know that I’d want to walk that path again as you seem to be absorbed with lower level things which in the grander scheme of things are unimportant.

As an example, knowing how to implement a double linked list or stack in C isn’t going to help you write better software in C#. I completely agree it is important to know the tools you’re using and the implications of certain decisions (such as algorithm performance) – but that isn’t something that you need to learn from writing C.

Your DSG example is an interesting one, since it both supports and contradicts your point.

To a relatively unadventurous driver of the car, all that matters is that the thing works and that it shifts faster than a manual. They’ll enjoy driving it more than a manual, and just take it to a repair shop when it breaks. This is line with your view that it’s not worth knowing what happens under the covers.

On the other hand, a racing driver will probably end up needing more information. They will want to know the corner cases: how to shift down two gears the fastest way; in which circumstances is it most likely to overheat; after how many miles should you take it easy on the gear changes.

Sometimes when programming you’re the unadventurous driver, and sometimes you’re the racing driver. Nevertheless, on every large project I’ve worked on, I’ve required both levels of knowledge. On every one, there has been a bug or feature that I’ve needed low-level understanding to cope with.

To make an informed decision about which environment to work in, you also need to know what’s going on under the covers. E.g. Python would be more productive for a project, but you know that Python’s garbage collection of objects with circular references only happens infrequently, your object tree is full of circular references, so you work with Jython or IronPython instead.

In a world where every abstraction leaks to a certain degree, you need low-level knowledge to know where to plug the gaps.

What’s the problem?

On your solution: how often do you call it in order to get the best performance?

More importantly, as a wider strategy question: have you picked the optimal platform for your particular project if that platform forces you to manually collect object trees with circular references?

Perhaps my example was poor, so I’ll try and get back to the topic of the post.

Garbage collection is a leaky abstraction (collecting objects with circular references is a good example here, but there are others), so without an understanding of your garbage collector there will be questions about your applications that you will not be able to answer. To understand a modern GC you need to learn a whole load of stuff:

– Conventional memory allocation
– Paging
– Memory fragmentation
– The structure of your address space
– Deterministic vs non-deterministic destruction

I find experience of C, C++, and other low-level things to be useful in learning the above. I may never program in C again, but I am confident that that knowledge will help me understand a problem in an application.

“At the time where I choose to let the VM do the garbage collection. Compare to Jython or IronPython where specific VMs would have different schedule for that.”

Choosing the time is hard, and I still feel that low-level knowledge is useful in doing so.

“Exactly. However how many platform + OS combination have you mastered to write the most optimal GC for each? Whereas if I am focusing on SOLVING THE PROBLEM, I’ll just let the system’s GC to kick in and does that for me, assuming it has already been optimise for whatever platform my code will be executed. Depending on the scale of the problem, knowing the actual fine detail of GC for that specific platform might not be very helpful.”

I agree with everything you say here: I have mastered precisely no platform + OS combinations, solving the problem is the key, and knowing the fine detail of the GC probably won’t be helpful.

That said, if a problem does arise and the GC is involved, I want to know where to start looking. With low-level OS knowledge, I know that a good figure to look at is the virtual memory size of my application. With low-level GC knowledge, I know that a better figure might be to look at is the size of each of the GC heaps. I have used both of those facts in the professional development of mundane GCed applications.

When working, I also want to know where there may be opportunities for optimisation (I admit that while this results in interesting problems for my brain, it may be less useful for my employer).

I suppose there is a trade-off here between being entirely focused on the problem at hand and operating with Just-In-Time learning (http://www.codinghorror.com/blog/archives/000575.html), and aiming for a broader knowledge base that may help you in the future. I think having breadth, even if your learning on any particular topic has been shallow, is always an asset for when something unexpected happens or you’ve run out of ideas.