Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't be clever

stitcher.io

Post reply on HN
Print view View original

181–190 of 231 posts

Re: Don't be clever

#181

Post by robomc »

jbandela1 wrote: post #15

> Yes, I had failed to see the proper solution: a class generator — so that I didn't have to manually copy code again No, please don't. This is jumping from the frying pan into the fire. If you think abstract base classes can be clever and hard to understand, code generators can be even more so. In addition, because code generators are a one way conversion, and the generated code evolves independently and the code ge…

Yeah surely a better approach is... rather than inheriting from an all powerful class, just compose controllers out of modules. Some used in almost every controller. Some pretty specific to one or two edge cases.

Like the problem was having an all-or-nothing inheritance model for shared functionality, which also ended up very long and intimidating.

I also don't really understand why emerging edge cases caused him to complicate his 90%-perfect parent class instead of just... overriding specific functions in the children. (The specifics of these overrides will probably make you want to refactor your parent class so that the overrides have clean joints but you shouldn't just dump the new child-specific logic into your parent)

Re: Don't be clever

#182

Post by thom »

gnat wrote: post #174

Larry Wall said something like "if you have a complex problem, the complexity will come up somewhere -- either you have a complex language and a simple program, or a simple language and a complex problem. The complexity can't be wished away." Being Larry, he said it far better but I can't find the exact quote. All programming is making models: representing a chaotic and changing analog world in bits, data structures,…

Very well put. Effective businesses are good at communicating and sharing these models so everyone is able to reason about them, and if they’re lucky anticipate future articulation points.

Re: Don't be clever

#183

Post by summerlight »

jbandela1 wrote: post #15

> Yes, I had failed to see the proper solution: a class generator — so that I didn't have to manually copy code again No, please don't. This is jumping from the frying pan into the fire. If you think abstract base classes can be clever and hard to understand, code generators can be even more so. In addition, because code generators are a one way conversion, and the generated code evolves independently and the code ge…

One good thing with a code generation approach is that we can actually inspect into the generated code and see what's going to happen in a relatively easier way. And it's usually working nicely with static analysis. For abstract base class or whatever, it's kind of hard to do.

Of course, code generator (or even compiler) is harder to maintain, especially when you want the output to be human readable. So it's always about trade-off. Think about how many lines of code it's going to generate. If it's an order of 100k then it's usually worth the cost. 10k might be good to go. 1k, probably not.

Re: Don't be clever

#184

Post by mostlylurks »

misja111 wrote: post #7
turnsout wrote: post #2

It seems like every coder needs to learn this the hard way at some point. “I’ll save so much time!”

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…

People often learn the wrong lessons from literature. Design patterns, for instance, are something you should learn, not as tools that you should eagerly find applications for, but rather as a shared understanding of the kinds of patterns that commonly occur in code, such that you have the right vocabulary to communicate about them with others, and such that you can easily recognize them when they occur in the code. You'll almost inevitably utilize various design patterns extensively in your code even if you've never heard of "design patterns", learning about them simply lets you understand what's happening.

Re: Don't be clever

#186

Post by lanstin »

rubicks wrote: post #171
mcv wrote: post #95

Earlier quoted context omitted.

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.

Seconded. How many in this thread have found generated code in source control? My trophy case includes artifacts produced by: flex, bison, gperf, swig, and one particularly nasty CORBA stub generator.

No Perl?

Re: Don't be clever

#187

Post by duderific »

mcv wrote: post #96

I don't understand why he added all those exceptions to the abstract class. That's not what abstract classes are for. The initial code example shows an implementation class inheriting from the abstract class; that seems like the perfect place for exceptions. Why not simply use that most basic feature of OOP? Override the parts of your abstract class that you need to override.

I guess he wanted to make sure that the subclass code would be as simple as possible. So when he wanted to add a new entity to his model, as he mentioned, he only had to extend the abstract class, without writing any new business logic.

Clearly what you're saying is correct, however, it would mess up his original intent, which was frictionless extensibility.

Re: Don't be clever

#188

Post by m463 »

jbandela1 wrote: post #15

> Yes, I had failed to see the proper solution: a class generator — so that I didn't have to manually copy code again No, please don't. This is jumping from the frying pan into the fire. If you think abstract base classes can be clever and hard to understand, code generators can be even more so. In addition, because code generators are a one way conversion, and the generated code evolves independently and the code ge…

I think one lesson newer programmers fail is that sometimes copy/paste is not only OK, but preferred.

One time this is good is when helping others get up to speed. Other people can copy/paste your examples and be functioning right now.

But if you have a function that you put in to eliminate some duplication, they have to understand this new abstraction layer before they can start working.

Re: Don't be clever

#189

Post by hu3 »

slifin wrote: post #145

Composer/PHP never really supported proper autoloading of functions So everything is a class The majorities language's community has this super weird Java obsession The other half has a Rails obsession The best career decision I ever made was to watch the Rich Hickey talks 2x my wage in a few years and don't have to care about any of this obvious mis-match ever again

Could I ask what kind of tech you work now? I'm interested in Rich Hickey's pov.

Re: Don't be clever

#190

Post by oefnak »

beachy wrote: post #153
tomjakubowski wrote: post #141

Earlier quoted context omitted.

Well if we're being anal about the metaphor, in construction and renovation, the scaffolding eventually goes away. Scaffolded code rarely disappears entirely; some of it usually sticks around.

To be perhaps even more anal, after construction scaffolding is taken down, stored, transported to a new project and then used again.

And it's made of steel, not bits.
Post reply on HN