In some ways, in Haskell, type-classes are passing around "dictionaries". You can implement a similar pattern as in Gleam, in Haskell, by explicitly passing aro

In some ways, in Haskell, type-classes are passing around "dictionaries". You can implement a similar pattern as in Gleam, in Haskell, by explicitly passing around those dictionaries. In Haskell it makes for some pretty ugly code though. But type-classes get a dual use also as constraints for parametric polymorphism. This gives you some more immediate feedback from the type checker and also lets the programmer extend type checking with their own rules. Never the less I sometimes use this pattern of grouping functions together into a record along with pointers and handles they need to shared resources to make running those functions, passing them around, and cleaning them up easy and explicit -- when it is called for. From experience I find I doubt that we tend towards complexity or enjoy writing complex code. Most people I know find complex code takes quite a lot of effort to write, understand, test, and make useful. The majority of people I've worked with want to write simple, elegant code and find joy in understanding a problem. It happens that some times we either judge the problem to be more simple than it is or we can't formulate a succinct specification of the solution. This leads to code needing some solution to the inherent complexity in the former case. And in the latter it means we don't know what we're doing and are getting lost in the weeds. In both cases a liberal application of good-old-fashioned thinking tends to do the trick. When thinking is insufficient it always helps to have coding guidelines, mentors, and access to experienced colleagues. The last ditch effort of course is searching the good, old Internet.