In reply to @b:chreekat.net
DRY is in frequent conflict with YAGNI

DRY: don't write the same thing twice
YAGNI: don't define something you don't (yet) need

I can see how they conflict when applied loosely, but applying DRY carefully should be OK.

Maybe something like this?

lens_5_3_3 = self.callHackageDirect {
  pkg = "HaskellNet-SSL";
  ver = "5.3.3";
  sha256 = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
} {};

Maybe something like this?

lens_5_3_3 = self.callHackageDirect {
  pkg = "lens";
  ver = "5.3.3";
  sha256 = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
} {};

Maybe something like this?

lens_5_3_3 = callHackageDirect {
  pkg = "lens";
  ver = "5.3.3";
  sha256 = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
} {};

Maybe something like this?

lens_5_3_3 = pkgs.haskell.lib.callHackageDirect {
  pkg = "lens";
  ver = "5.3.3";
  sha256 = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
} {};

pkgs.haskellPackages.lens.overrideAttrs {
  version = "5.3.3";
  src = pkgs.fetchzip {
     url = "mirror://hackage/lens-5.3.3/lens-5.3.3.tar.gz";
     hash = "sha256-3xm0+HH2CY3rcigl8x1kYVLOW5PVFhilg0s0hxHxzWE=";
  };
};

In reply to @implicit_operative:matrix.org

Maybe something like this?

lens_5_3_3 = pkgs.haskell.lib.callHackageDirect {
  pkg = "lens";
  ver = "5.3.3";
  sha256 = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
} {};

In reply to @b:chreekat.net
They're fundamentally in conflict. You only avoid conflict precisely by applying them loosely. :) DRY, applied religiously, requires you to define abstractions very early that allow slightly different use cases to share common expressions. But abstractions have a cost. Copy/paste/modify is often cheaper. And most importantly, it requires a lot less careful thought. Wasting brainpower to develop a thoughtful abstraction for something that will never have more than two use cases is a shame. That's really the essence of YAGNI.

In reply to @b:chreekat.net
They're fundamentally in conflict. You only avoid conflict precisely by applying them loosely. :) DRY, applied religiously, requires you to define abstractions very early that allow slightly different use cases to share common expressions. But abstractions have a cost. Copy/paste/modify is often cheaper. And most importantly, it requires a lot less careful thought. Wasting brainpower to develop a thoughtful abstraction for something that will never have more than two use cases is a shame. That's really the essence of YAGNI.

That's hardly the bare minimum needed to avoid repetition.

Perhaps DRY fails to explicitly account for the idea that some repetition is needed for defining things that are different even though they seem similar.

For me, problems like this tend to go away when I model the problem more carefully.