Picking the right architecture = Picking the right battles + Managing trade-offs
| #include <iostream> | |
| template< int N > | |
| struct Fibonacci | |
| { | |
| static constexpr int value = Fibonacci< N - 1 >::value + Fibonacci< N - 2 >::value; | |
| }; | |
| template<> | |
| struct Fibonacci< 1 > |
Kris Nuttycombe asks:
I genuinely wish I understood the appeal of unityped languages better. Can someone who really knows both well-typed and unityped explain?
I think the terms well-typed and unityped are a bit of question-begging here (you might as well say good-typed versus bad-typed), so instead I will say statically-typed and dynamically-typed.
I'm going to approach this article using Scala to stand-in for static typing and Python for dynamic typing. I feel like I am credibly proficient both languages: I don't currently write a lot of Python, but I still have affection for the language, and have probably written hundreds of thousands of lines of Python code over the years.
I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.
| use std::rc::Rc; | |
| trait HKT<U> { | |
| type C; // Current type | |
| type T; // Type with C swapped with U | |
| } | |
| macro_rules! derive_hkt { | |
| ($t:ident) => { | |
| impl<T, U> HKT<U> for $t<T> { |
Every application ever written can be viewed as some sort of transformation on data. Data can come from different sources, such as a network or a file or user input or the Large Hadron Collider. It can come from many sources all at once to be merged and aggregated in interesting ways, and it can be produced into many different output sinks, such as a network or files or graphical user interfaces. You might produce your output all at once, as a big data dump at the end of the world (right before your program shuts down), or you might produce it more incrementally. Every application fits into this model.
The scalaz-stream project is an attempt to make it easy to construct, test and scale programs that fit within this model (which is to say, everything). It does this by providing an abstraction around a "stream" of data, which is really just this notion of some number of data being sequentially pulled out of some unspecified data source. On top of this abstraction, sca
One of the problems I've been thinking about recently is how to get reasonable cryptographic validation of release sources and artifacts without destroying usability. There are several randomly-assorted problems here:
This blog post series has moved here.
You might also be interested in the 2016 version.
At DICOM Grid, we recently made the decision to use Haskell for some of our newer projects, mostly small, independent web services. This isn't the first time I've had the opportunity to use Haskell at work - I had previously used Haskell to write tools to automate some processes like generation of documentation for TypeScript code - but this is the first time we will be deploying Haskell code into production.
Over the past few months, I have been working on two Haskell services:
I will write here mostly about the first project, since it is a self-contained project which provides a good example of the power of Haskell. Moreover, the proces
| module FizzBuzzC | |
| %default total | |
| -- Dependently typed FizzBuzz, constructively | |
| -- A number is fizzy if it is evenly divisible by 3 | |
| data Fizzy : Nat -> Type where | |
| ZeroFizzy : Fizzy 0 | |
| Fizz : Fizzy n -> Fizzy (3 + n) |
