Programming

Elm apps, require that we define a single type, usually called Msg, to host the type of messages that form a major part of the ‘The Elm Architecture’. This single type is usually a custom/variant type, and because it must host all of the messages that the app may consume, it can get rather large. This leads to a large update function. I do not think this necessarily a bad thing, but many beginners to Elm baulk at the idea of large functions, and so they seek solutions to break up their Msg type. The basic idea is to make your messages hierarchical, so you have a variant that itself contains a variant. The question is how best to split this up. I’m going to explain why the first instinct in this is usually wrong, suggest a slightly better way, and end up by claiming that the main thing is to remain fluid in your datatypes so that you can best represent whatever the current situation is, rather than cling to an old design for earlier requirements. ...

A feature that is semi-regularly requested in Elm, or at least discussed is the issue of type-classes. Type classes are a means in Haskell of restricting polymorphism, which then allows you to write more generic functions that you would otherwise be able to. In fancy words that means that type classes support ad-hoc polymorphism, but you can forget about that. I’ll start off with a simple example, then show how you could acheive a similar result without the type classes. Finally I’ll use this to argue that therefore type-classes are a limited form of meta-programming. ...

Could meta-programming be considered harmful? Probably not, but like all features of programming languages it will not automatically improve your code. Because I intend to talk in some future posts a little about meta-programming in statically typed languages I want to first lay down some caution. In other words, I do not wish for it to be taken as granted that meta-programming is a solid win, a feature that needs to be added to statically typed languages. ...

I’m going to go a little nostalgic and explain my journey through thoughts on statically/dynamically typed languages. I’ll arrive at the conclusion that (some) dynamically typed languages have mostly nailed meta-programming. Whilst it still seems something of a todo for statically typed languages. Dynamically/Statically typed languages and productivity When I first started programming, for a while, I was a card-carrying member of the strongly, statically-typed languages fan club. I didn’t really understand why anyone would ever wish to remove type type-checker which I saw as a major help to the programmer. In other words, I couldn’t really understand why anyone would wish to write code that did not pass a static type-checker. ...

Update We have started using Constructor which allows us to do exactly this. It doesn’t yet have a ‘public’ issue board, but I believe the developers are working on it. We are a three person team and we use github to store our source code. We also use github to track our issues. There is a missing feature that I’ve never seen in any bug-tracker: relative prioritising of issues. We typically have a meeting after a sprint of work to decide what to work on next. During this meeting we (perhaps after creating some new issues) mark several with the tag “priority”. But what I really want to do, is order the issues by priority. ...

I am a paid up member of the immutability appreciation society. I believe programming in an immutable language reduces bugs, as well as potentially helps the compiler optimise your code (though perhaps at the cost of not being able to do similar optimisations yourself). I also rather suspect that immutability has a role to play in concurrent code, but that’s somewhat irrelevant for today. However, although I feel that immutability reduces bugs, I do not think of it as a strict subset. A strict subset would imply both that, some bugs introduced using a mutable language are simply not possible, or at least less likely when using an immutable language and also there are no bugs introduced using an immutable language that would be impossible or less likely when using a mutable language. It’s the second part I disagree with. I think most immutable programmers know this, but it’s worth reminding ourselves of this. It’s very easy to get comfortable in our land of the fewer bugs. ...

I’ve long been interested in psychology. I find it fascinating the ways in which our brain is capable of tricking even ourselves. Even if some results are difficult to re-produce in the real world, the fact that they work in a laboratory setting is interesting enough. I’ve long thought that many cognitive biases have a strong application to software development. If I had the time I’d love to create a catalog of cognitive biases and their particular application to software development. In lieu of that, I’ll settle for blogging about the odd one. ...

Since almost as long as compilers have been around there have been attempts to store source code as something other than plain text. Various different formats have been suggested but the actual format is not important the general idea is to store the abstract syntax tree of your program rather than text that can be parsed into the abstract syntax tree of your program. There are several reasons you might wish to do this, and several disadvantages as well. But I wanted to speak today about one particular part of this. Comments. ...

This morning someone posted their snake game implementation to the Elm discourse asking for feedback on their implemenation. I thought the implementation was pretty fine, I had one structural comment but for the most part I’d be pretty happy to have to work on something from that code. My complaint though was that the author’s source code comments were mostly pointless, at least none of them were (yet) downright counter-productive, but it’s easy enough for comments to become so. I was reminded of an excellent student of mine who wrote a blog post (as part of their coursework) entitled ‘Delete this comment’ you can find it here. ...

Defensive programming is generally defined using terms such as ‘impossible’, one definition on the c2 wiki has Defend against the impossible because the impossible will happen. In addition there is also the idea to do the right thing. Such a definition is obviously (and intentionally) vague. The question is, what is the right thing? That’s always situation specific and it can be a difficult part in programming. That’s what I find interesting here, the programmer can easily make happen whatever we want, but it’s difficult to decide what we should want. That’s difficult to follow so let’s try an example. ...