Donkey code
einarwh.wordpress.com
Donkey code
1–10 of 64 posts
Re: Donkey code
#2Besides the naming, the code examples because it uses an ask-then-do-different-things anti-pattern rather than Tell-Dont-Ask which implies defining distinct classes (or property values that define behaviors in the thing itself) rather than strewn across the codebase by interpretation, ie. there was no factoring only use-site decisions.
The problem wasn't lack of naming, it was incomplete defining of the thing. If it had a definition that everyone agreed upon, the name is arbitrary like naming of celestial bodies.
Re: Donkey code
#3Besides the naming, the code examples because it uses an ask-then-do-different-things anti-pattern rather than Tell-Dont-Ask which implies defining distinct classes (or property values that define behaviors in the thing itself) rather than strewn across the codebase by interpretation, ie. there was no factoring only use-site decisions. The problem wasn't lack of naming , it was incomplete defining of the thing . If i…
This is a helpful way to think about it. Though, is the problem of having an incomplete definition the same as lacking a unique name? Maybe the solutions are different, and the author points out that made-up names don't cut it. Is it instead more of a catch-22 situation?
The other dimension implied here is the timing of when variety is introduced. If all the options were known when the system was originally designed, the issue may have been more clear. So then the other problem is that, when the need to distinguish between cases first came up, the solution was designed for only 2 cases. And if there were only ever those two cases, the solution presented would probably be the most efficient.
The solution to this incremental scope problem is a lot less clear to me and something I struggle with personally in scientific computing projects. When variety #2 pops up, how does one decide whether to restructure everything in case of a variety #3, or take the quicker (potentially more efficient) path and avoid unnecessary complexity? Assuming I've done as much as I can to anticipate and constrain my needed functionality. It somehow feels like I end up losing either way.
Re: Donkey code
#4The writing style is very beautiful.
Re: Donkey code
#5Interesting read, I try to give a lot of thought to naming things but still can’t get it right first time. Often I need the courage to refactor, which also involves changes to a lot of documentation. Also, retaining backwards compatibility is tough when renaming things so proper names can’t always be used
Re: Donkey code
#6Besides the naming, the code examples because it uses an ask-then-do-different-things anti-pattern rather than Tell-Dont-Ask which implies defining distinct classes (or property values that define behaviors in the thing itself) rather than strewn across the codebase by interpretation, ie. there was no factoring only use-site decisions. The problem wasn't lack of naming , it was incomplete defining of the thing . If i…
This is a helpful way to think about it. Though, is the problem of having an incomplete definition the same as lacking a unique name? Maybe the solutions are different, and the author points out that made-up names don't cut it. Is it instead more of a catch-22 situation? The other dimension implied here is the timing of when variety is introduced. If all the options were known when the system was originally designed,…
First you have to make things worse. You just proudly {horse breed: zebra} then {horses breed: sofa} and so on.
Re: Donkey code
#7The writing style is very beautiful.
Yeah, it's gorgeous. Makes me jealous. Reminds me of some author I read recently but I can't put my name on them...
Re: Donkey code
#8This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not to mention it's super long.
Just name your things as things. Name it Pluto, Calvin, Steve, Jon, Ted, Ann, Mobius, Orpheus, Martha, Alex... I don't care. Maybe even Tomato, Artichoke, Celery, Broccoli, Pumpkin, Rooibus etc... It just needs to be as neutral as possible.
This is the power of mathematics really. When I say "monoid" do you have any idea what it might be? No, well that's great, because here is a very formal definition of this thing called "monoid". Old school names like "group", "category" etc are worse. Names like "Kolmogorov complexity", "P-Complete", "Galois Field", "Ultrafilter" are much better.
Re: Donkey code
#9This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…
Agreed. And might as well use one-syllable words that are pleasant to read / write (e.g. bob, tom, box, rack, sun).
Re: Donkey code
#10[deleted]