an hour ago by horsawlarway
I don't disagree with your title. I pretty strongly disagree with your content.
You started with a simple solution that nicely handles the current needs.
You then over-engineered a solution so badly that you haven't even noticed the 'url' param isn't used in the last method you've shown.
You went from simple enough a junior dev can make meaningful changes, to bloated enough the original author is fucking it up.
Don't do this. Wait until you actually have a REAL use case for adding complexity.
21 minutes ago by MrGilbert
> You then over-engineered a solution so badly that you haven't even noticed the 'url' param isn't used in the last method you've shown.
I think he wrote 'site' instead of 'url', so I'd call it a typo, but... I agree with what you wrote. For me, the article transports a wrong message. It's a thin line between YAGNI, KISS and OMGINTWNT[0]
[0]:"OMG, I NEVER THOUGHT WE'D NEED THAT!" - made this one up, sorry.
17 minutes ago by tomkwong
OP here. Thanks for the note.
The intention to illustrate the power of abstraction. Based upon yours and other people's comments below, perhaps it wasn't the best example.
I did correct the typo about 'url'. Best regards.
25 minutes ago by enneff
an hour ago by MaxBarraclough
> There is nothing wrong with this function. Really. It does exactly what it should do with the least amount of code. In fact, this is probably what I want to deploy in production as well. But, it is inflexible.
It does one well-defined thing, and does it well! That's the good kind of 'inflexible'.
> A skillful programmer looks at the problem and says, hey, why don't we build an abstraction layer to make it more flexible?
In this example, the additional complexity just doesn't seem justified. You ain't gonna need it. [0] Unnecessary abstractions cause bugs, bloat, and baggage. The article then goes on to acknowledge this, but I really question the chosen example.
> Just having these few abstractions opens up a lot of possibilities. Why? Let’s suppose that you have 3 different kinds of fetchers and 3 kinds of notifiers. Now, you can easily compose 3 x 3 = 9 different kinds of health checks.
You've just introduced an exponential explosion into your testing burden. The pay-off: additional functionality that might be useful later.
edit On reflection I suppose it's not a 'exponential explosion', it's merely a 'multiplicative explosion'.
> Enjoy your programming life. It's a fun art!
The article doesn't go into detail on what it means here, but the more serious the software work, the less the artistic mindset applies. [1]
I think the most sensible approach to software engineering is to draw satisfaction from solving a challenging problem well. Things like 'programmer freedom' strike me as false idols.
That said, I'm a sucker for elegance (a famously subjective commodity), so maybe I'm a hypocrite.
[0] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
[1] https://www.fastcompany.com/28121/they-write-right-stuff
40 minutes ago by horsawlarway
Ding ding ding. I agree one hundred percent. This isn't elegant, this is needlessly over engineered and now much more likely to slow development. The biggest cost isn't lines of code, it's understanding abstractions.
What happens when an "abstractnotifier" blows up? Where does the error happen? what are the possible side effects? What systems might be impacted?
What happens when 'alert's start failing? Is it queued/buffered? Do I need to worry about OOM errors on systems? Will it retry?
I lead a team of developers - This kind of abstraction tends to slow everything down. The only place it fits is during a refactor of software delivering real business value already. Basically - You can do this if you know exactly what your requirements are, and this nicely solves them.
If you do this before you understand EXACTLY what you need, you're going to be wrong. You will abstract the wrong pieces, with the wrong assumptions. I promise you. Then later you have to rip it all apart anyways, except now instead of 4 simple lines with clear consequences, you have a bloated monster of bad assumptions.
36 minutes ago by tomkwong
OP here. The code presented in the blog post was just an example although your points above are well taken. Practically, the decision to do abstraction or not depends on the use case and requirements.
an hour ago by cheez
> A skillful programmer looks at the problem and says, hey, why don't we build an abstraction layer to make it more flexible?
No he doesn't
3 hours ago by phkahler
One of the most beautiful pieces of code I've ever read is this:
https://github.com/solvespace/solvespace/blob/master/src/srf...
If you have a basic understanding of spline and NURBS surfaces but never knew how you might actually implement that, well there it is. Incredibly readable IMHO.
3 hours ago by paulcole
I see a lot of beauty in this.
3 hours ago by kgraves
sorry, but I see no beauty in this.
3 hours ago by phkahler
You have to read it to see the straight forward simplicity in it. Like I said, it also helps to have a high level understanding of the subject matter. The culmination at the end - finding the intersection point of 3 parametric surfaces - is artful IMHO.
3 hours ago by mathgladiator
I'm right there with you.
an hour ago by TheOtherHobbes
These articles reliably confuse art with craft and technique.
Art is about giving other people rich, engaging experiences that distill and/or highlight some element of relatable human emotional, psychological, and/or sensual experience.
The more unusual, original, and insightful the experience, the more interesting the art.
Doing something difficult with elegance is not art. Solving problems is not art. Complex but comprehensible systems that have "beauty" are not art.
If there's no emotional or sensual content, there's no art - just technique.
There's nothing wrong with technique, and art isn't better or worse than technique on its own terms. But they're different languages with different goals.
Calling software abstraction "art" is like watching someone who has discovered a for loop trying to persuade you they're an expert developer.
36 minutes ago by reikonomusha
I think you got it on the nose. I think folks who engage in more “traditional” arts (painting, music making, ...) really develop a distinction between these often interacting concepts. When playing an instrument, you distinguish between creative interpretation (art), musicality & sonic control (aural craft, imho), and manual or corporeal dexterity (technique). Of course, one’s ability to communicate a musical interpretation is propped up by the
(In very rare circumstances I might consider a program to be art, like the original metacircular Lisp evaluator, even if the author’s express intent wasn’t to appeal to somebody’s emotions.)
an hour ago by Tade0
This brought me back to the time my SO tried to explain an 84 year old lady she was assisting what is it that I do for a living.
The consensus was that I'm a writer.
Also there's one thing I ask everyone seeking to get into programming: "are you resistant to boredom?"
This appears to be a good predictor of future success.
an hour ago by WalterBright
I find football/baseball games to be incredibly boring. I posit that successful ball players must be highly resistant to boredom.
21 minutes ago by perl4ever
I consider myself very easily bored, and that's why I ended up programming, because every bit of coding is about eliminating repetition.
an hour ago by ironmagma
Hmm, interesting. I can’t tell, though, if that question means, “do you not bore easily?” or “do you avoid boredom at all costs?”
13 minutes ago by dkersten
> A skillful programmer looks at the problem and says, hey, why don't we build an abstraction layer to make it more flexible?
A skillful programmer doesn't add layers of abstraction unless there's a good reason or need to.
5 minutes ago by JoeAltmaier
The article was presuming a need? Otherwise there's nothing to discuss.
Yes, pedantically this approach is only used in certain circumstances. Then, a skillful programmer has a ready set of skills. And so on.
2 hours ago by tomkwong
Another way to express semantics is the use of Unicode in source code. For example, I have this Julia package that performs Box-Cox transformation, and I was able to use bold face for vector data and greek letters for the parameters as found in research paper and literatures.
https://github.com/tk3369/BoxCoxTrans.jl/blob/master/src/Box...
an hour ago by klysm
I’ve been conflicted about using verbose names or symbols for mathematical expressions in code, and I don’t think there’s an easy answer for when to use them. For simple arithmetic expressions, it seems like verbose names are superior because it’s easier to derive their meaning and we already understand the operators at play. When translating complex expressions, however, we usually a priori understand the meaning of the expression with our algebraic mental model and it makes sense to use that nomenclature. At the same time though, someone who is unfamiliar with the particular source of the algebra used would find such code quite opaque. For something like the Box-Cox transform I think it makes sense to use the symbols widely employed by the mathematical nomenclature.
This certainly also depends on the language you are using and the ability to define arbitrary in/postfix operations.
It’s also rather annoying to type them, but that’s also probably because I just haven’t developed a workflow for it.
3 hours ago by tomkwong
Interesting. Thanks for the share.
I wonder if programming fonts could achieve that - like the original author could specify a font for a portion of the code eg. a “destroy_context” or “drop_connection” function could have a scary look.
3 hours ago by 7373737373
Yeah! Or syntax highlighting that confers some emotional valence to runtime behavior (allocating resources - say, calling a constructor for instantiating objects - having a different color)
Daily Digest
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.