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