71–80 of 501 posts
For one thing, pizza recipes are either dynamically built by the customer or they are just fixed recipes.
Having individual functions for different predefined pizzas is not really dry enough for me.
I would have a pizzas.yaml file, and a get_pizza_recipe("id"). Maybe I'd even read pizza data from an excel spreadsheet directly for ease of editing and sharing by management if needed.
I have reached similar conclusion. DRY projects tend to snowball over the years into mess where every minor change is insanely difficult, breaks everything and code is hard to read, bugs are difficult to solve, diffs are difficult. WET code (opposite of DRY code, often starts as copy pasted) has more code, more typing, but the diffs are simple, bugs are simple (often you simply forgot to copy piece of code into 7 dif…
The problem with DRY is that it doesn't tell you how many repetition is too many. Here's my advice: don't refactor when you repeat yourself twice, refactor when repeat yourself _three_ times. Having one chance to copy-paste before DRY'ing your code has been one of my most treasured coding tricks, it'll save you so much time and premature refactoring.
If all your API does is return two pizza description jsons then keep it that way. If your client is a pizza delivery company and your api is supposed to allow definition and customization of pizza recipes, then you better take your ass to DRY town. Don’t blame the principle when you can’t understand what it is that you’re abstracting.
I have time and again gained enormous benefit by pursuing DRY principle to its absolute core. 20x speed and code complexity optimizations, making entire teams obsolete, etc. The most important point is to make sure that your abstractions absolutely match the fundamental principles of the concept you’re trying to represent. No matter how verbose you think it’s getting it’s totally worth it if this is your bread and butter.
Earlier quoted context omitted.
> Mistake 1: Switch from DRY to premature optimization. "Premature optimization" is largely a bogus concept, because the meaning of "optimization" has shifted a lot since the concept was first created. People now use optimization to mean "sensible design that does not needlessly waste resources". In this meaning of optimization, "premature optimization" is a bogus concept. You should absolutely ALWAYS write non-pessi…
The reasoning behind discouraging premature optimization makes no distinction between "micro optimizations" and any other kind, the purpose of this guidance is to minimize wasting time building unnecessarily complex solutions based on untested performance assumptions.
At the low levels you really have no idea where the performance bottle necks are without profiling and getting actual numbers to work with.
At the high level you pretty much have a clear idea of what roughly the system is supposed to do and what performance characteristics you want.
Earlier quoted context omitted.
Agreed. To use the example from the article `make_pizza(["pepperoni"])` What does `make_pizza()` do? It could be a lot or it could be a little. It could have side-effects or not. Now I have to read another function to understand it, rather than easily skimming the ~four lines of code that I would have to repeat. I think the article fails to show particularly problematic examples of DRY. E.g. merging two ~similar func…
Yup. But I guess that typically happens in steps. So next DRY-programmer that comes along will add a cheezeFilledCrust boolean to that make_pizza function and so on. Every time it will seem more reasonable to add another boolean, because otherwise you have to remove the make_pizza function, and there would be SO MUCH CODE DUPLICATION. I’ve seen this again and again in the field and I wholeheartedly agree with the sen…
So now you've dumped it down to an interface with a default implementation which calls the create_dough, add_toppings, bake_pizza interfaces in order, each of which are either passed in callbacks or discovered through reflection.
We can even sprinkle in some custom DSL to "abstract away" common step like putting the product into the oven correctly!
Jr's will never understand when why and what is effectively excecuted at runtime. Honestly, at this point I enjoy working with this kind of code. It's always such a high entertainment value and I get paid by the hour, so whatever
I am working in a code base right now that was literally ruined because of #3. It's full of extremely difficult to follow and test higher order functions that are completely unnecessary. A feature request did come for a "half/half" pizza and we're spending our days trying to disentangle the higher order functions. The developer who wrote this thought himself the programmer genius and wanted to make a pattern out of e…
>Argument by Authority may be a fallacy, but it is significantly more persuasive than other arguments. I looked at https://gordonc.bearblog.dev/ - I don't know why I would think this guy was any more of an authority on what was important than I am. So I'm not sure if anyone who thinks they're a programming genius would even care.
It’s like finding a third person on the internet to agree with you in a one-on-one, without exposing the person you disagree with to judgement of an actual third person.
Yes, I actually think OOP is not bad :)
But I disagree with their conclusion:
That the goal is to send a post with a single JSON object and marking this task as:
> That is a very, very simple thing to do
That is a very simple thing to do if you think that you will write this code once and never have to change it to fit some new requirements.
But probably there will be changes either from your own business or because the API will change thus the task becomes:
>
And as right now when you write this code you cannot know what kind of change will come in the future the best way to move forward is to write small functions with very few conditions and open to extensions.
Thus repeating that code there is not a good solution. What if the API will request to add any new key in the payload? And those two methods (def make_hawaiian_pizza and make_pepperoni_pizza) are not in the same file and the one doing the implementation is not the current author to remember "ahh the code is duplicated so I have to change it in multiple places"?
Anyhow there are cases when duplication is good, but when composing the payload for a request is not one of them :) IMHO.
Let me add to think one more thought: the structure of code tends to be duplicated in the future. So choose not to DRY having in mind that people who will write code after you will tend to make the same choice. They will look at what you wrote and then follow a similar structure.
So don't DRY but make sure you do this in a place where you will be ok with other people increasing the number of duplicate code.