Don't be clever • Hacker News Board

Re: Don't be clever

#101

Post by pphysch » Thu, Aug 03, 2023, 3:20 PM UTC

dmoy wrote: post #99

pphysch wrote: post #94

Earlier quoted context omitted.

> But if you want to make even a single tiny modification to one of the generated files, you're busted, you need a different solution. Not totally true, if you can robustly express your tiny change as a `sed` or `awk` script, you can just append to the generator pipeline. Speaking from experience, do not condone, etc.

I think GP means "make a tiny change [after generation, outside of the generator, and persist that change independent of the generator code]", which is where all the demons are waiting Modifying the generator itself to do something different every time, and doing GP's stated "regenerate and throw away the old stuff" is in line

It's not modifying the generator. The generator may be a proprietary black box. It's wrapping the generator in a bash script that pipes the result through AWK, etc.

Re: Don't be clever

#102

Post by lijok » Thu, Aug 03, 2023, 3:21 PM UTC

shrimp_emoji wrote: post #84

BowBun wrote: post #80

Earlier quoted context omitted.

First time I've heard this, I love it. Definitely resonates both as the one who is there first, and then future ambitious folks would rather rebuild than understand and extend. Also, relatable when I come in somewhere and immediately start thinking about how I would re-build something instead of improving it. We sure have a lot of hubris in software, don't we?

If you're looking at a giraffe's laryngeal nerve[0], you see it making a circuit from the jaw, down the loooong neck, to the chest, back up the loooong neck, and to the jaw again. It's like this because it used to be an small, innocent "u" shape back before giraffes evolved long necks. As their necks elongated, there was never any effort to rewire the nerve, so it elongated too. When encountering that situation, the…

I hope you regularly give talks. You would be an amazing speaker.

Re: Don't be clever

#103

Post by lijok » Thu, Aug 03, 2023, 3:22 PM UTC

catchnear4321 wrote: post #18

lijok wrote: post #11

At a consulting gig I did, we were bootstrapping a brand new python engineering team for a new line of products. We chose the frameworks, set standards via decision records, wrote a template service that you would copy paste, and build on top. Cross cutting concerns were pulled out into a library that all of these services installed. Most things were standardized, all APIs felt like they were written by a single pers…

that’s the danger. you built a system for cogs. someone hired a thinker.

Very good point, eloquently worded

Re: Don't be clever

#104

Post by xwowsersx » Thu, Aug 03, 2023, 3:23 PM UTC

Not disagreeing with the core assertion in this post because I think the author is correct that you can absolutely over-engineer things. But one thing I don't quite understand.

> Some controllers had to do some things a little differently.

....

> And young me? I just kept going. Adding the proverbial knobs and pulls to my abstract class

Aren't the ways in which the concrete implementations vary supposed to be in the subclasses? One of the points of the abstract base class is to encapsulate common behavior. For things that differ, those belong in the concrete implementations. So _one_ of the mistakes here was to try to write a god class that could anticipate all of the ways in which the subclasses differ and to encode those into the abstract class in order to leave the subclasses as simple as having to specify the entity type.

I guess that was the author's point ha?

Re: Don't be clever

#105

Post by reidjs » Thu, Aug 03, 2023, 3:23 PM UTC

turnsout wrote: post #81

misja111 wrote: post #7

Earlier quoted context omitted.

I think this is because most literature focusses on exactly those things. Design patterns to be one step ahead of some obscure future usage of your API, FP patterns to abstract your API into a 'something' that you could not just use to aggregate customer account balances in the database but, say, merge arbitrary lists as well etc. It's rare to find literature that tells you -not- to use new frameworks or design patte…

Yeah, you've hit the nail on the head—no one got rich selling a book called "There Is No Magic Bullet: Everything Sort of Depends"

Now I'm tempted to write that book, maybe it could work. Find examples of things people desire and write the simple 'common knowledge' rules to achieve it, acknowledging the role of bad/good luck.

Want to be healthy, in good shape? Get lots of sleep, eat well, exercise. Unless you suddenly get cancer.

Want to be rich? Work a steady, boring job that pays well and live below your means. Unless a financial disaster occurs and you lose all that money you saved up.

etc.

Re: Don't be clever

#106

Post by Sujeto » Thu, Aug 03, 2023, 3:25 PM UTC

I disagree. You could have done a better system. I think it's a must to be "clever" regarding code, especially if the repetition is huge.

Re: Don't be clever

#107

Post by burglins » Thu, Aug 03, 2023, 3:26 PM UTC

Oh no, the conclusion is so funny. That's the problem with "magic frameworks" like ASP.NET, where it's not obvious how to extend things if need be (if even possible).

Re: Don't be clever

#108

Post by CaptArmchair » Thu, Aug 03, 2023, 3:33 PM UTC

xwowsersx wrote: post #104

Not disagreeing with the core assertion in this post because I think the author is correct that you can absolutely over-engineer things. But one thing I don't quite understand. > Some controllers had to do some things a little differently. .... > And young me? I just kept going. Adding the proverbial knobs and pulls to my abstract class Aren't the ways in which the concrete implementations vary supposed to be in the…

I think the point of the author was that as a young - implied: inexperienced - developer he was blinded by the power of being able to describe the world in code; and inadvertently got stuck in the rabbit hole.

Learning to take a step back and discern the best fitting abstractions that allow modeling the business domain is a learned skill. There's a difference between learning about object inheritance in school, and actually applying it in big projects where the effects only become apparent over the course of months.

Re: Don't be clever

#109

Post by sfn42 » Thu, Aug 03, 2023, 3:37 PM UTC

catchnear4321 wrote: post #18

lijok wrote: post #11

At a consulting gig I did, we were bootstrapping a brand new python engineering team for a new line of products. We chose the frameworks, set standards via decision records, wrote a template service that you would copy paste, and build on top. Cross cutting concerns were pulled out into a library that all of these services installed. Most things were standardized, all APIs felt like they were written by a single pers…

that’s the danger. you built a system for cogs. someone hired a thinker.

Eh, in this case your "thinker" sounds kinda dumb to me.

Re: Don't be clever

#110

Post by raincole » Thu, Aug 03, 2023, 3:38 PM UTC

mcv wrote: post #95

sanderjd wrote: post #66

Earlier quoted context omitted.

Generating code is fine, if the generated code strictly never evolves independently of what it is generated from. For instance generating libraries from .proto files (or other declarative schema definition solutions) works really well. If the schema changes, you throw away the old generated code and generate brand new code, no problem. But if you want to make even a single tiny modification to one of the generated fi…

Generated code is fine if it's newly generated on every build. If you're going to have to maintain the generated code, it's not generated code anymore, but duplicated code.

Yes and the original article is about how duplicated code is ok. The discussion finally went the full circle.