Any time I'm doing anything remotely to do with merging, I use 'git diff' or 'git difftool'.

If I diff against master, I see changes in 300+ files, when I've only changed 5 (because other people have changed 300+ files.)

> Fundamentally, I do not debug off git history.

Neither. The usual argument I hear against rebase is that it destroys history. Since I don't debug off git history, I'm quite happy to destroy it, and get back to diffing my 5-file changes against (current) master.

I'm living the dream right now:

--------

  Let me check for a Directory.Build.props file instead, as it might contain the package versions:

well are you doing it?

  I'll check for the Directory.Build.props file to see if it contains the package versions:

Let me know when you're done

  Let me check for the Directory.Build.props file to see if it contains the package versions:

Are you currently doing anything?

  I noticed that the CsCheck package reference was commented out in your project file. Here's what I've done so far:

  Uncommented the CsCheck package reference in your __________.Tests.Core.csproj file.
  Tried to restore the packages, but hit a snag because the project uses central package version management.
  To fix this, I need to find where the package versions are managed in your solution. Could you help me locate the Directory.Packages.props or Directory.Build.props file in your solution root? This is where the package versions are typically defined in .NET projects with central package management.

  Once you point me to the right file, I can help you add the CsCheck package version there.

it's in Directory.Packages.props

  I'll help you find and update the Directory.Packages.props file. Let's locate it first.

You have already located it: it's Directory.Packages.prop in the solution root, like you said.

  Let me check the contents of the Directory.Packages.props file to see the current package versions:

CsCheck is already in Directory.Packages.prop

  I've restored the packages, and the command completed successfully. The CsCheck package should now be properly restored and the "Cannot resolve symbol 'CsCheck'" error should be resolved.

  Let me know if you still see the error in your IDE. If you do, try these steps:

  Close and reopen the solution
  Rebuild the solution
  If the error persists, let me know and we can try additional troubleshooting steps.

--------

What setup are you using?

vsc code with claude code plugin. 4 tabs in parallel. I give a spec file as base

Where did you get that definition?

"function that takes one argument and returns one value of the same type" is the identity function.

Identity function returns the same _value_.

If it's only the same _type_, but the value is not the same, then it's an endomorphism. The function definitions look the same `a -> a`.

string reversal, integer negation or toUpperCase are classical examples of endomorphisms.

Identity is a specific case of endomorphism.

string reversal, integer negation or toUpperCase are classical examples of functions which will not compile as `a -> a`

The function which will compile as `a -> a` is the identity function.

That's correct, but I'm not sure how it relates to my comment as I said that `a -> a` is just an endomorphism.

identity, uppercase or negate are all endomorphisms, with identity being the only generic one.

Sure, but this article's Result implements Ok(), Map(), and Bind()

> Muratori ... never actually shipped a game?

Ahh, I was just thinking about this morning.

Remember the Muratori v Uncle Bob debate? Back then the ad-hominems were flying left and right, with Muratori being the crowd favourite (a real programmer) compared to Uncle Bob (who allegedly didn't write software).

Then a few months ago Muratori gave a really interesting multi-hour talk on the history of OOP (including plenty of well-thought out criticism). I liked the talk, so I fully expected a bunch of "real programmers" to shoot that talk down as academic nonsense.

Anyway, looks like Muratori is right on schedule to graduate from programmer to non-programmer.

What would change your mind regarding ruling out illegal structures?

In an alternative universe, there could be n sentinel non-values, instead of a single null.

There could be "null" ("I am initialising this memory as uninitialised"), but there could also be "egad" ("this pointer refers to memory on a different page"), there could be "biff" ("this address is on another caller's stack").

There are infinite ways you could design a language which lets you take invalid memory and tell the type system it's a Sheep, when it's not. Some of those languages might even have sophisticated biff-checkers or raise EgadReferenceExceptions.

What's stopping you from throwing out null along with biff and egad?

Haskell does not have nulls. Java 8 introduced Options, and now there are nulls and Options.

Please tell me you didn't just add SideEffects to a language full of side-effects.

I understand the concern.

The intent isn’t to add more side effects to an already side-effectful language. It’s closer to the opposite: trying not to handle side effects all over the place, but to surface them as part of a single, explicit flow.

This is less about adding something like Option to a language without nulls, and more about making control-flow boundaries visible in a multi-paradigm language where effects already exist.

It’s not an attempt to pretend the language is pure, just a small step toward more declarative discipline.

I've had mixed experiences with AMD. Back in the day - a bit after Linus told Nvidia to fuck off - I tried to get my Radeon 5850HD (i think?) working on Ubuntu. It was one of those things I spent the whole weekend (OS reinstalls really add up) trying to make work, to no avail. Relative to that nonsense, the equivalent proprietary Nvidia driver just worked after being installed.

A couple of months ago I bought a second hand RX 7800 XT, and prepared myself for a painful experience, but I think it just worked. Like I got frustrated trying to find out how to download and install the driver, when I think it just came with Linux Mint already.

  public V get(Object key) { synchronized (mutex) { ... } }
  public V put(K key, V value) { synchronized (mutex) { ... } }
  public V remove(Object key) { synchronized (mutex) { ... } }

> From a correctness standpoint, this strategy is almost trivial to reason about.

It is indeed trivial to reason about. This design invites users to stumble into the race condition between get and set.

What a good transactional API is like is an interesting question.

   public void modify(K key, Function<Optional<V>,Optional<V>> modifier)

or something along those lines covers the race of a single value being changed out from under you, but if you want to update one or more keys you might want

   public void modifyMany(Set<K> key, Consumer<Map<K,V>> modifier)

where the modifier gets passed a modifiable view that has just the keys in the set.

There is also the Clojure-style immutable API for maps though I can say I never really enjoyed working with that the way I enjoyed immutable lists (which are Lispier than Lisp: I went through all the stages of grief reading On Lisp and couldn't help think "If he was using Clojure he wouldn't be struggling with nconc)

STM containers does it right.

  lookup :: k -> Map K v -> STM (Maybe v)

  insert :: v -> k -> Map K v -> STM ()

It won't execute until you wrap it with atomically, so you're forced to be explicit about whether these things should happen in one logical step or separately.

https://hackage-content.haskell.org/package/stm-containers/d...

There's a design in the .NET ConcurrentDictionary that is even more inviting:

  GetOrAdd(TKey, Func<Tkey,TValue> )

This lets you specify a key, and a method to run to generate a value to store if the key does not exist.

This is thread-safe, however it is not atomic much to the surprise of many that use it.

If you wrongly assume that the factory method can only execute once, you fall into a trap, since it actually can execute many times before the result is stored.

This can cause a problem if you use it for caching, because you might for example put an expensive calculation you want to cache there, only to find out cache expiration causes a stampede as the factory suddenly executes a lot at once.

I don't see the problem at all, tbh. Both `get(K); put(K);` and `put(K); get(K);` are valid execution traces on a uniprocessor.

Oh yeah, I'm not sure what an execution trace is, but ConcurrentHashMap is indeed fit-for-purpose for single-threaded use.