Lean on the built-in features that do the most work.
Write as little code as possible.
I heartily subscribe to this. Currently I mostly write in Python and I have increasingly come to avoid creating custom classes and data structures - lists and dicts are often all you need and fast enough. The only time I find myself using classes is when I need to define fields, and for that named tuples often work just fine.
One reason I like Ocaml is making specialized types for things is very low-overhead, it adds safety, and the types have zero runtime cost as they can be aliases to existing types. This is something I miss a lot in Python.
I also like OCaml (and Clojure which is about as pythonic as it gets), but a disavantage of custom types is that they are less general so it is harder to just compose stdlib functions to work on your data, you have to have bits of glue code here and there. Though the lack of type safety did bother me here and there when the data you put in does not match what you were expecting, so your code might break in subtle ways.
Like anything it’s a balancing act and it could be that the balance I have struck is less extreme than the one you have tried. Or it could be that the things you find bothersome about composition don’t bother me. But, FWIW, I have not experienced this pain you’re referring to. I do have to_balh and from_blah type functions, often, for my specialize type, and generally that extra step has been enough for me. I have been bit pretty heavily by Python types (or any dynamic language) not being what I expect, so even if that extra conversion is annoying I haven’t been too bothered by it. Often times, the only one one should manipulate the values I have is through API functions anyways, where the conversion isn’t a problem. So, YMMV.
Go strongly encourages this by giving you slices (kinda like lists) and maps (essentially dictionaries) that are generic but making you jump through the hoop of writing an interface if you want your own snowflake container.
I think there’s a happy medium. Going full-on primitive obsession can be harmful. Encapsulating every tiny bit of knowledge can also be harmful. It’s useful to nudge people in one direction or another depending on circumstance, but it’s hard for me to come up with absolute rules that should be followed. Saying “it depends” is a lot less satisfying than claiming one end of the spectrum is better period.
To support that three claims there’s also a study referenced in The Art of Unix Programming. In chapter 4, the author speaks about Encapsulation and Optimal Module Size and there he refers to the idea of defect density versus module size [Hatton97] being invariably with the chosen programming language!
So the obvious conclusion for the author was that the observation: “strongly reinforces the advice given elsewhere in this book to program with the most powerful languages and tools you can.”
Never forget that “the author” of TAOUP is ESR, so take what he says with a pinch of salt - he’s not exactly renowned for creating high quality software (except in his own mind).
Anyway, the conclusions are still valid (based in evidence from the mentioned Hatton’s paper). And they are coincident with Hague’s (but several years ago).
I heartily subscribe to this. Currently I mostly write in Python and I have increasingly come to avoid creating custom classes and data structures - lists and dicts are often all you need and fast enough. The only time I find myself using classes is when I need to define fields, and for that named tuples often work just fine.
One reason I like Ocaml is making specialized types for things is very low-overhead, it adds safety, and the types have zero runtime cost as they can be aliases to existing types. This is something I miss a lot in Python.
I also like OCaml (and Clojure which is about as pythonic as it gets), but a disavantage of custom types is that they are less general so it is harder to just compose stdlib functions to work on your data, you have to have bits of glue code here and there. Though the lack of type safety did bother me here and there when the data you put in does not match what you were expecting, so your code might break in subtle ways.
Like anything it’s a balancing act and it could be that the balance I have struck is less extreme than the one you have tried. Or it could be that the things you find bothersome about composition don’t bother me. But, FWIW, I have not experienced this pain you’re referring to. I do have
to_balhandfrom_blahtype functions, often, for my specialize type, and generally that extra step has been enough for me. I have been bit pretty heavily by Python types (or any dynamic language) not being what I expect, so even if that extra conversion is annoying I haven’t been too bothered by it. Often times, the only one one should manipulate the values I have is through API functions anyways, where the conversion isn’t a problem. So, YMMV.Go strongly encourages this by giving you slices (kinda like lists) and maps (essentially dictionaries) that are generic but making you jump through the hoop of writing an interface if you want your own snowflake container.
I think there’s a happy medium. Going full-on primitive obsession can be harmful. Encapsulating every tiny bit of knowledge can also be harmful. It’s useful to nudge people in one direction or another depending on circumstance, but it’s hard for me to come up with absolute rules that should be followed. Saying “it depends” is a lot less satisfying than claiming one end of the spectrum is better period.
To support that three claims there’s also a study referenced in The Art of Unix Programming. In chapter 4, the author speaks about Encapsulation and Optimal Module Size and there he refers to the idea of defect density versus module size [Hatton97] being invariably with the chosen programming language! So the obvious conclusion for the author was that the observation: “strongly reinforces the advice given elsewhere in this book to program with the most powerful languages and tools you can.”
Never forget that “the author” of TAOUP is ESR, so take what he says with a pinch of salt - he’s not exactly renowned for creating high quality software (except in his own mind).
Anyway, the conclusions are still valid (based in evidence from the mentioned Hatton’s paper). And they are coincident with Hague’s (but several years ago).