Frankly speaking ...

A Puzzle Without a Picture Genome sequencing faces a fundamental physical constraint: modern instruments cannot read a long chromosome continuously from end to end. Instead, they synthesise or capture millions of short sequence fragments called reads. These range from 150 base pairs in high-throughput short-read chemistry to tens of thousands of base pairs on long-read instruments—and well over a million base pairs with Oxford Nanopore ultra-long protocols. Reconstructing a complete genome from these fragments is like solving a multi-million-piece jigsaw puzzle without the picture on the box top. To tackle this challenge, I turned to graph-theoretical assembly frameworks. The Overlap-Layout-Consensus (OLC) paradigm is one of the classic, most intuitive ways to stitch fragments into continuous sequences called contigs. While building reconstruct-strings —a pure and total Haskell implementation of a greedy OLC assembler—I set out to explore sequence reconstruction from first princ...

I've been curious about dependent types for some time. After wrestling with them in Haskell , discovering Lean felt like a small revelation. Two weeks in, Lean's proofs-as-values and tighter types already feel like the missing piece I couldn't quite get in Haskell. My Haskell background helps; the language still feels familiar enough that the learning curve is manageable. In this post I compare two Word Puzzle solvers I implemented: one in Haskell and my first program in Lean 4 . Below I list the differences I noticed and why they mattered for design, validation and I/O. Overview of the Problem I built both projects to solve an identical problem: given a pool of 4–9 lowercase letters and a mandatory letter, filter a dictionary file for words that can be spelt from the pool. My Haskell version uses pull-based streaming I/O with the io-streams library and applicative validation via Data.Validation . For my Lean 4 attempt, I used dependent types with compile-time...

This post was first published on 15 October 2020, but that site has since been shut down. Part 1  of this series explored pseudo-random values—statistically random values derived from a known starting point. This article explores using random values in testing. Randomness in test invocation is common; for instance,  JUnit5  provides an annotation to  randomise the order of test execution . This article, however, examines a testing style using randomly generated input values to test  properties  of code, known as "Property-Based Testing". Why use random values in testing? Defining suitable positive and negative test cases to exercise code is often difficult. Automating the execution of many randomly selected tests covers a broader range of input values. Furthermore, recording and reporting failing tests allows for replay and debugging. Property-based testing verifies program code using a large range of relevant inputs by generating a random sample of valid v...