Category Archives: rants

Learning Functional Languages

I took it upon myself to begin learning Haskell recently. This isn’t my first adventure into the realm of functional languages; I spent some time a year or two ago learning Erlang as well. As someone who spends most of their time developing in (and quite frankly, enjoying) C and/or C++, it might seem like a strange foray into bizzaro-world. However, I don’t have any definite or particular interest in the functional paradigm, only in the sense that it offers a new perspective on the way software is built, and perspective is good.

From the imperative perspective, functional programming is a bizarre and imposing approach to writing programs. These languages are all concerned with things like side effects, mutability, and state, and its often difficult to identify the advantages of functional languages over more conventional ones with respect to these concepts and others. In addition, they often have the stereotype of being less practical and more academic (translation: interesting but useless) technologies – although this is not necessarily the case.

I’ve been learning Haskell from this tutorial, which I recommend not only for its technical completeness, but also the author’s sense of humor. I’m not at the stage yet where I was with Erlang (which was, actually building programs), but I could be if I spent a little more time on the subject. So far, one thing I’ve found to be an incredibly useful aspect of Haskell is:

  • Its clean, rigid syntax

However, the thing that probably drives me the most insane about Haskell is:

  • Its clean, rigid syntax

Make no mistake, that when you begin building some application in Haskell, your code will look pretty much identical to what is produced by your coworkers. If you have some sort of writing style, or you don’t like the default formatting and structure of the language, too bad. It sort of forces you into structuring your application a certain way, and to be honest, this is invaluable when you’re collaborating with others – you should know what to expect in their work.

Haskell people will also argue that the immutability of variables, the brevity of code for tasks, and stateless program design will reduce defects as well in the final product. I can’t find any numbers to back that up, but that seems like it might have a reasonable amount of truth to it. The tradeoff being, spending five years finding a developer who is an expert in Haskell.

I stopped learning Erlang at the time because I couldn’t stand the syntax; Erlang has a lot of very strange characters and formatting in the language. Certainly, you would have to write considerably less code than for an equivalent program in C++, but I’d use Python in that case any day over it.

Anyways, stay tuned for more feedback about Haskell. Should be an interesting adventure.

Advertisements

COBOL and the collapse of the Canadian government

Sheila Fraser made an announcement last week which brought an extremely important issue onto the national stage: the Government of Canada’s IT infrastructure is about to implode. In fact, it’s so bad that key government services may shut down because the systems behind them are in such bad shape.

Apparently the National Immigration Program runs on COBOL and a database system which has been dead for over twenty years. Also the Department of Public Works’ pay and pension system is about to collapse. And the Auditor-General says it’ll take billions of dollars to fix.

The problem here is that the government never implemented any sort of continuous maintenance and update strategy for its technical infrastructure. And there apparently isn’t any sort of reasonably competent department to run such a program. The fact is, if your organization (or, government) is going to rely on an IT infrastructure for all its day-to-day operations, you can’t let it rot. You need technically competent people to maintain the system. You need to keep up-to-date with changes in the industry. And you need to investigate how newer and better tools will make the continual growth and expansion of your IT services manageable. Otherwise it’ll crumble. The situation out in Ottawa is exemplified by Stockwell Day’s brilliant statement:

“As you know, with technology, there are always people who are saying you should have newer and better.”

Apparently the problem with software is that it needs to be updated every forty years or so. Other government tools such as cars, pencils and coffee makers don’t suffer from the same issue.

My biggest concern isn’t the cost to fix the issue, it’s potentially more serious. If the Government of Canada can’t keep its legacy systems up-to-date (we’re talking almost half a century old technology here), then how is it supposed to protect sensitive information about itself and the citizens of the country from malicious hackers and other threats?