deredede

It might be difficult to say "No, I do not want this magic box." when under the pressure of economic forces that require you to use the magic box, but that doesn't mean you need to use the magic box in all other areas of your life.

According to current practices, you ask ChatGPT or DeepSeek to verify it.

I don't have that reading at all. The phrasing even seems (carefully?) chosen to avoid this interpretation: it's "Examples are many of the administrators [...]", not "Examples are the administrators [...]".

GitHub (still) allows you to edit files directly in the browser without using AI.

I know how to review code without looking at the corresponding assembly and have high confidence in the behavior of the final binary. I can't quite say the same for a prompt without looking at the generated code, even with temperature 0. The difference is explainability, not determinism.

I also do this.

Random flags added to core tools are done with aliases, which do not affect the launched processes, not by shadowing them in ~/bin. Shadowing in ~/bin are for cases where a newer (compared to the system-wide version) or custom version of a tool is needed.

I like it. IIFEs always make me nervous because they look like they beg to be removed if you don't know why they are used. Using an explicit function such as `run` looks much more intentional, and provide a single intuitive place (the documentation of the `run` function) to explain the pattern.

You can send arbitrary commands, but they will be rejected unless you provide valid credentials first.

Not GP but I read "I'm fine with allocation failures" as "I'm OK with my program terminating if it can't allocate (but not for other errors)".

Not GP but bump allocation (OCaml's GC uses a bump allocator into the young heap) mitigates this somewhat, list nodes tend to be allocated near each other. It is worse than the guaranteed contiguous access patterns of a vector, but it's not completely scattered either.

You can give honest, unbiased feedback without insulting either people or their work.

Software engineering is a collaborative process, not an adversarial one.

I can think of plenty situations where you really want to use the dependency's types though. For instance the dependency provides some sort of data structure and you have one library that produces said data structure and a separate library that consumes it.

What you're describing with SML functors is essentially dependency injection I think; it's a good thing to have in the toolbox but not a universal solution either. (I do like functors for dependency injection, much more than the inscrutable goo it tends to be in OOP languages anyways)

Alternative answer: both versions will be picked up.

It's not always the correct solution, but sometimes it is. If I have a dependency that uses libUtil 2.0 and another that uses libUtil 3.0 but neither exposes types from libUtil externally, or I don't use functions that expose libUtil types, I shouldn't have to care about the conflict.

It's not "all the transitive dependencies". It's only the transitive dependencies you need to explicitly specify a version for because the one that was specified by your direct dependency is not appropriate for X reason.