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

Essays on programming I think about a lot

benkuhn.net

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Essays on programming I think about a lot

#71

Post by AnimalMuppet »

wtetzner wrote: post #69
gnud wrote: post #27

Earlier quoted context omitted.

You are abstracting over a CPU and memory. Your abstraction leaks in that memory layout actually matters for performance, for example. Or if you have a bad RAM chip.

> You are abstracting over a CPU and memory. Your abstraction leaks in that memory layout actually matters for performance, for example. I find the idea that an abstraction is leaky if different implementations of it perform differently to be fairly useless. I don't think it's a useful concept unless the abstraction captures the expected performance. If the abstraction doesn't give any performance guarantees, then th…

Performance matters sometimes. If you're in a situation where performance matters, and the abstraction doesn't capture the expected performance, but you're subject to the abstraction's actual performance anyway, then the abstraction leaked in a way that matters to you.

Re: Essays on programming I think about a lot

#72

Post by AnimalMuppet »

holografix wrote: post #3
simonw wrote: post #2

So glad to see the Law of Leaky Abstractions in there - that's had a very long-running impact on how I think about programming. It's still super-relevant today, nearly 18 years after it was published. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

I’m going through the conversation with a colleague atm where he believes DRY applies to everything.

Well... early in my career, a colleague and I developed a bit of a mantra: "Did you fix it everywhere?" Later in my career, I learned the value of there only being one place to have to fix.

At the same time, too much DRY can over-complicate (and even obfuscate) your code. That's not the answer either.

Taste. Taste, experience, and wisdom. But I don't know how to give them to someone who doesn't have them. Maybe by pointing out the problems of specific things they're trying to do, in a way that they (hopefully) can understand and see why it's going to be a problem. Maybe...

Re: Essays on programming I think about a lot

#73

Post by mormegil »

mhink wrote: post #5

Love the list, but I definitely think Programming Sucks [1] should be on any list of programming essays. :) 1: https://www.stilldrinking.org/programming-sucks

I guess I have read this already, but did not remember it very much. Halfway through, I thought it was written by James Mickens. So, if you liked this, you might also like Mickens' essays like The Night Watch " rel="nofollow">http://scholar.harvard.edu/files/mickens/files/thenightwatch.... All should be available at https://mickens.seas.harvard.edu/wisdom-james-mickens And they are not only very funny, but also insightful.

Re: Essays on programming I think about a lot

#74

Post by kaio »

twic wrote: post #52
Cthulhu_ wrote: post #34

Earlier quoted context omitted.

I still can't believe that I was actually there during that exact presentation but at the time it didn't have the impact on me that it seems to have had on HN as a whole. Maybe I should review it again, or maybe I'm just not smart enough / don't have the right mindset, IDK.

Rich Hickey seems to be a bit of a Necker cube. Some people i know and respect think he is a deep and powerful thinker. But to me his talks always seem like 90% stating the obvious, 10% unsupported assertions.

That is the key: stating the obvious actually is hard and I think Rich does a beautiful job to translate the thoughts and feelings most programmer have into words. It actually gives a way to discuss and think about things (especially design and architecture) with others. I learned that there is no such thing as "common ground" or common knowledge magically and intuitively shared by all programmers. So if this already reflects your thoughts - even better.

Re: Essays on programming I think about a lot

#75

Post by chowells »

AnimalMuppet wrote: post #71
wtetzner wrote: post #69

Earlier quoted context omitted.

> You are abstracting over a CPU and memory. Your abstraction leaks in that memory layout actually matters for performance, for example. I find the idea that an abstraction is leaky if different implementations of it perform differently to be fairly useless. I don't think it's a useful concept unless the abstraction captures the expected performance. If the abstraction doesn't give any performance guarantees, then th…

Performance matters sometimes. If you're in a situation where performance matters, and the abstraction doesn't capture the expected performance, but you're subject to the abstraction's actual performance anyway, then the abstraction leaked in a way that matters to you.

You've found that the abstraction isn't useful for doing your task. That's not leaking. That's like complaining that your ice cream maker can't cook rice. That's not what it's for.

In fact, this is a common manner for abstractions to become leaky. You find you are in need some guarantee not present in the abstraction. You choose to add whether or not that guarantee is satisfied to the shared interface. Congratulations! You've added a leak to the abstraction.

But that's not the only option available. If you need a guarantee not provided by an abstraction, you could ignore the abstraction and use something that actually provides the guarantees you need.

Re: Essays on programming I think about a lot

#76

Post by akkartik »

_pmf_ wrote: post #21

I only think about "Out of the Tar Pit".

I've never understood why people like this paper. Over the years I've evolved a bite-sized rebuttal, if anybody wants to fight me:

The authors' "ideal world" is one where computation has no cost, but social structures remain unchanged, with "users" having "requirements". But the users are all mathematical enough to want formal requirements. The authors don’t seem to notice that the arrow in "Informal requirements -> Formal requirements" (pg 23) may indicate that formal requirements are themselves accidental complexity. All this seems to illuminate the biases of the authors more than the problem.

Link to the paper, for convenience: http://curtclifton.net/papers/MoseleyMarks06a.pdf. I think it's a siren and takes away attention that could be spent on better papers.

Re: Essays on programming I think about a lot

#77

Post by AnimalMuppet »

chowells wrote: post #75
AnimalMuppet wrote: post #71

Earlier quoted context omitted.

Performance matters sometimes. If you're in a situation where performance matters, and the abstraction doesn't capture the expected performance, but you're subject to the abstraction's actual performance anyway, then the abstraction leaked in a way that matters to you.

You've found that the abstraction isn't useful for doing your task. That's not leaking. That's like complaining that your ice cream maker can't cook rice. That's not what it's for . In fact, this is a common manner for abstractions to become leaky. You find you are in need some guarantee not present in the abstraction. You choose to add whether or not that guarantee is satisfied to the shared interface. Congratulatio…

I have to care about what's inside it (to know whether the performance is up to what I need) rather than just the interface. To me, that's leaking.

For example, if I have to care whether the "collection" is implemented as a linked list or as a vector, the the "collection" abstraction has leaked.

Re: Essays on programming I think about a lot

#78

Post by rovolo »

mercer wrote: post #31
nordsieck wrote: post #6

Sadly it's a video/presentation, not an essay, but Simple Made Easy[1] is the single software argument that has made the most impact on me. ___ 1. https://www.infoq.com/presentations/Simple-Made-Easy/

I don't have a transcript link at hand, but as far as videos go, "Functional Core, Imperative Shell" / "Boundaries" by Gary Berhardt is also a must-see (or must-read, hopefully).

Here's the video link:

https://www.destroyallsoftware.com/screencasts/catalog/funct...

Unfortunately there's no transcript on the official video

Re: Essays on programming I think about a lot

#79

Post by nordsieck »

breckenedge wrote: post #51
nordsieck wrote: post #6

Sadly it's a video/presentation, not an essay, but Simple Made Easy[1] is the single software argument that has made the most impact on me. ___ 1. https://www.infoq.com/presentations/Simple-Made-Easy/

I’ve been programming for a long time, watched this presentation several times, done a bunch of other research, and still don’t know if I understand what this presentation is about. I fear that I’ve tried to apply these simple-vs-complex principles and only made my code harder to understand. My understanding now is that complexity for every application has to live somewhere, that all the simple problems are already s…

> I fear that I’ve tried to apply these simple-vs-complex principles and only made my code harder to understand. My understanding now is that complexity for every application has to live somewhere, that all the simple problems are already solved in some library (or should be), and that customers invariably request solutions to problems that require complexity by joining simple systems.

Simplicity exists at every level in your program. It is in every choice that you make. Here's a quick example (in rust):

    fn f(i) -> i32 { i }      // function
    let f = |i| -> i32 { i }; // closure
The closure is more complex than the function because it adds in the concept of environmental capture, even though it doesn't take advantage of it.

This isn't to say you should never pick the more complex option - sometimes there is a real benefit. But it should never be your default.

You are correct in your assessment that customers typically request solutions to complex problems. This is called "inherent complexity" - the world is a complex place and we need to find a way to live in it.

The ideal, however, is to avoid adding even more complexity - incidental complexity - on top of what is truly necessary to solve the problem.

Re: Essays on programming I think about a lot

#80

Post by dllthomas »

Koshkin wrote: post #62
lmm wrote: post #47

Earlier quoted context omitted.

> Your abstraction leaks in that memory layout actually matters for performance, for example. There are cache-aware abstractions if your situation warrants them. Of course if you abstract over a detail then you lose control over that detail. But that's not the same as a leak, and it's the very essence of programming at all; if the program needs to behave differently every time it runs, then creating a useful program…

Right. As they say, In theory there is no difference between theory and practice; in practice, there is.

Get better theory.
Post reply on HN