Custom Search

Tuesday, April 26, 2011

Personal choices in marketability

Having figured out what skills are going to be in demand, the next step is to filter in your personal attributes: Which things you enjoy doing - I assume you're a programmer because you enjoy it, we certainly don't do it for the fame or money. Which things you are good at - in particular, what innate abilities might be required for some choice, and how well you do at those.

My tastes and skills

Probably the single most important factor in what I choose to do is that I can't do design work involving graphics. I've studied the classics in the field, and can critique a design or UI, but my own work is ... well, the further I get from "bland" and "boring", the worse it gets. This blog is about as far as I dare go.

That ties into the things I enjoy doing. While I enjoyed working with web 1.0 technologies, the later versions bother me. JavaScript seems to combine the worst features of Perl and Java. Most of the web frameworks seem to be designed to let designers inject code into a design - which means they play to my weaknesses. I prefer toolkits that are designed for programmers - SeaSide and QtWui come to mind. But those aren't very popular.

If that hasn't make it obvious, I'll state it outright: I'm a picky SOB.  I don't want to work with things I don't enjoy: Windows, Java, C++, Perl. JavaScript I already mentioned not liking, which drags me even further away from doing client side work. I managed to survive the last 35 years with DOS and Windows work being at most minimal parts of my work; I suspect I can survive what's left of my career without having to deal with web client software, and only dealing with server software that I like.

As for what I like: languages that are obviously designed to meet some goal, as opposed to being a mere accumulation of features.  Anything that minimizes the boilerplate in the programming process is good in a language, but not an IDE. I want high-level data types, because those are sufficient for many tasks by themselves. Well done, they can be used for lots of things that aren't necessarily obvious. Finally, I consider a REPL to be one of the best tools for learning a language a beginner could ask for.

The languages I've chosen in the past are Scheme, Python, and Eiffel - and they are all fun. Python is fairly marketable. I like C - at least, the early versions, when it was designed to displace assembler as a systems programming language, as opposed to what it grew into as it was co-opted for ever more things, and that's also marketable, though I'd rather be writing Python.

Finally, there's what I'm looking for in working with concurrent programs. Basically, I want tools that I think of as relating to concurrency issues the way garbage collection relates to memory management. They should hide the details from me and at the same time prevent obvious mistakes. Rather than alloc (lock) and free (unlock) calls, I want high level protection mechanisms that can't deadlock or leave dangling locks. Preferably, a more advanced tool than CSP or variants. And of course, if I use something that needs to have access and/or modification protected without proper protection, I'd like a warning about it - at either run time or compile time.

So what am I studying now?

Well, this blog has chronicled my experiments with clojure. I chose that because it runs on the JVM, which has the potential of letting me write mobile applications, and meets my concurrency requirements. It also exposed me to the Java environment, which is nothing like the Unix environment I'm used to. The major difference is that - well, it's targeted at enterprise applications. Which is also the problem - the amount of boilerplate required to do simple things isn't noticeably less than to do those enterprise applications. I got over it, and created WAR files for a simple app, and got an education.

One of the problems with Scheme (and LISPs in general) is that they don't play well with others. Clojure solved that by integrating tightly with Java. But this makes it inappropriate for use in the Unix world. Writing a quick little hack to automate some task in a JVM-based language doesn't work very well - because the overhead of starting the JVM keeps it from being a quick little hack. People are "solving" this by making the JVM a server process you connect to to handle running your quick little hack. Basically, making that quick little hack part of an enterprise-class system.

With that in mind, I'm now studying Haskell. This is more a "learn it to improve your programming" than something that's directly marketable. I'll discuss why in the next entry.

No comments:

Post a Comment