Live data from Hacker News

Essays on programming I think about a lot

benkuhn.net

51–60 of 99 posts

Re: Essays on programming I think about a lot

#51

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 solved in some library (or should be), and that customers invariably request solutions to problems that require complexity by joining simple systems.

Re: Essays on programming I think about a lot

#52

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 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.

Re: Essays on programming I think about a lot

#53

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 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.

I think that the thing about that talk that struck a chord is that he took a bunch of things that people had been talking about quite a bit - functional vs oop, mutability, data storage, various clean code-type debates, etc. - and extracted a clear mental framework for thinking about all of them.

Re: Essays on programming I think about a lot

#54
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.

The Sandi Metz talk/post included in the list touches on that:

https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

My takeaway from it is that we need to distinguish what you might call essential from incidental duplication. Essential duplication is when two bits of code are the same because they fundamentally have to be, and always will be, whereas incidental duplication is when they happen to be the same at the moment, but there's no reason for them to stay that way.

For example, calculating the total price for a shopping basket has to be the same whether it's done on the cart page or the order confirmation page [1], so don't duplicate that logic. Whereas applying a sales tax and applying a discount might work the same way now, but won't once you start selling zero-rated items, offering bulk discounts to which a coupon discount don't apply etc.

[1] Although i once built a system where this was not the case! In theory, the difference would always be that some additional discounts might be applied on the confirmation page. In theory ...

Re: Essays on programming I think about a lot

#55
post #27
post #26

Earlier quoted context omitted.

I don't think that's true. A lot of these abstractions are provably correct and so simply cannot leak (and in slightly more advanced languages you might even enforce those proofs - consider Idris' VerifiedMonad and friends). Of course if you put garbage in at the lower levels (e.g. define a monoid instance that doesn't actually commute) then you will get garbage out at the higher levels (e.g. the sum of the concatena…

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.

Yeah, and that is still completely pointless observation, because literally nothing I do will change because of it. Because if abstraction leaks in these edge cases, we are still better off trying to come up with same abstractions then not.

Re: Essays on programming I think about a lot

#56

Joe Armstrong's PhD thesis 'Making reliable distributed systems in the presence of software errors' is good reading. http://erlang.org/download/armstrong_thesis_2003.pdf

Definitely recommend. I recently bought a book on Amazon on distributed systems[0] which talked about fault tolerance without even a cursory mention of Joe Armstrong's work. I've returned the book, but I wish I could have browsed the bibliography before buying.

[0]: https://www.amazon.com/dp/1543057381

Re: Essays on programming I think about a lot

#57

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 think, the shift in programmer's perspective on where complexity should live is very much related to the idea of "the two styles in mathematics" described in this essay on the way Grothendieck preferred to deal with complexity in his work: http://www.landsburg.com/grothendieck/mclarty1.pdf.

Re: Essays on programming I think about a lot

#58
post #26
post #24

Earlier quoted context omitted.

I think we Haskellers have to be realistic and say that although it feels that many of our abstractions are non-leaking, they're only non-leaking in the sense that a modern, triply-glazed, thoroughly insulated house is non-leaking of heat compared to a draughty, cold house built 200 years ago. There are indeed leaks, but they are small and generally ignorable.

I don't think that's true. A lot of these abstractions are provably correct and so simply cannot leak (and in slightly more advanced languages you might even enforce those proofs - consider Idris' VerifiedMonad and friends). Of course if you put garbage in at the lower levels (e.g. define a monoid instance that doesn't actually commute) then you will get garbage out at the higher levels (e.g. the sum of the concatena…

Inside the computer abstractions are always leaky: the set of integers is finite; the reals are anything but.

Re: Essays on programming I think about a lot

#59

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…

> still don’t know if I understand what this presentation is about

1. The simplicity of a system or product is not the same as the ease with which it is built.

2. Most developers, most of the time, default to optimizing for ease when building a product even when it conflicts with simplicity

3. Simplicity is a good proxy for reliability, maintainability, and modifiability, so if you value those a lot then you should seek simplicity over programmer convenience (in the cases where they are at odds).

Post reply on HN