Illusory Follies Sed quis debuget ipsos debugatores?

Computer Science vs. Programming

There have been a few Slashdot submissions here and here. They're concerned with an article published by two professors from NYU that assert that Java (and similar high-level languages) are damaging to teach as the "first language" of a Computer Science education. Since I wasn't a real CS major, I'm perhaps a little outside of this discussion. However, I cut my teeth on C/C++ at school before moving on to the high-level languages (really just .NET and some very high-level languages like Ruby and Python).

I tend to agree with the conclusions. It's not that there's no place for Java. It's just that without the fundamentals of pointers, memory management, and basic understanding of the construction of complex data structures which are just handed to you with Java or .NET, it's very difficult to fully comprehend what you're doing

I had a very good professor that taught algorithms and data structures at school and although at the time, the experience was painful, I'm sure it has helped immensely. Despite my affection for things like Ruby on Rails which is extremely high level, I'm annoyed sometimes because of the indeterminacy of functions and the vagueness of the specifications. When you write a language that can do powerful things in one line of code, you're taking a lot of shortcuts and it can be surprising when a function returns something very unlike what you expected do the complexity of the underlying code. Basically, you ignore things like sorting algorithms entirely in favor of the "built-in" sort routine. How does it work? Well, you can dig it up in the code, but most people will simply use it and assume that it's the fastest for all of their needs. What happens is that writing code becomes an assembling of pre-built components. It reminds me of "building" Ikea furniture. Granted it takes a certain amount of handiness to put together your new desk but you're not gaining skills that you can use to build anything yourself without first being handed the pre-built pieces.

I tend to think of myself as primarily a Software Engineer. I'm not just a programmer because I do a lot more than write code. But I'm also not much of a Computer Scientist because I spend very little time actually attempting to improve upon techniques and mechanics of processing information. These definitions are a little vague, but I feel that Software Engineering is more what I do because I apply creativity to the process. I think one can be a Computer Scientist and a Software Engineer but I don't think my work normally falls into both categories. I've always found the role of a traditional Architect to be similar to Software Engineering. It's an application of creativity (design, color, texture, material, etc.) to a field of science (physics) that results in [hopefully] useful buildings. There are some "cutting edge" Architects that attempt new and innovative projects but most Architects are working with existing ideas and applying them creatively.

I've heard that Frank Lloyd Wright's buildings although amazing in appearance and remarkable in their artistic qualities are often problematic in simple ways. Flooding basements, leaking roofs, etc. were the result of a poor implementation of a great and artistic idea. It's not enough to be artistic and creative; a good system like a good building works and functions as it should in addition to its aesthetic qualities (which make it unique).

I've always seen this distinction between implementation-focused approaches and theory-focused approaches. Implementation is desirable for the production of new applications and system but will always be held back by advances in theory. It seems that Computer Science has largely lost its way in North American schools by focusing too much on implementation without teaching theory. Programmers are cheap. It doesn't take a lot of brains to assembly code from pre-built components and creativity often is the only difference between a good programmer and a mediocre or poor programmer. Without new advances in theory, applications and systems will simply have to stand on their desirability of implementation (i.e. how easy is to use?). New ideas must be infused into the process for real advances to be made.

The use of so-called AJAX seems an interesting example. The ability to use things like the XMLHttpRequest object were available for quite some time before companies like Google began using it to do amazing things. This is entirely focused on implementation. Web 2.0 applications (whose primary distinction seems to be AJAX technology) are an innovation in implementation only. Many "hard-core" programmers find the terribly sloppy and inefficient results that often result less than satisfying. It does cool things but isn't there a Better Way? I use AJAX quite a bit these days and it's handy. However, I have only a bare understanding of how it works and what might be a better design. I don't tend to concern myself with the next evolution of the Internet-- I focus on building things that work with the technologies that now exist. But AJAX really isn't a huge advance -- in fact its "magic" often results in massive security holes, odd and unpredictable behavior, and hugely increased server overhead.

At the same time, a Software Engineer who truly understands the science of the code that he writes is likely to make far fewer mistakes and write much more efficient code. Even without much creativity, a programmer who can optimize code is a desirable catch for any software company. I think that everyone should understand the underlying details of code even if some end up focusing on the creative, implementation focused approach or the theoretically, algorithmic approach.

I mentioned security in regards to AJAX and this seems important. It's well and good to provide applications that do the same things in easier ways but without a strong cadre of Computer Scientists, developing faster, more secure, and more reliable ways of doing business, we end up with applications that are never properly tested (it's difficult to test code that just does magical things!) and never adequately secured.

A little rambling of a post -- hopefully I've managed to convey something. Your comments welcome.