Sep
29
Automatic memory management (aka Garbage Collection) has been a mainstream for way over the decade now. Java was the one to make it popular. Some might argue that Lisp or Smalltalk should take all the credits but I'm talking mainstream here. Nowadays, any reasonable programming environment has it. Java, .NET, Ruby on Rails, Python, you name it. We wouldn't been able to do all the cool apps if we needed to worry about memory management. Let the machine do those menial tasks.
The side effect is that once programmers don't have to deal with the annoying problems of memory management, nobody can do it any more. I mean, there are a bunch of really smart guys who really dig these issues (and write memory managers) and there is the rest of us, who knows next to nothing about it. All we know is that there is a GC, that it's reasonably fast and that we can rely on it. I interview internship candidates as a part of my job. Hardly any of them knows anything above that. That means no teacher ever mentions those topics in their classes.
Is this a bad thing? I don't think so. I don't really think we all should be bugged with such petty details. Sure, knowing the internals of the GC of your VM of choice is essential at some points but these moments are few and far between. There are more important and more interesting things to worry about day in and day out.
Now, how does it all relates to GAE?
Scaling a web app is hard. There are some ground rules but each case is different, really. The software conferences are full of 'How we scaled Flickr/Twitter/Another cool app' talks. They are full of scary words, words like 'denormalization' or 'sharding'...
But there are new development environment starting to emerge. GAE is a good example - it eases up scaling by taking care of the infrastructure. Scaling isn't a no-brainer (yet) but developers has been relieved of a huge chunk of scaling burden. There are other, more important and more interesting things to take care in your application.
I think that in a couple of years (dozen, if we're unlucky) there will be a small group of super-smart scaling guys, working on frameworks like those and a huge crowd of "ordinary" web developers who just doesn't care. They will use what will be available and don't give a second though of what's being done behind their backs in terms of scaling their apps.
And, just as it is today, hand-crafting will give you faster, less resource-hungry app but it won't be economically viable. The competition will develop faster and cheaper, while the infrastructure cost will be only slightly higher.
Is this a bad thing? I don't think so.
Comments
4 Comments so far
I would argue that complete ignorance on what is going on behind the scenes of a GC or a scaling framework is a bad thing. I agree that as long as one is building more-less average, not very demanding applications, that knowledge is redundant and hand-crafting things will not pay off. However, as you noticed, there are cases when it is a must. I think it is OK to forget details if one does not need them. But if you are saying that most of future Java developers know next to nothing about how GC works, I consider it an educational failure. What else should software developers study at university if not how things work? Should they learn how to use APIs, what one can immediately check in the documentation? I don’t think so:)
Well, do you have any experience with interns? That’s exactly what they do. Ask anything regarding “how things work” and all you get are blank stares.
That leaves all the fun work for us, the smart guys. And the money
BTW, I can name maybe 3 people who studied with me who knew anything about such esoteric things as GC or guts of a compiler. I don’t think students are worse now then when we were ones.
Not sure where your interns come from, but most decent computer science courses should cover these types of issues. I am a recent Australian CS graduate and we learned all about garbage collection strategies and other behind-the-scenes stuff. Off the top of my head, we also covered process management (we implement our own process manager which had to allow a choice of various selection strategies and measure execution times), and we also created our own compiler which had to parse a particular made-up language with meaningful error messages and convert the structure to a flat machine code. I agree that much abstraction is occurring. I am now a java developer, and hence worry less about memory management than would a C++ developer in my position 10 years ago, but I also probably develop application for a much larger scale (hope that makes sense), so the abstraction is neccessary. Having said that though, I do feel I understand what’s going on behind the scenes, and have several times had to profile an app or diagnose a resource leak which has required me to think about those behind-the-scenes issues. Maybe your interns have done a course that is very focused on data representation and business rules etc (like Information Science) and have had less exposure to low level stuff in order to get more exposure to the high-level stuff.
Consider yourself lucky.
I seriously think writing a compiler should be included in curriculum of any Computer Science school. Not because world needs more compilers but because writing a compiler from scratch helps you grasp most of what’s difficult in programming. Pointers, DSLs, GC, I could go on and on.
Unfortunately most schools here (Poland) do not require actually writing a compiler. Some don’t even offer courses on that, some teach only theory… Sigh…