Yeah, there's something of a tension between the Perlis quote "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures" and Parse, don't validate.

The way I've thought about it, though, is that it's possible to design a program well either by encoding your important invariants in your types or in your functions (especially simple functions). In dynamically typed languages like Clojure, my experience is that there's a set of design practices that have a lot of the same effects as "Parse, Don't Validate" without statically enforced types. And, ultimately, it's a question of mindset which style you prefer.

There's probably a case for both. Core logic might benefit from hard types deep in the bowels of unchanging engine.

The real world often changes though, and more often than not the code has to adapt, regardless of how elegant are systems are designed.

Coalton ( https://coalton-lang.github.io ) is the sort of thing I like: a Haskell-style language hosted inside a very dynamic one with good interop.

Yes it's quite the blend!

Do those design practices protect you when you apply a refactor and now you don't know which call sites may be broken now?

Yes

I'm not sure why "954 partners" is surprising: log10(954) is between 2 and 3 so, if you assume Soundcloud uses at least 10 SaaS products to manage data (AWS, Snowflake, Datadog, etc. this number is definitely a low estimate). And then you assume each of those entities process the data through 10 partners of various kinds, it only takes 3 steps out to get 1,000.

Over time I evolved to Debian testing for the base system and nix for getting precise versions of tools, which worked fairly well. But, I just converted my last Debian box to nixos

I'm using Debian testing in my daily driving desktop(s) for the last, checks notes, 20 years now?

Servers and headless boxes use stable and all machines are updated regularly. Most importantly, stable to stable (i.e. 12 to 13) upgrades takes around 5 minutes incl. final reboot.

I reinstalled Debian once. I had to migrate my system to 64 bit, and there was no clear way to move from 32 to 64 bit at that time. Well, once in 20 years is not bad, if you ask me.

I've had a couple outages due to major version upgrades: the worst was the major version update that introduced systemd, but I don't think I've ever irreparably lost a box. The main reason I like nixos now is:

1) nix means I have to install a lot fewer packages globally, which prevents accidentally using the wrong version of a package in a project.

2) I like having a version controlled record of what my systems look like (and I actually like the nix language)

I prefer to isolate my development environment already in various ways (virtualenv, containers or VM depending on the project) so I don't need that parts of NixOS. My systems are already run on a well-curated set of software. Two decades allowed me to fine tune that aspect pretty well.

While I understand the gravitas of NixOS, that modus operandi just is not for me. I'm happy and fine with my traditional way.

However, as I said, I understand and respect who use NixOS. I just don't share the same perspective and ideas. Hope it never breaks on you.

I think you could mitigate some of the problems by making the drug company pay for the treatment before approval.

Genius did something like this to prove that Google was stealing lyrics from them: https://www.pcmag.com/news/genius-we-caught-google-red-hande...?

Gemini (3.0 Thinking) solves it too.

I strongly disagree with this: calling your thing that serves webhooks “webhooks” or “webhook-service” sounds nice and neat when you’re looking in a repo list but you immediately impose a tax on everyone in the org: now everyone in a conversation has to distinguish between “webhooks” as the proper name of a particular service and “webhooks” as the name of a particular pattern. Multiply this by all the various components of a modern software ecosystem, and you turn your companies infrastructure into a private language piecemeal and, what’s worse, it’s a private languages outsiders and newcomers think they understand and so they often take much longer to discover what the actual services are.

I wish people would stop promoting the singleton pattern: in almost every case I’ve seen, singletons are unnecessary tech debt and solve a problem that’s better solved with some form of dependency injection (and I don’t mean the XML/YAML monstrosities various frameworks force on you but rather constructor arguments or factory functions)

The site is not "promoting" the singleton pattern. In fact, there is a "Tradeoffs"[1] section that calls it an anti-pattern in JavaScript.

In spite of that, there are plenty of reasonable use cases for singletons in many languages, including JavaScript. For example, ES Modules are effectively singletons. If you import the same module in multiple places, it only gets evaluated once.

Let's not turn the singleton pattern into forbidden knowledge.

[1]: https://www.patterns.dev/vanilla/singleton-pattern/#tradeoff...

Why pose DI as replacing singletons when they're used together all the time? Injecting dependencies to create a singleton repository or service class, which is shared across requests.

Singletons are globals and should be treated the same as every other global (that is, used sparingly and with care).

Worse is that singletons enfurece a single instance which is almost always unnecessary. It’s trivial to only create as many instances as you need.

Off the top of my head, rails (currentattributes), Laravel (facades) especially, and most iOS apps use singletons quite well. It’s all in moderation and depends highly on how it’s used, much like every other design pattern.

I think people just don’t like Singletons because they’ve been especially misused in the past but I guarantee the same argument stands for any other design pattern.

Yes, I have to admit my interest was piqued by the banner, and I then scrolled down, saw the first example was singletons, and closed the tab.

Yeah, the liberating thing for me in CL is that things just don’t break as much as they do in other ecosystems. So, when I get breaking changes I look for an alternative that doesn’t break.

But how the data got sorted is irrelevant to the speed of the algorithm: for example, you could use binary search as part of an algorithm to find the insertion point of a new element in an always sorted data structure, meaning that sorting the data is never necessary.

The overall journey matters. For example, for some flight journeys, the flight-time is only a fraction of the overall time taken by the journey, which could makes it faster if you use road or rail transport. Flight speed doesn't matter.

But that is an unanswerable question which depends on how the data structure is used. The reasonable thing is to calculate the cost for the operations separately and let whoever uses the algorithms figure out what that means for their use case.