unison VS nbdime

Short version: no type classes (yet)

Longer version:

Building upon what Quekid5 mentioned, Unison abilities are an implementation of what is referred to as algebraic effects in programming language literature. They represent capabilities like IO, state, exceptions, etc. They aren't really a replacement for type classes, though in some cases you can shoehorn abilities in where you might otherwise use a type class.

For someone coming from a Haskell background, I think that abilities are closer to a replacement for monad transformers. But in my opinion they are much more ergonomic.

Discusson of type classes comes up a lot. Here is a long-standing GitHub issue: https://github.com/unisonweb/unison/issues/502

For what it's worth, I've written Unison quite a lot over the past few years and while I've missed type classes at times, I think that reading unfamiliar code is easier without them. There's no implicit magic; you can see exactly what is being passed into a function. So far I've been happy with a bit more verbosity for the sake of readability.

I've been following the Unison lang [1] for quite some. Wing seem to set similar goals? From the first glance Wing looks more polished, but there's "The Big Idea" behind Unison - is there something similar?

[1]: https://github.com/unisonweb/unison

in haskell it looks like this, you specify the language extensions you want at the top of the source files: https://github.com/unisonweb/unison/blob/trunk/unison-core/src/Unison/ABT.hs

they adjusted my ticket to be a bug fix on their part.

I think Unison is going in this direction. Imo this is a mistake, as a program language functions not just as specification for the machine, but also as communication between programmers. Allowing the introduction of arbitrary dialects to suit individual preferences seems like it would interfere with that communication.

I remember hearing about nbdime and thinking it sounded useful, but I've never really needed it since I rarely use Jupyter in the first place. But then I made some changes to my Hanukkah of Data 2023 notebook to work with the follow-up "speed run" challenge (a new dataset and slightly tweaked clues), and the native Git diff was too noisy to be useful. nbdime came to the rescue! Here are the changes I had to make for days 2 and 3 during the speed run:

[5] ReviewNB for reviewing & diff'ing notebook PRs / Commits on GitHub

Disclaimer: While I’m the author of last two (GitPlus & ReviewNB), I’ve represented the overall landscape in an unbiased way. I've been working on this specific problem for 3+ years & regularly talk to teams who use GitHub with notebooks.

[1] https://nbdime.readthedocs.io

Interesting they mentioned Jupyter Notebooks but not NBDime https://github.com/jupyter/nbdime which is a Jupyter plugin specifically to address this problem. Without it, diffing notebooks is not feasible.

A bit off-topic but someone might know; I'm working with jupyter notebook files (ipynb) which are basically json files. Git diff is very noisy so there's nbdime which works great in the CLI. Is there a way to have Magit aware of its integration with git diff?

I use nbdime which allows you to ignore parts of a notebook (e.g. outputs) when diffing.