Many algorithms cannot handle duplicates in their input. The specific problems that we were working with don’t require the input to be ordered in any particular way. What is the fastest way to remove duplicates from a list?

A recent PR to my one-true-path-experiment repository showed that some of my curve generation functions are not stack safe. There is an obvious solution to this problem, but I was afraid it might make the functions much slower. We can use the elm-benchmark package to find out.

A huge shoutout to Ian Mackenzie who actually implemented all of this

A description of two problems I ran into whilst putting a small haskell/elm project running in docker on heroku.

At university, I recently followed an OOP programming course. A big part of the course was using design patterns to architect features and applications. As a functional programmer, I was (and am still) horrified/puzzled by how OOP languages encourage the use seemingly arbitrary design patterns.

But it made me think: Most Elm programmers are javascript programmers (welcome!) to whom a functional approach to developing is foreign. The Elm Architecture solves many global architecture problems, but
for business logic, there isn’t much learning material available at the moment. As a community, we should do a better job in this area. This post describes how the concept of mathematical structures can help design programs.

Given

type Msg = A | B | C

Say you are in the A branch of your update function, and want to execute the code of the C branch. You go to the Core.Task documentation, find Task.perform and - with a little type tetris - write.

Task.perform identity identity (Task.succeed C)

I think this code is problematic and that there is a better way.

When I wanted to implement a python iterator from C using the Python C api, there was almost no information on it. At a time when we move to using more languages - to levarage each’s specific strengths - it is crucial to have a clear and approachable interop story for Python.

In this article, I implement a custom iterator for Freestyle - a stylized edge render engine that is integrated into Blender. The example should generalize. In addition, I cover bridging between Python and C++ iterators.

Recently, I’ve been translating some algorithms from imperative (Javascript/Python) languages to Elm. In this process, the conversion of loops to functional code always requires a lot of attention, mostly because loops imply mutation. Here are some strategies for rewriting common loops patterns in Elm using folds, unfolds, and paramorphisms.

My previous post about child-parent communication has done very well. It was also pretty dry and technical. Since then, Brian Hicks has done a much better job at explaining how to use the pattern in practice.

When creating more complicated applications, it becomes sensible to break up functionality into components. There is one main model (the parent) that holds subcomponents (here called children).

A problem arises when the parent needs to keep respond to something that happens in a child component. For instance, the child validates its input and the parent component needs to respond to that, or the child wants to cause an url change (an effect that affects the global state, and therefore is best done centrally by the parent).

Elm’s way of parsing JSON is completely different to what you’ll often see in non-functional languages. To make the types of your program fit, the JSON input has to be more or less regular. Optional fields are not great to work with.

To decode JSON objects in Elm, we use the Decode.object* functions. This gives a problem when decoding objects with more than eight fields, because these decode functions are only defined up to Decode.object8. For me, decoding large json object is pretty common, so a better solution is needed.