3 ms·
Wonderfully stated. One thing that deep, static type systems often lend themselves to is complex types, and those complex types lead to complicated designs; an
by ilikehurdles 8y ago
Wonderfully stated.
One thing that deep, static type systems often lend themselves to is complex types, and those complex types lead to complicated designs; and if I have the option, I'd rather spend my time designing a simple architecture than exhaustively testing and validating a complicated one.
Since using clojure (roughly the last 3 years in data-pipeline style architecture) I try to follow a principle of writing functions that do just one thing, simply, and do it well, keeping the interface as basic as possible. Almost all of the time when writing clojure, I'm writing functions that act on a couple of built-in types and return one built-in type, usually the same one as before.
Additionally, I try to isolate side effects.
Following these principes, I find that even when I'm dealing with a stinker of a namespace or running into a runtime error, it's pretty cheap to try it out in the REPL and get to refactoring.
That said, I kind of want my cake and to eat it too. I do miss static types -- just not as much as I missed them when I was writing Javascript or Ruby. If I write a new clojure library now, yes, I would try to instrument it (at least the public api) with clojure-spec. If I could re-design clojure, I'd leave out null and maybe build a more intuitive interface to clojure-spec to use it as a kind of progressive validation system via annotations and type hints.
- agumonkey 8y ago> static type systems often lend themselves to is complex types, and those complex types lead to complicated designs I don't know how to call this. But it's something I find true too. And to a point, it feels like a lot of businesses leverage that as a justification point for their cost.
- dmux 8y agoIt reminds me of a great quote from the book Computing Fundamentals [0] regarding Wirth's design philosophy: >Wirth’s philosophy of programming languages is that a complex language is not required to solve a complex problem. On the contrary, he believes that l languages containing complex features whose purposes are to solve complex problems actually hinder the problem solving effort. The idea is that it is difficult enough for a programmer to solve a complex problem without having to also cope with the complexity of the language. Having a simple programming language as a tool reduces the total complexity of the problem to be solved. [0] https://www.cslab.pepperdine.edu/warford/ComputingFundamentals/PboxCh01.pdf https://www.cslab.pepperdine.edu/warford/ComputingFundamenta...
- agumonkey 8y agoI'd add that most solutions to complex things require a tiny abstraction that brings beauty and ease, not the feeling you get in a messy warehouse.