Computer languages

This was a recent conversation with my family. My dad asked "What is the language you are trying to learn?" I said, "PHP and Drupal". My sister said, "Well, Drupal isn't really a language". I said, "Well, OK, it's more like a computer program for running websites". My sister said, "Yeah, a computer program, but one that's more of a platform or toolbox." In the end we were in good agreement, but I still find the thing rather hard to learn.

Why is that? Emacs, for example, could be described in similar terms. Instead of building websites, you mostly use it to build editing functions, but because it includes a fully-fledged programming language and connection to other GNU/Linux programs, you can get it to do all kinds of weird things. For example, one of my hacks was to get it to play music based on the keys I was typing. That was fun.

Like Emacs, Drupal has a bunch of "hooks" that allow you to modify the way it works. When something happens (say, for example the contents of a form are saved), a "hook" will fire, and any code you've associated with that hook will get run. There are quite a few hooks in standard Drupal, and learning how they work is a bit like learning a simplified "language". (Hence my comment.)

But, unlike Emacs, Drupal's debugging facilities are pretty arcane. Common Lisp tends to be even easier to interact with than Emacs Lisp, but the key word in both cases is "interact". Along with great things like "backtrace" and so forth.

In order to get proper debugging messages out of Drupal, you have to instrument the code with things like dd. That's pretty helpful, once you know it's there. Same goes for the mailing list. I learned tons about Emacs Lisp from the Help-GNU-Emacs mailing list -- and for some reason for a long time I thought Drupal only had its site's forums and issue tracker, and IRC. Asking good questions on a mailing list is one thing I'm good at -- asking good questions (and getting good answers) on IRC is something I find harder.

My pal from the Internet, Sacha Chua, has written a bunch about Drupal on her blog (google site search). She is also an Emacs hacker, by the way, which is how I know her -- and apart from that, she generally tends to maintain a positive attitude about most things (for years, her blog has been called "living an awesome life"). Probably reading some of her tips would help me get over my own bad attitude about Drupal!

(Quick digression on Sacha: she has lists on her website of things she can help you learn and things you can help her learn which is a great paragogical networking technique in my view, and a more balanced paragogical view on "learner profiles" than the standard Learning Analytics one.)

In any case, the best way to get over a bad attitude about learning something is probably just to dive in. (Unlike with cold water, you can't catch hypothermia from programming.) At one point when I was feeling particularly stuck, I read the first ten chapters or so of "Pro Drupal 7 Development". That helped give me a reasonably good high-level impression of what's going on.

One good thing about Drupal is the number of modules that you can just install. A lot of them do almost what you're after. (Which, at least in theory, reduces the learning load, as compared with having to code everything yourself.)

So far, the best way I've found to be productive with it is to work closely with friends and colleagues who know more about the system than I do. That's fun and really useful. Unfortunately for me, these colleagues aren't available all the time: they live far away, and our email-based communications aren't as effective as our in-person conversations. As our project lead put it, the best thing to do is to be able to depend on yourself.

I'm not sure if I have a specific mental block about Drupal programming or what, but at present it is certainly feels like one of my major Achilles heels. David Allen's comment that "You can do anything, but you can't do everything" feels like something I'd like to apply to Drupal: use my strengths at writing and conceptualizing projects to apply for grants so I can get money so I can hire someone who's good at this stuff. One problem with grant writing is that it's a bit of a gamble: I've heard that 1 in 5 applications, on average, gets the award. I'd particularly like to invest in a programmer who would not only do work on the project, but teach me and other people on the team (like this).

It's weird though: back when I was working on Lisp stuff, I didn't think so much about hiring someone. Since I "got it" more easily, I just did a bunch of programming on my own. I didn't necessarily finish everything (a big David Allen no-no) but think I did pretty well given the resources I had. It would have been nice then, too, to have a few more people around to talk to about the ideas and to hack with me on the code.

[...]