Skip to content
HomeVideosBooksBlogs
AllTop postsTopics
Podcasts
HistoryListsWatch laterLiked videosFollowing

The videos, books, blogs and podcasts Hacker News keeps recommending, all in one place.

VideosBooksBlogsPodcastsAboutPrivacySettings

Data from Hacker News, HackerTube, HackerBooks, HackerBlogs and Open Library. Credits · Not affiliated with Y Combinator.

HomeVideosBooksBlogsPodcasts
Ctrl K
    V

    Vanessa McHale

    blog.vmchale.com · Personal blog · on HN since 2017

    Vanessa McHale writes about functional programming, covering Haskell, ATS, J and APL, x86 assembly and SIMD performance.

    Visit blogRSSHN submissions
    Languages & CompilersProgrammingSystems & Performance
    What HN says

    HN commenters recommend her ATS posts for language and performance detail, and cite her Haskell post as rebutting the claim that it is too hard.

    Stats for nerds
    19HN people shared it
    17linked in comments
    307story points
    Oct 2022last shared
    2019people per year2022

    Top posts on HN

    1. 1
      A Proper x86 Assembler in Haskell Using the Escardó-Oliva Functional
      1 person · 90 points · first shared 2025 · 19 comments on HN
    2. 2
      C is not suited to SIMD (2019)
      1 person · 89 points · first shared 2025 · 120 comments on HN
    3. 3
      Type-Safe Pointers in ATS
      3 people · 82 points · first shared 2020 · 8 comments on HN
    4. 4
      Outperforming Rust with Functional Programming
      2 people · 21 points · first shared 2017 · 5 comments on HN
    5. 5
      Why Haskell Is Good
      2 people · 4 points · first shared 2018 · Discussion on HN
    6. 6
      Practical ATS
      1 person · 4 points · first shared 2017 · Discussion on HN
    7. 7
      Logic Programming Doesn't Work in the Real World
      1 person · 4 points · first shared 2024 · Discussion on HN
    8. 8
      Adequate J Matrix Performance
      1 person · 4 points · first shared 2021 · Discussion on HN
    9. 9
      Calling System Functions in a JIT
      1 person · 2 points · first shared 2024 · 1 comments on HN
    10. 10
      ATS as a Systems Programming Language / Rust
      1 person · 2 points · first shared 2018 · Discussion on HN

    What HN people wrote when they linked it

    • ghostwriterJun 2020

      > What kind of project would be a sweet spot to ATS?

      I'd say a large mission-critical C codebase that decides to grow and expand a formally-verified kernel of its most important functionality - it can be a real-time sytem, an OS kernel, a HFT algorithm etc.

      Nowadays people seem excited about gradual typing in widespread dynamic languages like JavaScript and Python, because it allows them to adopt the best parts of static typing without having to rewrite the entire codebases in new langauges. Now imagine that you can introduce gradual formal verification to your battle-tested C codebase, without a loss in performance[1] and without forcing you into a new tooling ecosystem (compiler, debugger, profiler etc). Actually, you don't need to imagine it, because that's what ATS is :)

      > I would love to understand the nature of the theoretical advantage ATS has here over Rust.

      I'd say it's a synergy of two key features, that produce miracles when put together - 1) direct and safe pointer arithmetics [2], which enables the same data structures and optimisation tricks available in C, yet in a verifiable environment, and 2) refinement types [3].

      > Would it be comparible with F*

      Unfortunately, I don't know much about F*, MS Research regularly releases a new PL prototype after the other and I lost my count on Koka[4].

      > ATS seems to be very much a concept/language in R&D phase. Its ergononics are difficult ergonomics (have a look at the error messages), documentation and example…

    • lucasdicioccioOct 2019

      This comment misses the point of the article, which argues against a urban legend that Haskell is too difficult "unless you are this tall" (a Phd, an E.T., a superhuman). I also had a shot at explaining why people are already tall enough in a past short "comic strip" [0]. I think the article makes a good job re-assuring the urban legends are a myth.

      Now. there are many reasons why one would want to use Haskell. For instance, to have fun, to understand better some pattern, to write expanding-brain memes, or, because they are good at solving problems with it. It is fine if your reasons do not intersect with other people's reasons. You can try finding answers whether Haskell matches your reasons in some other essays [1,2,3]. Maybe it is true for many people that their needs and desires are entirely covered with their own toolset. As a curious/optimistic person I find it incredibly pedant to say I'll never ever need to learn/use something (there's different goodness in everything).

      Personally, practicing Haskell led me to appreciate the importance and trade-offs that occur when isolating/interleaving side-effects. Similarly, it gave me some vocabulary to articulate my thoughts about properties of systems. Both are super important in the large when you architect softwares and systems. There are other ways to learn that (e.g., a collection of specialized languages), but at least for me, Haskell helped me build an intuition around these topics. That said, the prevalence of…

    • bear8642Oct 2022

      > Does it actually succeed though?

      Not sure about J, but I feel APL certainly does, at least for me - the symbol set makes it very easy to sketch out a solution.

      Part of that ease is the generality of the various operators. That is the reductions and cumulative prefix can be done with any function. For example ⌊\ as cumulative min - useful as Vanessa McHale shows <http://blog.vmchale.com/article/numba-why>

      kspalaiologos also shows APL enabling mathematical understanding on her blog <https://palaiologos.rocks/>

      An APL equivalent of the J is +\¯1 1[(?100⍴2)] although others exist as there's no exact equivalent for J's
      { - see <https://aplwiki.com/wiki/From>

    • vmchaleOct 2021

      > it becomes easier to shoot yourself in the foot (which is mentioned in the alternative title, but doesn't seem to be expanded on much) -- say, by closing a Handle

      lazy I/O (such as file reads) is suspect and even bad, but laziness + IO (or something like it) is a great way to stream from an API: http://blog.vmchale.com/article/lazy-io

      Makes it possible to transcode for one. Basically makes streaming "compose" nicely - bzip2 and lzip otherwise have very different ways of streaming! And one would have to line a lot of things up.

    • dan-robertsonAug 2021

      Vanessa McHale has a great set of blog posts about ATS. They touch on technical aspects of the language and it’s type system as well as practical aspects and real-world performance of compiled programs. The list is here:

      http://blog.vmchale.com/category/ATS

      If you click the ‘next’ link a few times you can go through several pages to earlier posts that introduce the language.

    Related

    Michael Snoymansnoyman.com52 people

    Haskell: The Bad Parts, part 2 (2020)

    Michael Snoyman
    Personal · last shared 2024
    Mark Karpovmarkkarpov.com26 people

    Lisp and Haskell (2017)

    Mark Karpov
    Personal · last shared 2025
    Haskell for Allhaskellforall.com190 people

    The category design pattern

    Haskell for All
    Personal · last shared 2026
    Alexis Kinglexi-lambda.github.io172 people

    Parse, Don’t Validate

    Alexis King
    Personal · last shared 2026
    FP Complete Blogfpcomplete.com201 people

    Monads and GATs in Nightly Rust

    FP Complete Blog
    Company · last shared 2025
    Well-Typed Blogwell-typed.com60 people

    Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)

    Well-Typed Blog
    Company · last shared 2026
    Existential Typeexistentialtype.wordpress.com157 people

    Haskell Is Exceptionally Unsafe (2012)

    Existential Type
    Personal · last shared 2026
    Oleg Kiselyovokmij.org251 people

    How the OCaml type checker works (2022)

    Oleg Kiselyov
    Personal · last shared 2026