Today I wanted to test a few boolean expressions, and ended up with some quick truth table generation hackery in Haskell which I thought I’d note down for next time. I’m sure there are many better ways of doing this, but this way was mine.
A sordid tale of builds, Gradle, Grunt, node, yarn, Linux, TeamCity, Docker, ssh, and shaven yaks.
Quick reminder to Future Dave, as I’m going to assume he’ll keep making the same mistake Past and Present Daves make.
When switching between my editor and GHCi REPL to test stuff out I often forget to add a
deriving (Show, Eq) or similar line to my data types. This normally occurs after I’ve just set up a bit of test data in the REPL, so if I just fix the data declaration and
:reload GHCi then my setup will be lost. We can use the StandaloneDeriving GHC extension to help here.
Today I wanted to look at an approach for producing aggregate data from multiple measurements over a source. I’m learning Kotlin at the moment so I’ll use that for the examples in this post, but we can apply the same idea to pretty much any language (I’ve used similar approaches in F#, and it would work with C# albeit with a bit more code noise).
In which I ramble on about how my thoughts on pattern matching have changed over the years.
When I first came across the terms "currying" and "partial application" I was a bit confused about the difference. Here is my attempt at an explanation1. I’m not 100% confident of my understanding, so please point out any inconsistencies – I’m happy to be corrected :).
C and C-style languages like C++, Java, and C# tend to have method types written like this:
Other typed languages and programming papers use a notation more like this:
I found it took a bit of getting used to, but I now much prefer to read and write this style. I think it is worth becoming familiar with, as it is used in quite a few languages1 and in all the programming papers I’ve seen. So here’s a quick guide on how to read this style of type annotation.
I really enjoy trying to understand how and why things like work, but for this post I’m going to try to skip all that wonderful stuff and instead give a practical outline of how to use a very useful pattern arising from applicative functors.
I’ve found this pattern incredibly useful in F#, Swift and Haskell. The examples here are in F#, but as far as I can tell we can use it anywhere that has generic types and higher-order functions.
Today I updated a library version in a project, which changed the path from
packages/FSharpFormatting.CommandTool-2.9.1. We’d also taken our own copies of some templates in the package, and I wanted to check if there were any differences between
-2.9.1\templates that I should port across.
Rather than my usual fumbling about (check out both, copy, diff) I thought I’d try to learn the necessary Git incantation to compare the paths. And then blog it, so that when I forget I’ll have a quick reference handy for next time. :)