New Programming Language?

Now that I’ve been working in the industry for a while, there are a few things on my wish list for programming languages.  These aren’t terribly obvious things.

I believe academic programming languages need built in profiling, both memory and runtime performance.  I know, I know.  If students can’t get their heads around basic programming, then why bother with these topics?

Still, in the real world, you need these features, and yet, they are not designed from the beginning.  If they were, I think you’d find a lot of cool things about your program, in very practical ways.  I know languages like Java like to hide how much memory is used, but to be fair, so does C++.  Indeed, finding how much memory objects use is hardly a straight-forward task.  If such monitoring were easily available, say, in a debug mode, you’d be able to point this out to students.

I also believe that languages need to separate out printing and debugging messages.  Java does this, somewhat, by letting System.out.println be for standard printing and System.err.println be for error printing.  Of course, most people say you should use logging, which, for my money, still needs to be greatly simplified, at least, when you look at the log4j model.

I suppose, if polled, you’d find most people wanting to teach some functional language or some such, to allow for greater semantics, but always near and dear to a pragmatic programmer’s heart is how fast things run, and how much memory it consumes.

Learning How To Use an Editor

I’m an emacs guy. I’ve been using emacs now for, I dunno, maybe 15 years. I can’t say I know everything about emacs. I don’t usually use grep within emacs, nor write e-lisp, nor debug in emacs.

Because I learned emacs, I never really learned vi. I know enough to quit out of vi, and that’s it. I knew a friend who started in vi, and was quite proficient. He forced himself to learn emacs, though, and while he liked emacs and could appreciate its power, there were things he could still do faster in vi than emacs. Each editor had its strength.

vi, in case you don’t know, is the default UNIX editor. In the past few years, it’s been replaced by the more powerful vim.

vi/vim are modal editors, meaning sometimes you are entering commands, and sometimes you are entering text. emacs, on the other hand, is not-modal. It uses control characters to maneuver around the keyboard, where vi uses the letter h, j, k, l (when it is not in text mode) instead of cursor arrows.

Now, this takes the new user a long time to learn, and initially, they can’t stand it. It’s too much work. But if you learn patience, you can eventually learn it. For example, I wanted to learn (once upon a time), how to use Windows shortcuts. I didn’t know how to cut and paste in Windows, thinking it should use the emacs model.

But I forced myself to learn, to work hard at it, so it became second nature.

It’s this kind of unintuitive learning that we do all the time in the computer field. It’s like a Westerner learning to use chopsticks. It requires a great deal of patience, but eventually, you get adept at it.

There’s really two aspects of learning an editor. First, especially for editors with steep learning curves like vi/vim, you need to get to the point where you don’t think about the editing actions explicitly. That itself can be hard. Second, you need to learn the various features. Many students live with a tiny subset of what is actually possible. If they would devote a bit more time, they would become proficient at it.

I suggest the way to teach this is through some kind of “game”. Perhaps you give various levels to proficiency, like they do in martial arts. Of course, this may only appeal to those that like competition, but still, it’s more focused than forcing people to learn for its own sake (even if a game is more or less just that, except it appeals to people’s competitive drive).

Although I’m talking about an editor, I could be talking about any program that students use when coding.  It takes time to learn and become proficient, and even more to become an expert.  So many choose not to become an expert because of how much work they perceive it takes.

Once you know you’re willing to do this work, you’ll find it easier to learn.