Sunday, January 13, 2008

High Level Languages Are Magic

After pondering the recent flap about how CS departments aren't providing a sufficient education by starting students in Java and ignoring lower level languages [link, link, and link], it seems to me that the problem can be boiled down to the simple fact that high level languages do too much work for you. They make it unnecessary to think about the low level things that cause the code work. It becomes easy to think of those things as "magic", and by and large dismiss them. Magic is an important productivity booster, but should be implemented only after understanding, to some degree, the little cogs that help it arrive.

High level languages do work hard for you, and I consider this an ultimate good, because I have a lot of work to do, and want to produce results as quickly as possible. One of the mantras of Perl is that given a context, it will simply Do The Right Thing. Java and C# make it unnecessary to think much (if at all) about pointers. This makes my life a whole lot easier. But it still helps to understand lower level concepts, for instance when considering the performance of various objects in a language, like StringBuilder in C#*.

I think magic is a danger even beyond CS departments. It's also inherent in productivity tools like Visual Studio, which will probably be learned on the job. If you only learn to use the magic, but don't understand that it isn't really magic, then you're headed for trouble.

I have a contractor who works for me developing ASP.NET applications. Out of college he didn't know C#/ASP.NET, but at a previous job had picked it up à la Visual Studio. I was just getting into ASP.NET myself when he hired on, and was a little confused about how the [auto] postback worked. I thought it would be quickest to ask someone with experience, so I did. But he didn't know, even though he was already producing fairly complex web applications for us. In his view, it was just a feature of ASP.NET, and beyond that was not important, as long as he could turn it on or off in the Properties of the various controls.

I had reasoned that it must be JavaScript, unless ASP.NET installed some sort of binary control on the sly. Sure enough, it turned out to be JavaScript. I decided then and there that our contractor was at a disadvantage because he understood web development primarily through Visual Studio, and this hindered him from realizing that ASP.NET was made to fit a set of (effectively lower level) standards, not the other way around.

We do a lot of programming in ASP.NET using Visual Studio, and it is a productivity booster. We're building more powerful applications in shorter time frames, and with less effort. Its magic is definitely appreciated. But seeing beneath the magic is what allows us to really understand and fix bugs, and build robust, maintainable applications.

Magic is for productivity. It's for those who have gotten the education, and the education is gotten by understanding the little cogs and how they relate to one another.

* This discussion, I might add, jumps right into the low level arguments of memory management, showing just how far removed you really are from those little cogs...

No comments:

Post a Comment