For a long time I’ve been sceptical that using the file system to denote modules in a programming language is necessary. There are many good reasons to do this as things currently stand, but most of these reasons can, and arguably should, be solved with better tooling. For example from the post linked to above: why would we equate a file to a form of encapsulation? Why, would we wish to divide any application into a bunch of files in the first place. If you ask this question, you get a bunch of answers, but they mostly fall into two categories: 1. some vague notion about organisation and modularising your code and 2. it is easier to navigate whilst coding. I would argue that the first is nonsense, since no one is arguing against modularising code, only that the file system does not need to come into it. The second is potentially true, but rather speaks to a deficiency in your coding environment (text editor/IDE) rather than to the efficacy of using files to modularise a program’s source code. ...

I have previously described using sed to hack together a “poor-person’s functor” to overcome an awkwardness encountered when using elm-program-test to simulate HTTP events in the program being tested. To recap briefly the issue is that using elm-program-test, means that the update function returns an Effect rather than a Cmd Msg. When we apply this update function to Browser.element|document|application we need to create a function,perform, which translates the Effect type into a Cmd Msg. The reason we do this, is because for testing we instead create a function, simulate, that translates the Effect into a SimulatedEffect which can be simulated by elm-program-test and also interregated to test that we have produced the intended set of Effects for the test in question. ...

The following was written for a colleague who suggested I post it more publically, so here we are. We’re going to compare dynamically and statically typed languages in the context of writing admin panels for a variety of data stores. We assume that the data is actually stored within a relational SQL database, but that’s not important because we further assume that we need to send/receive JSON data. First a point of terminology This section is skippable, but defines the difference between the statically-dynamically and weakly-strongly typed axes. If you’re sure you know, you can skip this. ...

As many did, I participated in pre-tournament prediction competitions for the Euros. As I didn’t know much about most of the teams, I largely based my predictions on the Elo rankings. Elo ratings are essentially Chess ranking applied to international football teams. Each team has a numerical score which is increased or decreased based on the results of their matches, with the new ranking being based on what would have been expected from their current rankings. So for example if team A with a rating of 2000 plays team B with a rating of 1700, even a win for team A will not increase their ratings by a large amount, but even a draw would significantly increase the rating of team B. ...

In this post I’m going to show a good example of where laziness would work well. This is of course not an argument that lazy programming languages are somehow better than strictly evaluated programming languages. Rather what I wish to do here is answer the question, what is laziness good for? My example here comes from the justinmimbs/time-extra Elm package. The main purpose of this library is to provide a means for working with the standard library’s Time.Posix values. Functions are provided to calculate the difference between two time values, and also to add/minus a given interval from a given time value. So for example it provides a convenient way to take a given time value and add one day, or two hours, or six months. ...

Imports in most languages always seem like a bit of an add-on, a separate language to the actual language. Today’s post is a thought experiment regarding removing imports from Elm/Gren. Ultimately I think it’s probably worthwhile having the import statements there, but this is an interesting (and quick) thought experiment. If we remove import statements from the head of a module file the first thing to note is that a file then becaomes one module declaration line followed by simply a list of top level declarations. However, we would obviously need someway to refer to values and types defined in another module. ...

In a case expression when you want to match anything you can use the special pattern _ which avoids giving a name to something you aren’t going to use. However, you cannot do the same thing for type parameters. If you want to say “I accept any type here and I don’t return anything containing that type” you just have to use an unused ttype variable name. I think you should be allowed to “say what you mean” and use underscore here for that situation. I’m going to give a motivating circumstance in which this would actually be useful. ...

There have been a few proposals for extensible custom types in Elm, the idea is that they are somewhat analogous to extensible record types. In this post I wish to give a proposal for how to make custom types ’extensible’ that could play well with opaque types. The key point is that we need not focus on extensibility so much as the distinction between structural and nominal types. The slightly longer summary is to say that we can make custom union types structural types. This means that custom union type declarations are actually type aliases, just as record type definitions are in Elm. Two record types can share the same field, and thus it is trivial to make two record types one of which is a sub-type of the other. Similarly if custom union types are structural, and their associated definitions type aliases, two such custom union types can share a constructor, and again it is trivial to create two custom union type definitions one of which is a sub-type of the other. With this apparatus we can implement opaque types by choosing to expose a type either nominally or structurally, this gives us opaque types in which the underlying type can be a primitive type, a function type, a record type or a custom union type. ...

In this post I’m going to describe an awkwardness encountered when using elm-program-test to simulate HTTP events in the program being tested. I will then describe ML functors, a feature of the SML/Ocaml module system and show how these would solve the awkwardness. I’ll then show how it’s pretty simple to hack together a “poor-person’s-functor” and use that to solve the aforementioned awkwardness. An awkwardness when simulating HTTP for testing If you haven’t used elm-program-test to test an entire Elm program I recommend trying it out. I’ve found that it not only does the obvious part of helping to build robust tests for Elm programs, but also helps me structure the Elm program in a way that is better for testing, but also just generally better. ...

A throw-away comment on the elm-radio episode debugging in elm led me to re-evaluate one of my Elm practices. The comment concerned writing a type signature for values/names defined in a let-in scope. I’ve always done this in what seemed to be a traditional accepted practice. That is omitting pretty much any and all signatures on names defined within a let-in scope. If you look at most Elm code you can find on the web, in particular in the elm-lang guide, and in documentation for elm libraries, you will find the same style. ...

So I started this blog on the first of January 2021, and have blogged every single day since then. This is the 100th day of the year. That was the target I set myself, blog something every single day for 100 days. It seems impossible when you start out. At first you have a few topics you’ve always wanted to write down but never gotten around to it, but after that you think there is no way you will make it to 100 days. ...

This is mostly a post for myself to remind myself how to do this. I typically program on a remote server. I ssh in via the terminal and use tmux to manage sessions. I then edit code in neovim. This setup has a bunch of advantages and a bunch of disadvantages as well. One of the disadvantages is that I found it difficult to copy and paste from the tmux session in my terminal, to a completely different program running on my local machine, such as say my web-browser, or a chat client. ...

I had an issue with a computation taking much longer than might have been expected. It turned out to be caused by a use of the function greedyGroupsOf from the list-extra library, and it was solved by writing my own, naive, implementation. I haven’t quite gotten to the bottom of why the library version of greedyGroupsOf of is so much slower than my naive version, but the reason it is slower is mostly to do with DRY or don’t repeat yourself. ...

Previously I’ve written about immutability bugs which are bugs that are more likely in an immutable language than a mutable one. I think these are relatively rare, but they do exist. A good example has come up on the Elm discourse. The person asking the question wants to create new unique identifiers for items in their model. To do this you can simply keep a count of the number of identifiers you have thus far created. So you can do something like the following: ...

When I first started writing web applications I was using Python, and pretty much by default I started using a templating language to actually render the HTML. There are quite a number of templating languages (or frameworks) for Python, I tried a few and found them to be mostly much of a muchness, that is to say I couldn’t quite work out why so many existed since the difference between them seemed minimal to me. ...

Programmers are good at following rules. Rules make for reducing the number of decisions you have to make. That’s why we like rules such as “do not have functions that are longer than 300 lines of code” much better than “try not to have your functions too long, but sometimes you need it, so it’s a judgement call”. You might think that kind of rule gives you more flexibility, but just means you have to make more decisions. Should I really refactor this function it seems fine? That is easy to answer with the first rule, much more difficult with the second rule. ...

I mostly do not use if-then-else. Part of this is just a common Elm feeling of desiring to keep the language small, and since we have case expressions we do not really need if-then-else. But there is another part to it, I can order the branches anyway I like, I do not have to have the True branch first. Why would I wish to do this? My feeling is that as you’re reading code, there is only so much you can keep on your “stack”. So if you have a large branch of an if-then-else and a small trivial one, I tend to place the small trivial one first. ...

Sometime in the early part of the century, think about 2004, I saw a talk which analysed source code for defects. They had used, what was at the time fairly new, online source code repositories for open source programs. They determined that a piece of code was buggy if it was changed in a commit which fixed a bug. The authors analysed the code (which was all written in Haskell) to see if they could determine differences between ‘buggy’ code and ’non-buggy code’. I wish I could remember the authors or the title, but I cannot. ...

Yesterday I detailed a simple fragment of code that is untyped in traditional Hindley-Milner type systems (such as that employed by Elm), but which is a perfectly reasonable bit of code. I think of this as a minor irritation and quite easy to live with. I term it a blind-spot of polymorphism, because in general I find that polymorphic Hindley-Milner style type systems map pretty well on to the types of programs that I wish to write. Aside from the issue of meta-programming, but that’s quite a separate issue. ...

I am a huge fan of polymorphism and of accompanying static type checking. I find that, meta-programming aside, I mostly do not wish to write the kinds of things that are allowed by dynamic typing but disallowed by static typing. There are two exceptions, or blind spots to this and I thought I would detail the first one. Suppose you have a data structure with several Maybe fields: type alias Preferences = { favouriteFood : Maybe Food , favouriteBand : Maybe Band , favouriteColor : Maybe Color , favouriteNumber : Maybe Int , favouriteName : Maybe String } Now suppose you want to count how many of these are set: ...

Global variables have a bad name, mostly for good reason, but as with most things which are considered harmful some have uses, whilst others are symptoms of specific needs. Elm of course, being a purely functional language (by which I mean it is devoid of any side-effects), does not have global variables. It does have global constants. I feel like there is a missing feature in between these two. A global constant that is initialised on startup, perhaps by the program flags. ...

A small design decision has come up whilst developing with Elm on both the front-end and the back-end. The issue concerns an input that has some UI state, that doesn’t need to be transfered from front-end to the back-end (or vice versa). So I’m going first explain an example of an input that might have some associated UI state that you need to keep track of. Then I’m going to explain how you might represent this has part of a larger entity that needs to be encoded into JSON, and decoded from JSON to send to and from the front-end and back-end. ...

Pair programming is pretty popular and I’m a fan of it myself. It certainly feels as if there is a productivity boost from pair-programming, but I’m not entirely sure why. I have two theories: It’s not actually more productive it just feels more productive Pair programming actually just forces both of you to focus for the entire time you’re pairing. I tend towards the second explanation. I’ve paired sometimes for three hours, even if two people pairing are no more productive than a single developer, I suspect you might struggle to actually get those two developers to independently work solidly for more than an hour and half each, within those three hours. There is probably some combination of factors going on here. So maybe for example two programmers pairing are no more or less productive than two developers working independently, but pairing just forces both of them to focus on development for that period of time. Additionally, it’s more difficult to interrupt two developers pairing than it is to do so for either one independently developing. ...

I’ve spoken before about how great and liberating elm-format is. Once you cede control of the formatting of your source code, other possible features arise. Some of these could potentially take the burden away from the code editor tools. An obvious example would be the formatting of multi-line comments. When you change a multi-line comment, you often have to do a bit of formatting if you wish to keep the lines under a given character count. ...

I’ve started using Tailwind in anger now, and whilst I cannot say I’ve fully completed a project I have some thoughts on it. The first thing is, I do not hate it. I can see how for a certain kind of development team, in particular single developers who are going to do the styling themselves anyway, doing the styling in whatever language you’re using to generate your HTML is quite liberating. In particular I do not have quite the same fear I have of changing the styling. In large projects I find they get to the point where I start adding more and more class names to the elements so that I do not have to modify the current CSS but rather add more. That way I’m more confident of not breaking anything that is currently working. However, of course that’s not a sustainable path forward. So I’m pretty pleased that the tailwind approach is seeing me more willing to change the current styling. ...

So poleprediction is live, and not with too much time to spare since the first session of the new season was today with the first two practice sessions for the Bahrain grand prix. I technically didn’t need to be ready until tomorrow since that represents the first session for which we are predicting. Mostly everything has gone through without a hitch. A small problem with emailing, in which I cannot seem to validate my domain with mailgun, so I’m still using the sandbox which means I can only send to 5 pre-verified recipients. In addition one of them is, for some reason, not receiving the emails promptly, I suspect the issue is with Yahoo rather than mailgun, but I do not know. ...

I’m a bit surprised that I’ve not spoken about elm-format more on this blog. I did write a post which mentions it, but that’s more about Elm’s frugal syntax and how that facilitates a formatter. The benefits of a formatter are surprisingly numerous, and many are voiced in this elm-radio episode. The main thing I like is that the trivialities of how code should be formatted are taken away from me, that’s great, I can focus my attention on things that matter more. For the most part formatting decisions are just taken away from me. ...

As part of a discussion of back-end languages on the Elm discourse someone linked to a post (from 2014) regarding why everyone hates go by Nate Finch. The author links to a Paul Graham post regarding identity, and he links the two. So Paul’s post states that people form identities regarding religion and politics and that’s why it is so difficult to have a meaningful debate about either. Considering the alternative view point questions your identity. ...

I came across Dolt which purports to be “Git for Data”: Dolt is a SQL database that you can fork, clone, branch, merge, push and pull just like a git repository. Connect to Dolt just like any MySQL database to run queries or update the data using SQL commands. Use the command line interface to import CSV files, commit your changes, push them to a remote, or merge your teammate’s changes. ...

I was reading, briefly, the ecosystem of the Go programming language, mid-way through it states: A simple language: Consulting the spec, you can find out that Go has only 25 reserved keywords. Which got me first wondering whether that was a lot or not, a brief search and I found a bunch of places offering keyword counts. They’re not completely accurate, one place has Haskell in with 25 and another 55, but for the most part sound about right. One place has Elm with 25, I make it a few less, since that seems to be based on the exports from the Parse.Keyword module in the compiler, which has four or five exports which are not keywords. Nonetheless I was kind of surprised that Go and Elm were roughly on a par here, and indeed 25 is comparatively fewer than most languages. ...

I have managed to deploy a version to the server. You can login with your email address, which it sends a login code to. With this the last weekend before the start of the formula one season, I’m cutting things mighty finely. The major thing left to do before Friday, is make the site look nice, or at least reasonable. Give it some styling. My plan is to experiment with elm-tailwind-modules. ...

As Paul Graham’s blog has been replaying some pretty old posts so have I been reading them. A recent one was the python paradox. I think this applies pretty well to Elm at the moment. The Python Paradox was written in 2004 when Python, was still what one might call an esoteric language, that is, it wasn’t particularly popular. Whereby popular, we mean, used by many people, rather than liked by those that used it. Even at the time Python was very much loved by its users. Anyway the basic idea in the Python Paradox, is that programmers at the time did not learn Python because it was good for their resume, or it was good to find a job, because there were no python jobs. Because of this, it means that they were learning Python purely for the love of programming, and perhaps because Python seemed a bit different. Such programmers are nearly always good programmers, at the very least programmers with potential. Therefore companies should use Python in order to attract such developers, or at least require Python experience. ...

When first learning source code control, one of the mantras you will hear is: do not check commented out code into the repository I’m not sure why this is so loudly and vehemently exclaimed. I’m not even sure it should be a general rule. I realise that the code you are commenting out is available in the repo should you need it. But if so, you at least need to add a comment suggesting that some code that would otherwise be right here and commented out is available in the repository history, where to find it, and what it does. I also see that it adds to the general untidyness. But having said that, I just don’t see that it is so very harmful. On top of that there are clearly cases in which the rule should be broken for specific reasons, and I fear making such a vehement and strict rule against this will lead to it not happening. ...

When I started programming in Elm I was already pretty fluent in Haskell and quite used to using the $ operator, which in Elm is written as <| and sometimes called the ’left pizza’ operator. Somehow, over time I started to use the |> (right pizza) operator more and more. I think this first came about through the use of the builder pattern which very naturally maps the building up of a data structure which thus just got me comfortable with post-fix application of a function. ...

Sometimes it’s possible to make a kind of judgement of a technology without trying it out, and that’s useful. In this sense you’re judging a book by its cover, see Paul Graham’s pre-critique of Java. Because of the recent release of Tailwind modules for Elm I’ve been trying to judge the cover of Tailwind before I jump in and start using it. One way of judging a technology without trying it, is to look at critiques of that technology. Do those comments hit home for you? A prominent critique of Tailwind came up on my feed. I think the author of this critique just doesn’t share similar problems to the ones I typically face, and, I think are typically faced by Elm developers. So I’m going to go through most of the points in the critique article and roughly state why I don’t think they really apply for Elm developers. ...

I’ve written before about the prospect of compile-time laziness and using elm-review to act as an elm-to-elm compiler pass. Obviously one way to implement compile-time laziness would be to fork the compiler. As I said previously the use of elm-review to do this instead is something of a low-risk route into this. If this works out particularly well it could be translated fairly easily into an internal compiler pass. An internal compiler pass would have the benefit that the output of the pass might not necessarily have to be valid Elm. It might also be faster because it would not involve the expensive operations of unparsing and re-parsing the Elm code. ...

I came across a nice blog post regarding what a modern object-oriented programming language would look like. Not now, nor never really, having been an object-oriented programmer, I’m not going to comment on how suitable the proposed language features would be. However, I thought it was an interesting exercise, many of the programming languages I fail to appreciate have made similar mistakes of ignoring things we seem to have learnt pretty conclusively about programming languages. But that’s not what I wish to talk about, what I want to talk about today is the list of five non-negiotable features the author lists for any new object-oriented language (though I think he roughly means these would be non-negotiable features for any application programming language. Here are the five that the author lists: ...

Update We have started using Constructor which allows us to do relative issue priority ordering. The team are very responsive to feedback as well which is great. Recommended. For projects involving more than one person, I’m typically using github or gitlab, either has a pretty usable issues feature. For the most part with issues all I want is the ability to write some text, preferably in markdown. The ability to add screenshots is a major plus. The checkboxes are nice as well, but I’d be happy to write those myself in markdown, ie. I don’t really need the ability to check a checkbox with the mouse, but it’s a nice touch I guess. ...

Since this blog is being hosted on poleprediction and was originally meant to document some of the effort going into pole-prediction I thought I’d give a summary of where I am. What is pole prediction? This is a simple website for myself and a few friends to make predictions on the outcomes of formula one races (and qualifying sessions). The basic idea is that you guess the top ten drivers and are awarded points based on how well you’ve predicted them. These points are summed over the whole season. I’m the only one who has never won this. ...

I wrote a little about Tailwind CSS and then up on my feed popped an article which argues against tailwind. There are of course many reasons why two people can see what seems like the same information and reach different, and possibly entirely opposite, conclusions. But one quite obvious reason, when we’re talking about choices of technology, is that both have different advantages and disadvantages, and for some reason the two people are weighing those differently. Often it means that there is no ‘right answer’ in general, and unfortunately no way to combine the advantages of both. I sometimes think of this in terms of horiztonal and vertical. In this post I’m going to try to give an example of this distinction. ...

Back looking Paul Graham’s old posts from 20 years ago, and back to the language design one. There is a section on pitfalls and the first pitfall is about clients: This is just a guess, but my guess is that the winning model for most applications will be purely server-based. Designing software that works on the assumption that everyone will have your client is like designing a society on the assumption that everyone will just be honest. It would certainly be convenient, but you have to assume it will never happen. ...

It’s always worth examining the things you love for the reasons why. Could something you think is improving your productivity actually be harming it? Perhaps in a way that makes it feel like you’re being productive. Continuing the look at some of Paul Graham’s older posts, this one regarding object-oriented programming languages popped up on my feed. I think it stands up pretty well over the previous two decades. I wouldn’t say object-oriented programming has been debunked, but it has certainly lost some of its hype. I thought about Elm when reading the following third point: ...

I’m not sure if it is intentional or something to do with the RSS configuration on his site but Paul Graham’s RSS feed is going through a redux of posts from 2001. Some of these are interesting to read with the 20 years worth of perspective. Back in 2001 he thought that Java didn’t smell great, a point he made without trying the language. I think for the most part this post has stood up well to time other than the frequent use of Perl as a counter-balance. ...

There are two quite common pieces of advice for Elm programmers: Make impossible states impossible Avoid carrying state state in your messages Impossible states impossible The first is a call to carefully consider the types, mostly in your model and messages. So do not have a Maybe User type used anywhere where you consider it impossible for the value to be Nothing. So for example, you might have a message, such as the liking of a post, that requires a logged in user, because the request takes in the authorisation token: ...

I really like using Elm’s extensible records. There is a little debate about how best to utilise them. It seems clear they should be used for narrowing the types of function arguments. Narrowing the type of an argument to a function often makes it significantly more general. Here’s a quick example, suppose you have a User type in your application, you might have only a few of them, say a list of friends of the current user or something. So you might write a function to find a particular user in a list: ...

A Tailwind CSS package was announced on the Elm discourse which lead me to checking out Tailwind which in turn led to this post by the author of Tailwin. In it he makes an excellent point which I’m going to try to distill into a smaller form, though you’re well advised to read the entire original article. The author’s main point is that try as you might to separate the semantic concern of the HTML from the display concerns of CSS, one or the other will depend upon the other. In particular when using semantic classes in your markup, your CSS becomes a mirror of your markup structure. That means that if you change the HTML you likely have to change your CSS. Note, when I say CSS here, I mean, however you write your styles, using LESS, or Sass, or, if you prefer, vanilla CSS. ...

I use neovim to edit code and I’m mostly editing Elm code, so the missing feature I’m about to describe is missing from neovim and for editing Elm code, I don’t know of any other IDE that has this, but it wouldn’t entirely surprise me if, for example, the Elm plugin for the IntelliJ IDE has this feature. I also think this feature would benefit most programming languages. Anyway, this feature regards editing the imports at the top of an Elm file. What I really want to be able to do is just press some key combination to bring up a dialog which allows me to edit the imports from where I am, without having to scroll up to the edits. What I mostly do now, is just edit code as if I had already edited the imports, press save, which tells me what imports I’m missing (and also if I scroll up there, which imports are no longer necessary). So I guess this is not a terribly needed feature, but I find myself wishing for it quite commonly. ...

A while back a colleague and I started developing a Go based web framework, in which all the HTML was generated on the server. The client webpage was essentially a thin client that sent all messages, via a websocket, to the server which then returned the new HTML to be displayed. I had previously helped with a very similar technique done in Python. This general technique is being experimented with in various places, most notably in Phoenix Live View (an Elixir based effort), and Hotwire. ...

I noticed a sort of surprising syntax thing in Elm yesterday. When you think about it, it’s not all that surprising, but the question is, can it be made of use? So what I noticed is that the in expression of a let-in expression can itself be a let-in expression. So the following is valid syntax: ... let x = 1 in let y = 2 in x + y That’s because the syntax of let-in is let <def-list> in <expr> and let-in is itself a valid <expr>. So you can have as many let-in blocks chained as you see fit. Clearly, you can just delete the middle two in-let lines and you still have a valid expression. The question then is, what is this useful for? ...

A little tip for restricted text input in Elm. I’ve coded up the general idea in an ellie. This is really a general HTML tip, that I didn’t know existed, but for some reason I feel it works pretty well in Elm. The sitation is that you wish to restrict a text input to one of several possibilities, but there are many possibilities, so a select element is probably not correct. You may or may not wish to prevent any output not in the list of suggestions. What I didn’t know is that you can define a datalist element that has all the suggestions and the browser will interpret that appropriately provided you set the list attribute on the input element. As for invalidating it, you could use a pattern attribute, but I think in Elm you’re probably doing your own invalidation anyway. ...

A couple of decades ago Java was riding pretty high in programming language circles. It used the JVM, and back at the turn of the century it seemed that pretty much any language was going to end up being run on some kind of virtual machine. Two decades on and it’s a little difficult to say what the point of a virtual machine is, any longer. At the time, it was not easy to see that most of the software we use was going to be moved into the cloud, and whilst somethings are interacted with using smartphone applications, much of it is done using a web-browser. In a sense, the web-browser has replaced the need for a virtual machine. Most of us did indeed see the value in compiling one application and being able to run that application on different machines. Although the virtual machine concept never really paid-out that kind of cross-platform dividend. Even if so, you have to wonder whether it really was easy to develop a virtual machine for different platforms, rather than just develop a compiler-target for different platforms. ...

I will admit that before I tried my first programming language that used significant whitespace, I thought it would be horrible. I cannot remember why. I was thinking about this whilst reading An incomplete list of complaints about real code. In this the author doesn’t like signficant white space, here is what they say: I don’t like meaningful whitespace. If a tab means one thing and a space means another and they both print the same way (i.e., NOTHING, a big blank space on the screen), I’m not going to be happy. Also, if the amount of whitespace somehow controls branching or blocking of code, you better believe I’m not going to be happy when it trips someone up. ...

This post is pure, unadulterated bike-shedding, on the use of the | operator for extending a record type. As I’ve said many times before, one of the big draws of Elm is the clean, and very slim syntax. This has numerous benefits. One thing I never noticed before but has just been pointed out on the Elm discouse is that the bar operator | is used for two different, unrelated record-type meanings in Elm. The first is within a record type to indicate that the record is an extensible one: ...

When I started programming almost all programs were built using make, which is basically a domain specific language for writing down dependencies and compilation instructions. It seems to have mostly fallen out of fashion, I think largely because many languages take the hard part of figuring out what depends on what out of the hands of the programmer and just do the correct thing when you call the compiler against the single file which hosts the main (or equivalent) of the program. You could still use make files for things like documentation, but what people tend to do instead is just use a script, they don’t worry too much about dependencies for things other than compilation, because you can generally just always run everything. ...

This site is the blog of a developer of a site which is a game about predicting formula one results. So it is no surprise that I might frequent the site of Formula-E. What I want to talk about is evident on this site, if you go to the standings page, the one linked here is specifically for the ’teams’ standings, rather than driver standings, but the point is basically the same, although more pronounced because there are half as many teams as their are drivers. ...

Mostly notes for myself on how I setup nextcloud on Time4VPS. I was mostly following this article but found it was slightly wrong in a couple of places and missed out the odd thing. Install the dependencies sudo apt install apache2 mariadb-server libapache2-mod-php unzip sudo apt install php-gd php-json php-mysql php-curl php-mbstring php-intl php-imagick php-xml php-zip Download nextcloud Navigate here to find out the latest verison. Then (substituting in the latest version for 21.0.0): ...

Once again today I had a github issue close accidentally on me. I’m kind of at a loss for how this feature is designed, programmers use github, we’re happy being explicit, why make it ‘smart’? So to explain the issue. Suppose you have an issue, say issue number 312. If your commit message looks to github as if it has fixed the issue then it will automatically close the issue for you. What does “looks to github has if it has fixed the issue” mean? Good question. If your commit message contains something like “close #312” or “fix #312” then that will look like it is meant to close the issue. You can also replace the “#312” part with the actual url of the issue, it seems to work even if the url targets a particular comment on the issue rather than the whole issue, which is particularly vexing. ...

There is no denying that Go, the programming language is pretty popular. I’ve never understood this popularity. The most commonly cited reason appears to be that Go is simple/easy language designed for beginners. I don’t feel this at all when I have had to dip into Go. This post will necessarily be quite negative for Go, but try to think of this as the writing of someone who accepts that the popularity of Go is entirely warranted, and that they just cannot see the merits. ...

Dan McKinley has an interesting site based around a talk of his in which he extorts the value in choosing boring technology. He fully admits that this is something of a click-baity title, what he is really talking about is old known technology as opposed to new unknown technology. Having read the site I feel that it really has two separate points. The first point is about old, boring technology as opposed to new/exciting technology. The second point is about trading-off pain now for pain later. ...

I subscribe to the RSS feed for how-to-geek, it often supplies timely reminders. For instance, I was a user of the LastPass password manager, even though the interface struct me as strange, anyway how-to-geek alerted me to the fact that free tier users were going to have to choose between desktop and mobile devices as of March 16th of this year. Obviously lastpass decided that they didn’t want as many free users and were pushing those free users to either take their passwords elsewhere or upgrade to premium. That’s a fair choice to make, software developers need to eat and to do so someone has to pay the bills, freemium is tricky to get right. However, for me I was itching to try out other password managers anyway, so it represented a good little nudge to go ahead and do that. ...

A blog post popped up on my feed, which has the main point that tagged union types (called custom types in Elm) are overrated for implementing intermediate representations. To be clear the author is not saying that tagged union types are in general overrated, but their suitability for intermediate representations within compilers is just not that big of a win. It’s easy to see why tagged union types are thought of as perfect for internal representations of code in compilers. The grammar of a language kind of looks like a tagged union type already. You might represent the grammar of an elm expression in Elm’s custom types something like the following: ...

I think mutation testing is a pretty fine idea. The idea of mutation testing is to deliberately add a bug into the program and then check that the test suite catches that bug. We add the bug into the program by mutating a part of it, since if you change code that you believe is all correct, then presumably it cannot still be correct. Of course mutating the program can be mechanised and hence we can test many many mutant programs. Mutation testing does not test your program code, but how effective your test-suite is. Mutation testing is used to improve your test-suite. ...

Today I’m going to talk about a language feature that I think is missing from most languages. I know of at least one in which it exists, I do not know of any functional langauges in which it exists. The language feature I’m talking about is the removal of a name from the scope. Let me first talk about a situation that is ripe for bugs, and then introduce the idea of removing a name from the scope so that you do not use it mistakenly. ...

Coury Ditch reported on the trickiest Elm bug he’s ever seen. It’s a good read and a good caution against holding stateful information into your Elm messages. When I was very new to Elm one of the first things I had to do at a new company was figure out a bug that basically had the ‘Stale message’ anti-pattern as main reason behind it. So I’m going to described the bug and the solution. ...

Someone asked on the Elm discourse how to embed HTML into an Elm app. There are basically two approaches, which I will try to describe along with advantages and disadvantages. Translate the HTML to Elm Either by hand, or you can use an online tool. As the original poster seemed to find, there is a limit to how sophisticated such a tool is, but it’s probably worth a shot. However, this is only going to work if the HTML you are trying to display is not going to change. In the discourse posts, the HTML was what was presented to them from a legal website drafting a set of Terms and Conditions. But if say that HTML was being produced by some wysiwyg HTML editor, then unless you can automate the translation of the HTML to Elm this isn’t going to work. It obviously will definitely not be able to display dynamically generated HTML. ...

When you hold an opinion, particularly when you know that other sane people hold the opposite opinion, it’s good practice to try to come up with the best argument possible for the opposite opinion. I’m going to do that today with weak typing. I typically think that a weakly typed language is basically useless. As in, I would always prefer a language with strong typing over an equivalent one with weak typing. So in this post I’m going to try to come up with a reasonable scenario in which choosing a weakly typed language over a strongly typed one would make reasonable sense. ...

Popping up on my feed was an article on learning Python by looking through the gotchas and unexpected things that happen in Python. It’s a nice enough article, and clearly a lot of time has been spent polishing it off and even publishing a package to accompany it. What is a little disconcerting though is the sheer number of surprising snippets. A pretty reasonable goal for a language would be to have as few surprising parts as possible. That’s another advantage of having a very small language, there are fewer things that could have been designed in a surprising way, and perhaps more importantly, there are fewer moving pieces that can combine to produce strange or surprising behaviours. ...

Single page applications are a good way to write responsive websites. Non-single page applications have to do a lot of re-getting of the same information, so they are often quite slow to move around. A single page application on the other hand tends to get most of what it needs up front, and then when you move around it only has to get the new data it needs for the new route that you’re on. This can make it seem very fast, in particular things like searching and sorting can be near instantaneous whilst on a non-single-page application they can take a lot more time. Even when you do need to go get more data, your app can feel more responsive because you only show a ‘working’ indicator in the part of the app waiting to display the new data. There are other advantages, such as lessening the load on your server since all the rendering is done on the client rather than the server. ...

This is a pretty entry level post on functional programming. It concerns the folding patterns in functional programming. I’ll be using Elm as an example language, but the ideas are broadly similar in other functional languages. So I’m talking about the fold functions List.foldl and List.foldr. I’ll talk about a strict/eager language, though one of the interesting things about folds is that in strict languages the foldl is the ‘good’ one, whilst in lazy languages the foldr function is the ‘good’ one. I’m going to try to explain why the foldl is the good one in strict languages, I’ll leave why ‘foldr’ is the good one for lazy languages for another day. ...

I wrote recently about laziness, I was trying to convey a sense of how useful laziness can be. I pointed out that it does have some disadvantages. I have been reading Michael Snoyman’s series of posts on the bad parts of Haskell (part 2, and part 3). It’s part 1, that I’m interested in. He talks about the sum and product functions over lists, here is what he says: The sum and product functions are implemented in terms of foldr. Well, actually foldMap, but list’s foldMap is implemented in terms of foldr, and lists are the only data structure that exist in Haskell. “Oh, but foldr is the good function, right?” Only if you’re folding a function which is lazy in its second argument. + and * are both strict in both of their arguments. ...

For pole-prediction I’m experimenting with writing server-side Elm code. Alex Korban’s Elm-weekly newsletter alerted me to a nice article which suggests using Javascript promises. The stated benefit of this is that it: decouples the Elm code and ports from Express itself I’m not sure I understand the benefit of using Promises here. So I’m going to describe in a bit more detail the current solution in pole-prediction which doesn’t use promises and then re-show Eber Freitas Dias’s promise-using code. ...

I actually managed to do a little bit of work on the pole-prediction backend last night. There is a part where we store messages in the “database” (it’s not really a database, it’s really just persistent storage). So the messages are a variant type, and as such we need to write code to both encode each message into JSON, and decode each message from JSON. type DatabaseMessage = AddDriver Year Driver | AddTeam Year Team | AddEntrant Driver.Id Team encodeDatabaseMessage : DatabaseMessage -> Encode.Value encodeDatabaseMessage dMsg = case dMsg of AddDriver year driver -> [ ( "tag", "AddDriver" |> Encode.string ) , ( "arg1", year |> Encode.int ) , ( "arg2", driver |> Driver.encode ) ] |> Encode.object AddTeam year team -> [ ( "tag", "AddTeam" |> Encode.string ) , ( "arg1", year |> Encode.int ) , ( "arg2", team |> Team.encode ) ] |> Encode.object AddEntrant year driverId team -> [ ( "tag", "AddEntant" |> Encode.string ) , ( "arg1", driverId |> Encode.string ) , ( "arg2", team |> Team.encode ) ] |> Encode.object databaseMessageDecoder : Decoder DatabaseMessage databaseMessageDecoder = let interpret s = case s of "AddDriver" -> Decode.succeed AddDriver |> Decode.andField "arg1" Decode.int |> Decode.andField "arg2" Driver.decoder "AddTeam" -> Decode.succeed AddTeam |> Decode.andField "arg1" Decode.int |> Decode.andField "arg2" Team.decoder "AddEntrant" -> Decode.succeed AddEntrant |> Decode.andField "arg1" Decode.string |> Decode.andField "arg2" Decode.string _ -> Decode.fail (String.append "Unknown message string: " s) in Decode.field "tag" Decode.string |> Decode.andThen interpret As you can see all of this is very repetitive and lends itself well to being automatically generated. You can easily imagine some meta-code that, given a type definition, can automatically generate an encoder and decoder (there is also the elm-codec library but if you’re auto-generating these anyway then that’s less useful). ...

I have spoken recently about compile-time laziness as well here and here. Both Elm and Purescript are pure languages that in theory could be compiled as a lazy language. Because there are no side-effects laziness wouldn’t change the behaviour of most programs and those that it does, it is because of infinite loops that do not need to be calculated. However both have chosen to compile in eager (or strict) fashion, partly to reduce the complexity of the compiler, and partly to allow easier interop with Javascript which is the target of compilation in both cases. ...

This post is some vague, not-well-thought-out rambling on meta-programming in statically typed languages. As I have said dynamically typed languages tend to have meta-programming already baked in. This is because changing the program itself, doesn’t need to be re-type checked. However, the whole point of a statically typed language is that the program is type-checked before it is run. So you cannot then change the program at run-time because in that case the new program would not be typed. In theory of course you could allow this, but you would have to do one of three things: ...

A fairly common problem for an Elm developer to encounter after around 6 months is that nested record update is a little painful. Suppose you have a form on your model, like this: type alias CommentForm = { content : String , subject : String , visibleToAll : Bool } type alias Model = { route : Route , commentForm : CommentForm , ... } So now you want to handle the message for updating the comment form. So you might have a handler like this: ...

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