Writing

Feed Software, technology, sysadmin war stories, and more.

Sunday, June 2, 2013

Why I don't just "dabble" in random programming languages

I received a question from an anonymous reader this weekend regarding "Go" (the programming language):

Do you have any experience with this? If so, please share with your readers. If not, why not dabble in it a bit and let us know your thoughts? :)

In response to your first question, no, I don't have any experience with Go. I heard about a few small projects which used it shortly before I flew the coop two years ago. I have also heard about people outside the company jumping on the bandwagon since then, but that's it. I haven't written, tweaked, or even directly touched any Go code.

So, why not dabble in it? Well, I don't usually do that sort of thing. Just because a new language exists doesn't mean I pay any attention to it. New programming languages of various degrees of completeness show up on the radar constantly. If you read HN regularly (and I do), not a week goes by without some kind of new language variant passing through.

This isn't anything specific to Go or its dubious heritage. I feel much the same way about all kinds of other things where other people are in full fanboy or fangirl mode for them. I require quite a bit more "activation energy" to start caring about this sort of thing. Merely existing is not sufficient. It has to do something specific which represents a net improvement to my current situation.

Given this sort of behavior, how do I pick up new languages? That's easy. I pick them up when there is some clear need to use them. I'll attempt to summarize my initial encounters with writing things from scratch in some programming languages. In the case of C++, there were several false starts. This is roughly in chronological order.

Turbo Pascal: I needed to write a DOS TSR - that is, a program which stuck around in the background doing stuff. I had been using QuickBASIC up to that point, and it made binaries which were far too fat and annoying to be proper TSRs. TP let me do systems stuff like calling interrupts much more cleanly.

C++, the first time: I was given a (legit) copy of Turbo C++. I installed it and started poking at it. I was annoyed by it, and let it rot. It did nothing for me.

C: When I started getting into doing stuff on Unix boxes, I started messing with existing software to add features or modify things to suit me. That software was written in C, so I had to pick up bits of it. After a year or two of this, it became clear this was the way to move forward with some other projects, so I switched to C on Linux as my default, abandoning Turbo Pascal on DOS.

C++, the second time: I had a couple of classes where they made us use some kind of Borland C++ compiler on Windows. I got most of my labs to work, but it was awful. There was a stupid amount of cargo-culting going on, and the professor was one of the biggest offenders! When the demo code which comes with your textbook segfaults on shutdown and you have to remove the destructor, something is very wrong. (I wish I still had that code now, so I could use my current knowledge to figure it out). I didn't use C++ outside of school, so my default remained C.

Perl: I needed to write a system service for NT (like a Unix daemon) which would listen for incoming connections and lob lists of users, groups, and user/group membership lists at the client. The only thing I could reasonably get installed without investing any money was ActiveState Perl, so I held my nose and glued a bunch of examples together: something to listen on a socket, something to handle requests, and something to poke the Win32 SAM lookup APIs. It worked enough to do my demo, and that was that.

C++, the third time: I was assigned a starter project to clean up some log files. The three approved languages were C++, Python, and Java. Nobody in their right mind wrote that kind of stuff in Java. They wanted me to use Python, but I didn't want to try to tackle the (huge) corporate code base and proprietary APIs while also trying to pick up another language. Their particular flavor of C++ was the most like what I had been doing for years at that point (C), so I went with it. This project wound up being killed after getting mired in code review hell, and I soured on the dev thing for a while at that job.

Python: I joined a project which was run by people who really liked LAMP stuff. I didn't have much choice in the matter. I wound up debugging some really hairy problems, like when they mixed threads and forks in a single program. (DO NOT DO THIS.) It left a bad taste in my mouth.

Java: I had some classes which used Java, since the world had changed and C++ was no longer the shiny thing it once was, according to the school. So, I had to do a whole bunch of labs, and dealt with such lovely things as Hibernate, JSP, servlets, Tomcat, and more. My senior capstone project managed to deliver something working because I just took it upon myself to drive the coding side of things. We did a successful demo using a real web server on the outside world whereas most people just used slides. I knew it would be evil long before the first class started, but it was part of my degree program so I just sucked it up and got through it.

C++, the fourth and final time: I decided to extend an existing C++ project which did some janitorial work on a production service. It had some dubious constructs which made things tougher than they had to be, so I had to do some re-plumbing of stuff to make it possible to extend things sanely. This time around, I didn't get caught up in dev hell, and instead had a kind, understanding reviewer who wanted me to "get it". I did, and wound up embracing C++ and went on to write copious amounts of code in the official corporate style over the next 3 or 4 years. It became my new default, even outside of work.

So where does this leave me now? Well, for new stuff, if it's the kind of software I usually write for myself (scanner, fred, web store, generator for my posts and the books, and so on), it's probably C++. If I'm dealing with really low-level system gunk like a kernel driver or similar, then it's C. Anything else would be silly.

If I'm bored and just want to fiddle with some values in an interactive mode, I usually start up (gasp!) python. It's actually pretty nice for that. It reminds me a little of "intermediate mode" in BASIC on my old Commodore 8 bit machines: type a command, get a result, lather, rinse, repeat.

Other programming languages don't figure heavily into my day to day operations. There just isn't a reason to bother with them most of the time.

Now, if you think any of this is a declaration of how anyone else should behave, you're wrong. This is simply a description of my own particular foibles, and I expect few people will be compatible with this way of thinking.

So, before you rage, read that again: this is just me. Your favorite programming language is still your precious little flower. It's just not my precious little flower... right now. Check back with me in a few years and see if my requirements have shifted, and if my preferences have shifted with them.

Reacting to actual needs? That's sensible.

Jumping at everything shiny? That's just nuts.