{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreievulvortsjx2l6wcuwuzkyvn5vxexz4si3i4mbl5alncft2vjhze",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3ml7mhrkhpe42"
  },
  "path": "/t/anti-llm-sentiment-considered-harmful/14008?page=4#post_73",
  "publishedAt": "2026-05-06T19:13:53.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "@Ambrose"
  ],
  "textContent": "I’ll speak for myself in replying to both this and @Ambrose - when working on dataframe a lot of people that approach ask me to meet them where their data is. Which means supporting common, consistently evolving file formats and layout specs like Apache Arrow and Apache Parquet. Even if that’s done people will complain about plotting and notebooks and their favourite cloud provider etc. So to get people to use dataframes in their day to day work I have to end up having to drop dataframe development time (query optimization, API design, and all the pretty complicated Haskell abstractions you have to juggle to understand the core problem). Each of these I-would-use-it-buts is a substantial digression. It took almost a year of going to the meetings (for all 4 of DataFusion, Parquet, Arrow and Iceberg) and socializing with people that know Parquet enough to be comfortable writing it out. Even then you gotta spend a week or so understanding the quirks of data.binary and lazy bytestrings to get the implementation working.\n\nI really enjoy coding and this currently very specific data structure that I think would be wonderful if it were in Haskell but currently that seems to commit me to doing a lot of no-that. I imagine for someone on payroll these incentives tip you to not using Haskell at all but even working on an open source project with less time and no access to cross cutting expertise the economics (time and effort wise) don’t make sense. Unless…",
  "title": "Anti-LLM Sentiment Considered Harmful"
}