An interesting thread came up on the Elm discourse today. It concerned the point of the unit type () (which is also the only value of type unit). The question was do we really need this? Couldn’t we use the empty record {}. This then provoked the question of whether we even need tuple types at all, why not just always insist on record types? I find it quite interesting that even in Elm a language that is far more frugal with its syntax than most, you can still find parts of the grammar that have questionable use. I think getting rid of both the unit type and more generally tuples would be perfectly doable, though I doubt it will happen since it would be somewhat inconvenient for most since tuples are even used as the results of both the init and update functions. Hence all programs and probably a large proportion of libraries would need to be updated for the change. Nonetheless it’s pretty fun to imagine the language without tuple types. ...

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. ...

Just after I wrote about lambdas in Elm suggesting that they were not particularly useful and if we had a mind to we could remove them from the Elm language (very unlikely to happen since I think it would cause too much anger within the Elm community), I read on the awesome Python newsletter a post regarding lambdas in Python, specifically 5 uses of lambda expressions. The author doesn’t quite have a main point, but it seems to be that lambda expressions are useful and you should use them in your Python code. ...

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. ...

Jeroen Engels of elm-review and elm-radio fame has written an excellent blog post regarding the safe removal of dead code in a purely functional language. The main take-away is that because there are no side-effects, all code dependencies are explicit. Because of this it’s relatively easy to determine that code does not depend on other code, and therefore some code is dead (ie. unused), and can be safely removed. You can extend this idea, and say the order that code is executed in, is only dependent on the explicit dependencies between code. Two days ago I wrote about compile-time laziness, I showed that the following code: ...

As I’ve mentioned many times on this blog Elm has a famously pretty frugal syntax. There are obviously positives and negatives from this. A potential negative is that you simply cannot write the code the way you would wish to, which presumably might mean that the code you do write is inferior, since you obviously had some reason for wishing to write it another way. Still, in general I think the positives outweight the negatives, and have even argued in the pass that Elm could consider removing some syntax, specifically lambda expressions and if-then-else expressions. Though it must be said I’ve also argued for the inclusion of the odd bit of new syntax. ...

Following on from yesterday I think there are various other ways in which a compile-time elm-to-elm optimiser could improve the performance of Javascript code output by the Elm compiler. It goes without saying that this does not necessarily have to be done as a separate tool, it could easily be incorporated into the Elm compiler itself. It is just potentially a lower barrier for entry to do it the separate tool way. It’s also a little easier to describe. ...

In certain circles in the Elm community it is seen as more ‘Elmish’, that is more idiomatic, or more desirable to write code using functions to combine/inspect common datatypes. So this code: Maybe.withDefault 0 mInt is more desirable than the following code which uses a case expression to achieve the same end: case mInt of Nothing -> 0 Just x -> x One question that arises, is does one compile to more efficient code? Let’s test this, we can easily write the following into an elm file and compile with optimisation turned on: ...

I have remarked before that Elm is pretty frugal when it comes to syntax. Lambda expressions though are a sort of staple of functional languages. For no particularly good reason a language is not seen as functional if it doesn’t have lambda expressions. It’s even possible to see phrases attributing elements of functional programming that have found their way into mainstream imperative languges such as Python, and it often includes lambdas. So lambda expressions are somehow seen as a quintessentially functional feature. ...

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. ...

Elm is pretty frugal when it comes to syntax. This has many benefits, one oft cited is that it helps beginners get started pretty quickly, in particular after learning the syntax for ten minutes or so a beginner can understand most Elm code out in the wild. I think a more compelling advantage is that the lack of syntax reduces the ways in which the same problem can be solved. It of course doesn’t eliminate this entirely, some people like to use |> and others much prefer <|, or even just to use parentheses. ...

There is an old but excellent post from Joel on Software which defends hungarian notation. Briefly hungarian notation was mis-applied in many places, and so something that wasn’t nearly as useful as hungarian notation was adopted and then (rightly) despised. That post is great and worth reading if you haven’t, but it is also quite long, so I’m going to first of all explain the correct hungarian notation that is useful, then the incorrect despised hungarian notation. Finally, I’m going to end by discussing how the old despised hungarian notation relates to Elm maybes. ...

I want to explain a minor tweak to Elm’s import syntax, that I cannot find justification for. Before that I’ll explain a syntax improvement that I at first thought was a no-brainer, but then came to realise was hard to justify, and certainly not a no-brainer. I’ll end by saying that despite the fact that I cannot find sufficient justification, I still think my minor syntax tweak should be adopted. ...

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. ...

I was reading a post found on Hackernews. Its main point is that shorter error messages are superior because the main problem is not obscured by other, mostly irrelevant details. I think it’s far from a universal truth, but some of their examples were pretty compelling. It got me thinking about Elm’s error messages. Elm’s compiler error messages are famously great. However, they are not typically short. This is a major boon for beginners. The compiler often explains in detail why it was not able to type check your entire program and possible fixes. So for beginners this is a major boon. For more experienced users however there is a lot of information being printed that is not helpful, mostly because we’ve seen it before. ...

There was a fairly long thread on the Elm discource regarding a proposal to add extensible custom (union) types to Elm. I thought I would try to summarise a little, the current status. In brief, I think currently the cons outweight the pros, but most of the cons are uncertainty rather than definite disadvantages so it is possible that some further work could tip the balance. I’ll describe here very briefly what an extenible custom type is, and then the pros and cons, why I think the cons outweight the pros at present, and finally a path towards overturning that. ...

Elm famously has excellent error messages, particularly for type errors. When the compiler detects errors in multiple files it outputs a little switch between which looks like this: `This `NeverEditable` value is a: Field.Editable But `withEditable` needs the 1st argument to be: Int Admin.Config.Orders.OrderTotals ↑ ====o======================================================================o==== ↓ Admin.Config.Basic -- TYPE MISMATCH ------------------------------------ src/Admin/Config/Basic.elm Although it’s a little redundant to repeat the filename (technically it’s a module name in the separator but since module names must line up to the filename it’s still redundant), I find this pretty helpful. Just one thing I would change, for the last error message, because you’re not at that point switching between error messages you don’t get a module or filename at the very bottom of the output: ...

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. ...

There was a thread on the Elm discourse regarding the communcation of expectations when contributing to Elm. It’s an interesting thread albeit mostly quite negative, but it’s still useful to hear people’s frustrations and view points. I wanted to focus in on one particular view point that seems pretty common. This is a direct quote from the thread: Thinking this a bit more, this actually sums up clearly the difference between Elm and other open source projects: ...

In Elm comma separated lists (and records and tuples) are traditionally written with the comma on the next line preceding the next item like: elements : List (Html msg) elements = [ title , introduction , mainImage , mainContent , conclusion ] I’m quite used to this style from my Haskell days. Although the comma-at-the-start feels a bit unnatural at first, I think after a while you start to see the benefit of having a nice visual clue which distinguishes a contination of a previous item with the start of a new item. Another benefit in my mind is that it means the items naturally align even though each line has the same indentation. ...

I’ve always indented Elm with four spaces. To my mind this looks nicer than two or eight spaces. It also seems to be about the default, relatively common in code seen in the wild. Recently I’ve found a really good reason to prefer two spaces, but I still cannot quite make myself accept it. I thought I would detail it here anyway. The ‘problem’ with four spaces comes when you want to indent nested comma separated entities. So a list of lists, or a list of record types. Suppose you have a list of people: ...

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. ...

In Elm it’s possible to import a name from a module in two ways, you can either import the module and expose the name, or import the module, perhaps aliasing the module name, and then qualify the use of the target entity. This seems common in documentation, I’m not sure why it seems to be that having unqualified names “looks better”, and there is certainly a sense in particular for the elm/html library that the resulting code more resembles the HTML that is essentially being described. ...

Elm has followed many other languages in equating a file to some form of encapsulation unit, in the case of Elm this is a module, much like it is in Haskell, Java used a class. In Java it is possible to define a nested class, and in most forms of the ML family of languages (SML, O’caml) you can define nested modules. In particular there is no reason why a single file need define one and only one module. ...

We have an application that uses a login token which expires. This is for an admin panel. The login token expires after a number of hours, after which you have to re-login. Initially this expiration time was set to 8 hours. I lobbied for this to be changed to 12 hours, but not just because it is more convenient, also because I think it might increase security, or at least it’s not clear it reduces security. ...

Elm is famously pretty conservative when it comes to adding language features/syntax. In general I appreciate this, but or-patterns are something I have longed for for a long time. I feel they can drastically increase clarity. However I do understand that a ‘better’ solution may arrive and we will all be glad Elm held off on implementing or-patterns. Still I feel that in this case, it’s worth the risk, or-patterns are used in a few other languages and to good effect. ...

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. ...

Elm has extensible records, you can write a type like { a | x : Int } which means a record type that has at least a field named x of type Int but may have other fields as well. The general advice seems to be not to use these for data modelling but instead use them to narrow the type of function arguments. See this Richard Feldman talk and, for example, this Charlie Koster blog post. ...

Alex Korban has released another version of his Elm Catalog. I think this is both very important work and very well done. This century it’s become popular for languages to include a package/library manager. I’m not quite sure when this started to become popular but certainly in the 90s such package managers were not common. This lead to many different ways to install libraries, and mostly including a new dependency was a chore at best. So the introduction of package managers as part of a language’s eco-system has been a major boon. ...

I’m going to talk about the common-language-runtime, and use this to contrast Purescript and Elm. Although I have in mind the .Net common-language-runtime, I’m more talking about the general concept. Specifically, it’s not just the common platform used as compilation target, but the idea of interoperability, in particular libraries that can be consumed by different languages so long as they adhere to the common-language runtime. Similarly whilst I’m contrasting Elm to Purescript, I’m more contrasting narrow versus broad scopes. ...

The builder pattern seems to be prettty popular in Elm, here is an elm-radio episode dedicated to it. The builder pattern To be clear, the builder pattern is used where you have a data structure, usually a record, which allows for a reasonable default and can be customised by chaining modifier functions. A simple example is best to describe this. Suppose you have number inputs in your application. You might have some module tasked with rendering a number input, but the number inputs themselves can have various settings, so you have a NumberInputConfig type which controls both the view and update of a number input. ...

Update: A couple of experiments that seem to give contradicting results for which case style is better for actually recognising identifier names: Camel > Snake and Snake > Camel. Often when naming entities whilst programming we are forced to combine several words into a single lexical token. So instead of writing my function we have to call it my_function(snake case) or myFunction(camel case), or perhaps some other contortion, but these are the two most common. ...

I have been reading through some of the source code from the requests library. This is one of the more well-known, well-used, well-loved, and well-praised Python libraries I know of. I came across some conditional code which I personally would refactor. A first refactor I’m pretty confident about whilst a second I’m less certain is an improvement. I’ll detail them both and welcome any comments anyone has. A specific example of this kind of conditional comes in the adapters module specifically the cert_verify method. Here is the code in question, slightly snipped for brevity: ...

I wanted to compare the manifestos for the local elections so I did a quick search but it came up with nothing. I was hoping for a simple page somewhere that simply listed where to find all of the parties’ manifestos. To save you the bother, here is where to find the manifestos of the five parties listed on my postal ballot form (in the order that they are listed), all of the homepages were found with a simple google search: ...

Bill the lizard has an excellent post describing an interesting puzzle as to the most desirable full house in a game of poker. The rest of this post depends upon you having read that puzzle so you may wish to do that now, or skip this post. I think this represents an instance where the mathematically correct answer is not correct for other concerns. To be clear, I think the given answer is the mathematically correct answer, and the blog post linked above never suggested to answer anything other than that. In addition, there isn’t really any action you can take regardless of which full house you think is better to have, the difference in the odds is small enough not to have any real-world applicability. ...

Developing a small web application I recently had reason to upgrade from Python 3.4 to Python 3.6. The reason for the upgrade was regarding ordering of keyword arguments and not related to the bug in my test code that I then found. I should have been more careful writing my test code in the first place, so I am writing this down as some penance for not testing my tests robustly enough. ...

I have written before about Flask and obtaining test coverage results here and with an update here. This is pretty trivial if you’re writing unit tests that directly call the application, but if you actually want to write tests which animate a browser, for example with selenium, then it’s a little more complicated, because the browser/test code has to run concurrently with the server code. Previously I would have the Flask server run in a separate process and run ‘coverage’ over that process. This was slightly unsatisfying, partly because you sometimes want coverage analysis of your actual tests. Test suites, just like application code, can grow in size with many utility functions and imports etc. which may eventually end up not actually being used. So it is good to know that you’re not needlessly maintaining some test code which is not actually invoked. ...

I come from a functional programming background, so I a lot of love for functions and so-called anonymous functions or lambdas. However, I have realised that I don’t make use of Python’s lambda syntax much, and I wanted to articulate why. This may mostly sound pretty negative towards lambdas, but bear in mind I’m certainly not against lambdas in general. A lambda expression could always be avoided by simply defining the function in question. So the question becomes when is a lambda more readable than a definition? That is almost always because the function you’re attempting to create is so simple that the definition syntax gets in the way. It is often used when the function in question is going to be used as an argument to some method. For example the sort method on a list takes as argument they key to be used when comparing the elements. So if you have a list of items and you want to sort them by their prices you can do something such as: ...

Looking through the code of an open-source Python project I came across code that amounts to the following: host_name = self.connection.getsockname()[0] if self.server.host_name is not None: host_name = self.server.host_name This looks odd because if the condition is True then we forget about the host_name derived from the call to self.connection.getsockname. However it could be that that call has some side-effect. Assuming that it does not we can re-write the above code as: if self.server.host_name is not None: host_name = self.server.host_name else: host_name = self.connection.getsockname()[0] Or even, if you prefer: ...

More than a decade and a half ago, Kragen Javier Sitaker wrote a blog post isinstance() considered harmful, a lot of which I believe holds up pretty well today. It’s well worth reading it in its entirety but the gist is that rather than testing a value against a specific type, you generally wish to check that a value confirms to a particular interface. Or if you prefer, using isinstance is imparting nominative typing in a language where duck typing is the convention. ...

Introduction Typically routes in a web application that require login are explicitly marked as such. Whilst routes that are open to general (anonymous) users, are left unmarked and hence implicitly do not require login. Because the default is to allow all users to visit a particular route, it is easy to forget to mark a route as requiring a login. I’m going to show a small pattern for making sure that all routes in a web application are explicitly marked as either requiring login or not-requiring login. As an example this will be done in a Python, Flask-based web application using Flask-Login but the general idea probably works in at least some other Python web application frameworks. ...

I have a small niggle that comes up in my Python programming. I’m going to describe it and propose a possible addition to the Python programming language that would mostly solve the problem. However, I have not thought through this language modification at all thoroughly so at the moment it’s just a germ of an idea. It wouldn’t be a major change or fix any important problem in any case, it would just solve my own personal peeve. ...

In many cases whilst programming there is a decision to be made as to whether to store some state, or (re)caluate it as and when needed. Obviously every situation is different and therefore there is no one answer which fits. In this post I’m going to attempt to explain the distinction and the benefits/drawbacks of either approach. I hope that just remembering that this choice exists will force me to make an explicit choice, such that I may think about it a bit more. ...

Dougal Matthews has written a blog post detailing how Vulture can be used to find some dead code. For me this was an important reminder not to rely on coverage analysis to detect dead code and remove it from the your maintenance burden. More generally, whilst I adore automated analysis tools that assist the developer in maintaining their code, such automated analysis can give a false sense of completeness, or lead to the developer believing that their code is “good enough”. It is not a problem I have any solution for though. The rest of the post will try to illuminate this view point through the example of dead-code removal. ...

Introduction I do not aim to answer the question in the title more raise the question. The question kind of implies that dynamically typed languages are more productive in at least some ways. It does not imply that statically typed languages are less productive in general, or the opposite. Before going any further, I’m talking about the distinction between static and dynamic typing which is not the same as strong vs weak typing. Static means the type checking is done at compilation before the program is run, whilst dynamic means types are checked whilst the program is running. Not the same as weak vs strong typing and also not the same as explicit vs implicit typing. ...

Selenium is a great way to test web applications and it has Python bindings. I explained in a previous post how to set this up with coverage analysis. However, writing tests is non-trivial, in particular it is easy enough to write tests that suffer from race conditions. Suppose you write a test that includes a check for the existence of a particular DOM element. Here is a convenient method to make doing so a one-liner. It assumes that you are within a class that has the web driver as a member and that you’re using ‘pytest’ but you can easily adapt this for your own needs. ...

Method Cascading Vasudev Ram has a thoughful post about method chaining/cascading that I picked up from planet python in which he basically argues for the use of method cascading. I’m going to disagree. Essentially, I simply don’t understand any benefit of using cascading. It’s a nice post though and includes some references to other method cascading links. Method chaining is the writing of multiple method calls directly after one another, usually on the same line, such as (to take Vasudev’s example): ...

Test First and Mutation Testing I’m going to argue that mutation testing has a strong use in a test first development environment and I’ll conclude by proposing a mechanism to link mutation testing to the source code control mechanism to further aid test first development. Test First Just to be clear, when I say ’test first’ I mean development in which before writing a feature, or fixing a bug, you first write a test which should only pass once you have completed that feature. For the purposes of this post you needn’t be doing that for every line of code you write. The idea here applies whether you are writing the odd feature by first writing a test for it, or whether you have a strict policy of writing no code until there is a test for it. ...

Placement of Python Import Statements Pep 8 specifies that all import statements should be “put at the top of the file, just after any module comments and docstrings, and before module globals and constants.” However, it does not really specify the logic behind this. I’m going to try to articulate some reasons to have import statements somewhere other than directly at the top of the file. I’ll also state some arguments for having such import statements at the top. ...

Update: Flask+Coverage Analysis In a previous post I demonstrated how to get coverage analysis working for a Flask web application in a relatively simple manner. In the section “At then end of your tests” I stated that you needed your tests to clean-up by telling the server to shutdown. The end of your test code would look something like this: finally: driver.get(get_url('shutdown')) ... This could have made things a little fiddly since your test code would have to make sure to access the shutdown route exactly once, regardless of how many tests were run. ...

Flask + Coverage Analysis This post demonstrates a simple web application written in Flask with coverage analysis for the tests. The main idea should be pretty translatable into most Python web application frameworks. Update I’ve updated this scheme and described the update here. tl;dr If you’re having difficulty getting coverage analysis to work with Flask then have a look at my example repository. The main take away is that you simply start the server in a process of its own using coverage to start it. However, in order for this to work you have to make sure you can shut the server process down from the test process. To do this we simply add a new “shutdown” route which is only available under testing. Your test code, whether written in Python or, say Javascript, can then make a request to this “shutdown” route once it completes its tests. This allows the server process to shutdown naturally and therefore allow ‘coverage’ to complete. ...

Suppose you have a web service using a Python web framework such as Flask. So you wish to do a full user test by automating the browser. Should you use the Python bindings to Selenium or CasperJS? In this post I wish to detail some of the advantages and drawbacks of both. Python + Selenium Setup This is fairly straightforward. You are simply writing some Python code that happens to call a library which binds to Selenium. In order for this to work you will need to install phantomJS but using npm this is pretty trivial. ...

I am a software developer and mostly write about coding related issues. A lot of my posts are related to the Elm programming language (and related). Some are more general.