Chris Penner

it's hard to put it into words but #jj-vcs has rewired my brain into thinking about commits more "meaningfully". i think git—and to a large extent github—have made commits feel "cheap", something you don't put much thought into. just a thing you have to do before you "push your change".

Things are always changing, and a lot is different from 2024, give it another try sometime :)

However we’ve also been considering different forms of definition identity, like an embedded ID or something (separate from the hash).

At any rate, as it is now upgrades between libraries work fine and still allow having multiple versions of a library if you want 😄

We’re still figuring out exactly how to do upgrades in the most ergonomic way, but what has been working so far is to map corresponding hashes between versions using names, then auto-propagate through the dependencies.

Just curious, are you able to quantify what was less than ideal about the LSP? If you can point at anything specific I’d love to get it patched up!

@unison-lang.org kind of accomplishes this, all code is identified by hash, so if you contribute a given definition, when it’s adopted the hashes will match and nothing complains.

A deployment pipeline that ships your code to staging, and hides the “Deploy to prod” button somewhere in your app on staging. You have to dig through your app, running your new code, to find it.

I’d love to make the type search global across projects in UCM!

Very cool!

Unison uses this system to propagate changes in dependencies, but you can imagine a system which uses a similar method to propagate changes to function colouring

And yes, time grows with the number of dependents, but Unison only needs to recompile actual dependencies, whereas most languages will recompile entire upstream modules when there’s a change.

It’s unidirectional, changes in a definition propagate to the definitions which depend it.

You don’t need to imagine it though you can try it out if you like: @unison-lang.org

You’d still need to handle the newly propagated code if it somehow fails to compile of course, but I think what annoys people the most is just that they have to reannotate the entire function stack

Unison doesn’t have an async keyword, so such a system that propagates function colouring like that is hypothetical, but definitely possible.

It depends!

For almost all languages yes, it’s an issue, but I’m spoiled by Unison, it can handle and auto-propagate even some type-changing updates, so sometimes you can upgrade a library and have it propagate updates through your codebase 😄

Also, IMO function colouring is great and desirable, the bad part is that the user has to update all the call sites and signatures manually. Any sufficiently advanced code storage system should be able to automate this, but alas, most programs are still stored as plain text in a file somewhere.

STM is smart too; so it won't spam like a busy-wait would, it only prints a trace once per block.

-- Hack for finding blocking points in your complex concurrent systems, -- you can literally just print where in the system you're blocked! readQ :: String -> STM.TBMQueue a -> STM.STM (Maybe a) readQ qName q = do STM.readTBMQueue q <|> do traceM $ "Blocked Reading from " <> qName retry writeQ :: Text -> STM.TBMQueue a -> a -> STM.STM () writeQ qName q val = do STM.writeTBMQueue q val <|> do traceM $ "Blocked Writing to " <> qName retry

Cool trick for finding bottlenecks in your concurrent systems; sometimes you can just literally print where you're currently blocked.

When people talk about 'inherent' complexity they're probably talking about an authorization system or a notification system 😵‍💫

I will say that designing flexible and performant versions of each of these has been a great design challenge though, a lot of fun to figure out 🙂

Building Industrial Strength Software without Unit Tests Unit tests aren't the only way.

Did you know that #Unison Share is a full-featured code-repository and collaboration platform that *doesn't have a single unit test*?

Here's how that works:
chrispenner.ca/posts/transc...

(*spoiler*: it's great!)

@unison-lang.org

Saw someone asking about a Haskell debugger on Reddit today and realized how _weird_ it is that Haskell doesn't really have a good story here, but also how weird it is that I don't ever find myself reaching for one.

Maybe I'm sufficiently stockholmed into TDD (Trace driven development) by now?

3 things other languages should steal from Unison Some things other languages should steal from Unison

💝 We encourage everyone to take inspiration from Unison's core ideas and practices. The more programming languages and tools challenge the status quo, the faster "outlandish" becomes "obviously better." Here's @chrispenner.ca on three things other languages should steal from Unison:

Pandoc is dope too! pandoc.org

Yeah the secret is to collect as many obscure languages as possible :)

I'm planning to learn Gleam at some point

#Python devs get sad #Haskell doesn't have examples, but I'll take reliable type information and generated docs over the haphazard python docs situation every day of the week.

It is absolutely bonkers to me that there still isn't a standard way to just see which functions a python module exposes. I know it's dynamic enough to generate new ones at runtime, but like, I'm just tryin' to look at docs!

AMAZING, thanks for sending this my way, I'll definitely be checking this out!!

I'm officially adding Notification Systems to my list of inherently hard problems. I've got:

* Cache invalidation
* Authorization
* Notification Systems

What's on your list?

🤝 We've just added collaborator support to Unison Share!

You can now add fellow Unison devs to your projects with these roles:

👁️ View – Read & download
🔧 Maintain – Read, download, merge & write
🔑 Admin – Full admin permissions

Try it out here: share.unison-lang.org/

As always, my problem was solved with yet another layer of abstraction :P