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

81–90 of 99 posts

Re: Essays on programming I think about a lot

#81

Post by nordsieck »

akkartik wrote: post #76
_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 ->…

> But the users are all mathematical enough to want formal requirements.

This seems like a strange interpretation. I understand that the term "formal requirements" has a technical meaning in some disciplines, but I also think it's pretty clear that the author isn't using the term in that way.

It is much more likely that the author meant that users have requirements, but those requirements don't typically map cleanly to actions taken by the computer. This step of translation is necessary in the construction of a program, even if it is typically done piecemeal and iteratively.

Re: Essays on programming I think about a lot

#82

Post by chubot »

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.

Yeah, I think it depends on whether you're thinking about things from a SYSTEMS perspective or a CODE perspective.

Hickey clearly thinks about things from a systems perspective, which takes a number of years to play out.

You need to live with your own decisions, over large codebases, for many years to get what he's talking about. On the other hand, in many programming jobs, you're incentivized to ship it, and throw it over the wall, let the ops people paper over your bad decisions, etc. (whether you actually do that is a different story of course)

Junior programmers also work with smaller pieces of code, where the issues relating to code are more relevant than issues related to systems.

By systems, I mean:

- Code composed of heterogeneous parts, most of which you don't control, and which are written at different times.

- Code written in different languages, and code that uses a major component you can't change, like a database (there's a funny anecdote regarding researchers and databases in the paper below)

- Code that evolves over long periods of time

As an example of the difference between code and systems, a lot of people objected to his "Maybe Not" talk. That's because they're thinking of it from the CODE perspective (which is valid, but not the whole picture).

What he says is true from a SYSTEMS perpective, and it's something that Google learned over a long period of time, maintaining large and heterogeneous systems.

https://lobste.rs/s/zdvg9y/maybe_not_rich_hickey

tl;dr Although protobufs are statically typed (as opposed to JSON), the presence of fields is checked AT RUNTIME, and this is the right choice. You can't atomically upgrade distributed systems. You can't extend your type system over the network, because the network is dynamic. Don't conflate shape and optional/required. Shape is global while optional/required is local.

If you don't get that then you probably haven't worked on nontrivial distributed systems. (I see a lot of toy distributed computing languages/frameworks which assume atomic upgrade).

-----

His recent History of Clojure paper is gold on programming language design: https://clojure.org/about/history

I read a bunch of the other ones. Bjarne's is very good as usual. But Hickey is probably the most lucid writer, and the ideas are important (even though I've never even used Clojure, because I don't use the JVM, which is central to the design).

Re: Essays on programming I think about a lot

#83

Post by mumblemumble »

mac01021 wrote: post #59
breckenedge wrote: post #51

Earlier quoted context omitted.

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 s…

I find the graph at the top of Sandi Metz's article "Breaking up the Behemoth" (https://sandimetz.com/blog/2017/9/13/breaking-up-the-behemot...) to be poignant.

If you agree with her hypothesis, what it's basically saying is that a clean design tends to feel like much more work early on. And she goes on to suggest that early on, it's best to focus on ease, and extract a simpler design later, when you have a clearer grasp of the problem domain.

Personally, if I disagree, it's because I think her axes are wrong. It's not functionality vs. time, it's cumulative effort vs. functionality. Where that distinction matters is that her graph subtly implies that you'll keep working on the software at a more-or-less steady pace, indefinitely. This suggests that there will always be a point where it's time to stop and work out a simple design. If it's effort vs. functionality, on the other hand, that leaves open the possibility that the project will be abandoned or put into maintenance mode long before you hit that design payoff threshold.

(This would also imply that, as the maintainer of a programming language ecosystem and a database product that are meant to be used over and over again, Rich Hickey is looking at a different cost/benefit equation from those of us who are working on a bunch of smaller, limited-domain tools. My own hand-coded data structures are nowhere near as thoroughly engineered as Clojure's collections API, nor should they be.)

Re: Essays on programming I think about a lot

#84

Post by fanf2 »

TomMarius wrote: post #50
JoeSmithson wrote: post #11

Earlier quoted context omitted.

The reason UDP is less leaky is not because it meets any guarantee better, but because it guarantees less

IMHO the switch to UDP is happening because the work TCP is doing to ensure reliability is now done at network and thus having TCP do it is redundant. TCP assumed very simple and dumb network, which is no longer the case.

You should have a look at the paper “end-to-end arguments in system design” - http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen...

More or less reliability in the datagram layers affects performance - for example, WiFi does its own retransmissions whereas ethernet does not, because WiFi uses a less reliable physical layer, and because you don’t want your packets to have to go from London to New York and back before you discover one of them was lost.

But reliability at the WiFi later cannot give your application the semantics of an ordered data stream, so it is not a substitute for TCP. You can replace TCP with a different transport protocol if you want different behaviour, eg SCTP or DTLS or QUIC, but in all cases they are providing a higher level abstraction than raw datagrams, not just (and not necessarily) more reliability.

Re: Essays on programming I think about a lot

#85

Post by cannabis_sam »

netcan wrote: post #49
cannabis_sam wrote: post #43

Earlier quoted context omitted.

I hate it, because it’s either: A) not a law, but a principle B) a tautology (formally the essence is “All non-trivial abstractions are non-trivial”) (Let alone the weaselly “to some degree“)

I think this is a little pedantic. "Not a law" is strictly tue, but the "law" idiom is totally in-line with "law of supply and demand," "law of diminishing returns," etc. The tautology problem is not a problem. Tautologies are powerful. Douglas Adams has a great essay on this, but his novel version is more concise. If you want strict laws and no "to some degree" hedges, read physics.

> but the "law" idiom is totally in-line with "law of supply and demand," "law of diminishing returns," etc.

Which I equally detest.

> The tautology problem is not a problem. Tautologies are powerful.

They are, of course, but how is the statement tautologically useful in this context?

> If you want strict laws and no "to some degree" hedges, read physics.

Sure, but physics is not the only field that does not consist of, mostly, overly general, extrapolation of empirical, but ephemeral phenomena.

Re: Essays on programming I think about a lot

#87

Post by TheCoelacanth »

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

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

I would argue that the "correct" behavior of a RAM chip is an abstraction over the actual physical behavior.

That abstraction leaks when the actual physical behavior of a RAM chip differs from the abstract specification that it implements.

Re: Essays on programming I think about a lot

#88

Post by akkartik »

nordsieck wrote: post #81
akkartik wrote: post #76

Earlier quoted context omitted.

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

> But the users are all mathematical enough to want formal requirements. This seems like a strange interpretation. I understand that the term "formal requirements" has a technical meaning in some disciplines, but I also think it's pretty clear that the author isn't using the term in that way. It is much more likely that the author meant that users have requirements, but those requirements don't typically map cleanly…

It's a strange interpretation only if you focus on just the vocal minority that talks about formal requirements. Here are two quotes by Hillel Wayne (https://www.hillelwayne.com/post/why-dont-people-use-formal-...), whom I've found to have the most balanced take:

"The problem with finding the right spec is more fundamental: we often don’t know what we want the spec to be. We think of our requirements in human terms, not mathematical terms. If I say “this should distinguish parks from birds”, what am I saying? I could explain to a human by giving a bunch of pictures of parks and birds, but that’s just specific examples, not capturing the idea of distinguishing parks from birds. To actually translate that to a formal spec requires us to be able to formalize human concepts, and that is a serious challenge."

"It’s too expensive doing full verification in day-to-day programming. Instead of proving that my sort function always sorts, I can at least prove it doesn’t loop forever and never writes out of bounds. You can still get a lot of benefit out of this."

The post makes a strong case, IMO. Formal methods can be valuable, but they don't have the track record yet for anyone to believe they're the #1 essential thing about programming.

Re: Essays on programming I think about a lot

#89

Post by lmm »

TheCoelacanth wrote: post #87
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…

I would argue that the "correct" behavior of a RAM chip is an abstraction over the actual physical behavior. That abstraction leaks when the actual physical behavior of a RAM chip differs from the abstract specification that it implements.

That's not exactly false, but at that point you might as well say that anything that breaks is an abstraction leak. If my car won't start in the morning, is that an "abstraction leak"? I don't think it is (or at least I don't think it's a useful perspective to see it as one), because the problem wasn't that I was thinking of the abstract notion of a car rather than the details of a bunch of different components connected together in particular ways; the problem is that one or more of those components is broken (or maybe that some of the components are put together wrong).

Re: Essays on programming I think about a lot

#90

Post by lmm »

Koshkin wrote: post #58
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…

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

WTF? The set of integers isn't finite. There are non-leaky ways to represent integers or computable reals in a computer (of course one cannot compute uncomputable reals, by definition). And plenty of finite subsets of either are well-behaved and non-leaky. If you treat a finite subset of the integers as being the set of all integers then of course you will make mistakes, but that's not a problem of abstraction.
Post reply on HN