Essays on programming I think about a lot

Post by mac01021 » Tue, Jul 21, 2020, 2:50 PM UTC

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.

Post by greymalik » Tue, Jul 21, 2020, 2:53 PM UTC

twic wrote: post #54

holografix wrote: post #3

Earlier quoted context omitted.

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…

Post by mrkeen » Tue, Jul 21, 2020, 3:03 PM UTC

mgkimsal wrote: post #45

mrkeen wrote: post #29

Earlier quoted context omitted.

Yeah that sucks. Especially when you're designing service endpoints and your colleague insists upon reusing an existing endpoint instead of opening up a new one, because the two use cases looked the same when he squinted hard enough. Now instead of /credit-card and /debit-card, which are independently testable, debuggable and changeable, you just have /card. Can't change the debit logic in /card because it will break…

I feel your pain. Probably well past 'fixing' now, but a 'type' could be passed in with the payload, even if it's not exposed as the URL itself, no?

Post by [deleted] » Tue, Jul 21, 2020, 3:08 PM UTC

lmm wrote: post #17

3PS wrote: post #16

Earlier quoted context omitted.

Interesting that you mentioned Haskell. In my experience, I've found that every type having a bottom makes a lot of abstractions leaky.

1. Every type has a bottom in every mainstream language, most of them are just less explicit about it. 2. Bottoms do not make abstractions leaky in some generalised sense. The "fast and loose reasoning is morally correct" result applies: any abstraction that would be valid in a language without bottoms is still valid wherever it evaluates to a non-bottom value.

Post by wtetzner » Tue, Jul 21, 2020, 3:23 PM UTC

gnud wrote: post #27

lmm wrote: 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.