Elektrine lite

← Feed

@jonocarroll@fosstodon.org

2025-12-05 06:07 UTC

Perhaps you saw the post series "Python is not a great language for data science"... well, here's Haskell IS a Great Language for Data Science https://jcarroll.com.au/2025/12/05/haskell-is-a-great-language-for-data-science/ #haskell :haskell: #rstats :rstats:

Replies (3)

  • @Lluis_Revilla@fosstodon.org 2025-12-05 14:50

    @jonocarroll@fosstodon.org I'm suprised by the seq_len(1e9) example. I thought that even without compuler tricks the ALTREP would work to make it faster than the 114s it took on my computer. 🤔

    Open ##2450814

  • @defuneste@fosstodon.org 2025-12-06 13:06

    @jonocarroll@fosstodon.org saw your blog posted on the data science reddit, pretty hilarious or sad depending on your mood

    Open ##2450815

  • @prophet@functional.cafe 2025-12-11 01:00

    @jonocarroll@fosstodon.org sorry if this has been said before, but this is only fast in haskell because you're not actually evaluating the result ^^. running length x takes around a minute before running out of memory on my machine (with 108 it finishes after around 20s). that's to be expected though for two reasons: 1) you're running this in ghci, which is an interpreter that is optimized for fast interactive use and performs no optimizations at all (although even compiled with -O2, this runs out of memory for me) 2) you're comparing singly linked lists of boxed integers (just about the least cache and memory efficient representation you could use here) to unboxed (probably?), vectorized arrays. using unboxed arrays from vector instead takes ~12s (compared to ~10s for R on my machine) i don't doubt that optimizations can give haskell an advantage but they won't make a difference here since you're only running two presumably already well-optimized functions

    Open ##2450819