by Steven J. Owens (unless otherwise attributed)
>For instance I am not required or expected to learn Java or Perl
>which our system is programmed in.
Java can be crazy-making frustrating to learn, even for a fairly technical non-programmer. It's also a really big bite to swallow; Sun's aiming java to take on nearly every niche of the programming field.
Perl, on the other hand, can be annoyingly messy and obtuse; there are a lot of implicit behaviors in the perl language that can perl source code infuriatingly mysterious. It was designed to be somewhat like a natural language (say, english) that way; you can use short-hand and rely on implicit assumptions and defaults or you can be more precise. It's also very much focused on WHAT you want to do as opposed to HOW precisely that gets done. If you want to sort a list of things in Java you instantiate a sorting utility, code a Comparator and instantiate it and pass it into the sorter, along with the list. If you want to sort a list of things in Perl you type "sort @list". For a beginner, this is usually a lot more fun since you can focus on your end goals.
Perl doesn't have to be hard to read, and in fact I think it's one of the better languages for dilettantes to learn. It's easy to actually accomplish useful things with perl. If you're at all into the web you can apply your knowledge to web CGI scripts, which in turn feeds back into your motivation - programming is a lot more fun if you can show off what you've programmed.
There a freightload of bad Perl/CGI books out there, and there are a handful of really good Perl books. The O'Reilly Perl books are generally a safe bet, though some of them (like Programing Perl) are a bit of a challenge for a beginner. There's even an "Elements of Programming In Perl" book meant as an intro to the general topic of programming.
However, the down side to Perl is that it will not take you as far as some other languages might. First, the very freedom it allows means you'll tend not to learn some of the structured programming stuff that Pascal teaches. Second, Perl doesn't play so well on windoze boxes, or for doing GUI applications. So if you're making a more serious, long-term committment to programming, you might not want to start with Perl. But on the other hand, if you're just dabbling, Perl is a good place to start. If you like and enjoy it, you may decide to expand your programming horizons.
However, don't be surprised if you don't find other languages as friendly as Perl.
Also, don't be surprised if the Perl community is rather isolationist. They tend to be rather focused on unix system administration type tasks, and usually the response to any questions about other things is either "Why would you want to do that?" or "Do it in Linux instead!".
All that said, Perl isn't going to take you as far in the long run. I'm not entirely happy with Java, but I haven't seen any good contenders for what I want. I like everything about Java except the language itself. I want something that's sanely and well designed, something that provides GUI coding, something that's cross-platform, and something that has wide industry support (so I can get paid to do it :-). However, I also want a language more focused on WHAT than HOW, more of a scripting level language. VisualBasic has some of the market elements but I hate the way the language is designed and it's not cross-platform. Delphi is an interesting possibility, as is Python, but both have very little industry/market potential now.
>Are there various 'classifications' for technical writing?
In the past I've said that learning something about programming can be useful, particularly since a great many (majority?) of tech writing jobs are in the computer industry.
Learning the rigorous thinking necessary to program well (i.e. structured programming) can be useful for understanding what you're working with.
Learning the dominant programming language in use in your field can be useful for achieving rapport with your SMEs, as well as making it just a little bit easier to grok what they're doing.
Having some sense of the programming experience and the inevitable bits of the programmer culture you'll pick up along the way are also useful in communicating with programmers (and as folks here on techwr-l are fond of pointing out - aren't we supposed to be the experts at communicating?).
In addition, learning some programming will establish some credibility with most programmers. Not that it necessarily has to be programming, though that's the most likely field, but studying any topic they recognize as technically complex and challenging will demonstrate to them that you're not asking questions just because you're too lazy to go look it up. This is not an us vs them issue, either. The same sort of psychology applies inside the programming culture; asking for help in learning how to do something for yourself will get you an order of magnitude more response than asking for help to doing something.
Open Source advocate Eric Raymond, editor of The Jargon File (published in the dead trees format by MIT Press as The New Hacker's Dictionary) has written a fairly interesting essay on "how to become a hacker" which I recommend to anybody following this conversation:
http://www.tuxedo.org/~esr/faqs/hacker-howto.html
I also generally recommend most of Raymond's writing, as well as The Jargon File (particularly the appendices of The Jargon File).