23 ms·

Essays on programming I think about a lot

438 points by jchook 6y ago

simonw 6y ago
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-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
- holografix 6y ago
  I’m going through the conversation with a colleague atm where he believes DRY applies to everything.
  - bryanrasmussen 6y ago
    by everything you mean outside of programming also? Or just in programming? I guess I find DRY pretty important for me, as a tool to force me to abstract and to help me understand the system I'm working on.
  - yakshaving_jgt 6y ago
    It usually helps to point out that DRY and loosely-coupled are often two sides of the same coin.
  - hinkley 6y ago
    When everything is DRY you get the Sahara Desert. Some things should be DAMP every so often, and at regular intervals.
  - mrkeen 6y ago
    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 credit. Can't change the credit logic in /card because it will break debit.
    - mgkimsal 6y ago
      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?
      - mrkeen 6y ago
        I definitely would have done that if I had the choice. However the endpoint owner just insisted I just send nulls for the fields I didn't have.
  - bcrosby95 6y ago
    The problem isn't DRY. The problem is most programmers' inability to tear down abstractions that aren't correct for your new requirements when they evolve.
  - twic 6y ago
    The Sandi Metz talk/post included in the list touches on that: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction 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 ...
    - greymalik 6y ago
      I don’t understand why people interpret that article as recommending you avoid prematurely removing duplication and comparing it to the rule of 3. The point of her essay is that you should resist the sunk cost fallacy and refactor your duplication-removing abstractions when requirements (or your understanding of them) change.
  - jchook 6y ago
    Some good resources about DRY: > DRY is about knowledge. Code duplication is not the issue. https://verraes.net/2014/08/dry-is-about-knowledge/ https://verraes.net/2014/08/dry-is-about-knowledge/ > Every piece of knowledge must have a single, unambiguous, authoritative representation within a system https://wiki.c2.com/?DontRepeatYourself https://wiki.c2.com/?DontRepeatYourself
  - AnimalMuppet 6y ago
    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...
- lmm 6y ago
  It's nonsense, written because Joel had never used a language with a decent type system. Any Haskell programmer uses half a dozen non-leaking abstractions before breakfast. Even the examples in the post itself don't hold up - using UDP instead of TCP doesn't actually mean your program will work any better when someone unplugs the network cable.
  - kqr 6y ago
    I agree. Dijkstra et al. always pushed (as early as in the 1960s) that resources used at abstraction level n should be effectively invisible at level n + 1. Anything else is an improperly designed abstraction. Of course there's always the thermodynamic argument that "any subprogram has the permanent and externally-detectable side effect of increasing entropy in the universe by converting electricity to heat" but that is to me a bit of a Turing tar-pit of an argument.
    - lmm 6y ago
      Even that's just an effect that you can represent in your language. The evaluation of 2 + 2 is not exactly the same thing as the value 4, but you could track the overhead of evaluation (e.g. in the type) and have your language polymorphically propagate that information.
  - JoeSmithson 6y ago
    The reason UDP is less leaky is not because it meets any guarantee better, but because it guarantees less
    - TomMarius 6y ago
      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.
      - fanf2 6y ago
- cannabis_sam 6y ago
  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“)
  - netcan 6y ago
    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.
    - cannabis_sam 6y ago
      > 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.
napo 6y ago
"If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens." I think the author is stuck in 2010.
- mavelikara 6y ago
  The essay was written in early 2015, around the same time NodeJS foundation was set up.
mhink 6y ago
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 https://www.stilldrinking.org/programming-sucks
- mormegil 6y ago
  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 <http://scholar.harvard.edu/files/mickens/files/thenightwatch.pdf> http://scholar.harvard.edu/files/mickens/files/thenightwatch.... All should be available at https://mickens.seas.harvard.edu/wisdom-james-mickens https://mickens.seas.harvard.edu/wisdom-james-mickens And they are not only very funny, but also insightful.
- hnick 6y ago
  > All programmers are forcing their brains to do things brains were never meant to do in a situation they can never make better, ten to fifteen hours a day, five to seven days a week, and every one of them is slowly going mad. Yeah, this resonates. I've got in trouble with my wife more than once for being in "code mode" when I'm working and something happens, it seems to turn off my basic empathy for some reason. Programming changes people.
nordsieck 6y ago
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/ https://www.infoq.com/presentations/Simple-Made-Easy/
- Cthulhu_ 6y ago
  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.
  - twic 6y ago
    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.
    - mac01021 6y ago
      If you find 90% of his statements to be obvious, maybe all that means is that you're a deep and powerful thinker too?
    - kaio 6y ago
      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.
    - chubot 6y ago
      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 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 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).
zem 6y ago
"slumming with basic programmers" https://prog21.dadgum.com/21.html https://prog21.dadgum.com/21.html
danielnixon 6y ago
I think about 'Why it is Important that Software Projects Fail' a lot. https://www.berglas.org/Articles/ImportantThatSoftwareFails/ImportantThatSoftwareFails.html https://www.berglas.org/Articles/ImportantThatSoftwareFails/... It's been posted a few times over the years: https://news.ycombinator.com/from?site=berglas.org https://news.ycombinator.com/from?site=berglas.org
deathanatos 6y ago
Arthur C. Clarke's Hazards of Prophecy: The Failure of Imagination: https://fabiusmaximus.com/2017/12/27/arthur-c-clarke-hazards-of-prophecy-lack-of-imagination/ https://fabiusmaximus.com/2017/12/27/arthur-c-clarke-hazards...
- apabepa 6y ago
  I read it from your link. It was an interesting piece about innovation and imagination versus lack of imagination.
lactobacillis 6y ago
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 http://erlang.org/download/armstrong_thesis_2003.pdf
- yawboakye 6y ago
  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 https://www.amazon.com/dp/1543057381
codeDruid 6y ago
As a less experienced web developer, i found "How I write backends"[1] very enlightening and I recommend it to all my peers when we discuss useful resources. 1. https://github.com/fpereiro/backendlore https://github.com/fpereiro/backendlore
- dewey 6y ago
  I just read it but I think it focuses too much on specific tools (Redis, Node,...) and their configurations which might not be the best for most use cases. Especially if it's for a beginner who maybe doesn't have to start out with a load balancer and Redis.
_pmf_ 6y ago
I only think about "Out of the Tar Pit".
- joe_fishfish 6y ago
  Fourteen years later, I still think about this. I have three half-written drafts of blog posts about things this essay has inspired me to do. I think part of the mystique of it is that the authors kind of faded into the background after publishing it. I've never been able to find a follow-up paper from them.
- yboris 6y ago
  It's super great! I loved it. Hope to re-read in a year or two as a reminder. https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf https://github.com/papers-we-love/papers-we-love/blob/master...
- akkartik 6y ago
  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 http://curtclifton.net/papers/MoseleyMarks06a.pdf. I think it's a siren and takes away attention that could be spent on better papers.
  - nordsieck 6y ago
    > 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.
colecut 6y ago
I saw the Inventing on Principal video several years ago and I’m very happy to come across it again. Thanks for sharing!
vrnvu 6y ago
Lately I've been into what I would call "the classics", Knuth, Peter Norvig, Minsky, Dijkstra... I realised most of what nowadays is called modern software/techniques basically consist in re-framing old essays from them. Some of my references: the famous Norvig view on design patterns [1] and also his view of clean code [2]. Knuth on programming [3] also really enlighting. 1. https://norvig.com/design-patterns/design-patterns.pdf https://norvig.com/design-patterns/design-patterns.pdf 2. https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf 3. http://www.paulgraham.com/knuth.html http://www.paulgraham.com/knuth.html
zvrk 6y ago
"Reflections on Trusting Trust" - https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
- jjice 6y ago
  The first time I read this, I had to read it a few times to really understand. Great essay/lecture, but what else would one expect from Ken Thomposon?
sbuttgereit 6y ago
I read Peter Naur's "Programming as Theory Building" and thought it quite good. http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf At the time I found it I was was working where the key challenge was not so much technical as much as ensuring that simple technology, spread across a large breadth of functionality, adhered to a consistent vision of the business domain that was being implemented. The program became an implementation of the mental model I developed of the business domain itself: its purpose, its uses, and its allowances and prohibitions. The Naur paper hit exactly not only on what I had been implementing in code, but on what other developers would have to know in order to maintain that code over time.... and had the kind of knowledge that had been lost over the life of application by the time I came to be involved.... and part of why my project existed.
- hnick 6y ago
  The examples near the start reminded me of another piece shared here before, "How to Build Good Software". Most notably the part near the end, titled "Software Is about Developing Knowledge More than Writing Code". https://www.csc.gov.sg/articles/how-to-build-good-software https://www.csc.gov.sg/articles/how-to-build-good-software It has a few great quotes scattered throughout. "Building good software involves alternating cycles of expanding and reducing complexity." "Software should be treated not as a static product, but as a living manifestation of the development team's collective understanding." "Software projects rarely fail because they are too small; they fail because they get too big."
loopz 6y ago
One of the last links, but probably most significant: Inventing on Principle https://vimeo.com/36579366 https://vimeo.com/36579366

438 points by jchook 6y ago

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-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

holografix 6y ago
I’m going through the conversation with a colleague atm where he believes DRY applies to everything.
- bryanrasmussen 6y ago
  by everything you mean outside of programming also? Or just in programming? I guess I find DRY pretty important for me, as a tool to force me to abstract and to help me understand the system I'm working on.
- yakshaving_jgt 6y ago
  It usually helps to point out that DRY and loosely-coupled are often two sides of the same coin.
- hinkley 6y ago
  When everything is DRY you get the Sahara Desert. Some things should be DAMP every so often, and at regular intervals.
- mrkeen 6y ago
  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 credit. Can't change the credit logic in /card because it will break debit.
  - mgkimsal 6y ago
    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?
    - mrkeen 6y ago
      I definitely would have done that if I had the choice. However the endpoint owner just insisted I just send nulls for the fields I didn't have.
- bcrosby95 6y ago
  The problem isn't DRY. The problem is most programmers' inability to tear down abstractions that aren't correct for your new requirements when they evolve.
- twic 6y ago
  The Sandi Metz talk/post included in the list touches on that: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction 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 ...
  - greymalik 6y ago
    I don’t understand why people interpret that article as recommending you avoid prematurely removing duplication and comparing it to the rule of 3. The point of her essay is that you should resist the sunk cost fallacy and refactor your duplication-removing abstractions when requirements (or your understanding of them) change.
- jchook 6y ago
  Some good resources about DRY: > DRY is about knowledge. Code duplication is not the issue. https://verraes.net/2014/08/dry-is-about-knowledge/ https://verraes.net/2014/08/dry-is-about-knowledge/ > Every piece of knowledge must have a single, unambiguous, authoritative representation within a system https://wiki.c2.com/?DontRepeatYourself https://wiki.c2.com/?DontRepeatYourself
- AnimalMuppet 6y ago
  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...
lmm 6y ago
It's nonsense, written because Joel had never used a language with a decent type system. Any Haskell programmer uses half a dozen non-leaking abstractions before breakfast. Even the examples in the post itself don't hold up - using UDP instead of TCP doesn't actually mean your program will work any better when someone unplugs the network cable.
- kqr 6y ago
  I agree. Dijkstra et al. always pushed (as early as in the 1960s) that resources used at abstraction level n should be effectively invisible at level n + 1. Anything else is an improperly designed abstraction. Of course there's always the thermodynamic argument that "any subprogram has the permanent and externally-detectable side effect of increasing entropy in the universe by converting electricity to heat" but that is to me a bit of a Turing tar-pit of an argument.
  - lmm 6y ago
    Even that's just an effect that you can represent in your language. The evaluation of 2 + 2 is not exactly the same thing as the value 4, but you could track the overhead of evaluation (e.g. in the type) and have your language polymorphically propagate that information.
- JoeSmithson 6y ago
  The reason UDP is less leaky is not because it meets any guarantee better, but because it guarantees less
  - TomMarius 6y ago
    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.
    - fanf2 6y ago
cannabis_sam 6y ago
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“)
- netcan 6y ago
  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.
  - cannabis_sam 6y ago
    > 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.

napo 6y ago

"If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens." I think the author is stuck in 2010.

mavelikara 6y ago
The essay was written in early 2015, around the same time NodeJS foundation was set up.

mhink 6y ago

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 https://www.stilldrinking.org/programming-sucks

mormegil 6y ago
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 <http://scholar.harvard.edu/files/mickens/files/thenightwatch.pdf> http://scholar.harvard.edu/files/mickens/files/thenightwatch.... All should be available at https://mickens.seas.harvard.edu/wisdom-james-mickens https://mickens.seas.harvard.edu/wisdom-james-mickens And they are not only very funny, but also insightful.
hnick 6y ago
> All programmers are forcing their brains to do things brains were never meant to do in a situation they can never make better, ten to fifteen hours a day, five to seven days a week, and every one of them is slowly going mad. Yeah, this resonates. I've got in trouble with my wife more than once for being in "code mode" when I'm working and something happens, it seems to turn off my basic empathy for some reason. Programming changes people.

nordsieck 6y ago

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/ https://www.infoq.com/presentations/Simple-Made-Easy/

Cthulhu_ 6y ago
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.
- twic 6y ago
  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.
  - mac01021 6y ago
    If you find 90% of his statements to be obvious, maybe all that means is that you're a deep and powerful thinker too?
  - kaio 6y ago
    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.
  - chubot 6y ago
    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 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 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).

zem 6y ago

"slumming with basic programmers" https://prog21.dadgum.com/21.html https://prog21.dadgum.com/21.html

danielnixon 6y ago

I think about 'Why it is Important that Software Projects Fail' a lot. https://www.berglas.org/Articles/ImportantThatSoftwareFails/ImportantThatSoftwareFails.html https://www.berglas.org/Articles/ImportantThatSoftwareFails/... It's been posted a few times over the years: https://news.ycombinator.com/from?site=berglas.org https://news.ycombinator.com/from?site=berglas.org

deathanatos 6y ago

Arthur C. Clarke's Hazards of Prophecy: The Failure of Imagination: https://fabiusmaximus.com/2017/12/27/arthur-c-clarke-hazards-of-prophecy-lack-of-imagination/ https://fabiusmaximus.com/2017/12/27/arthur-c-clarke-hazards...

apabepa 6y ago
I read it from your link. It was an interesting piece about innovation and imagination versus lack of imagination.

lactobacillis 6y ago

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 http://erlang.org/download/armstrong_thesis_2003.pdf

yawboakye 6y ago
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 https://www.amazon.com/dp/1543057381

codeDruid 6y ago

As a less experienced web developer, i found "How I write backends"[1] very enlightening and I recommend it to all my peers when we discuss useful resources. 1. https://github.com/fpereiro/backendlore https://github.com/fpereiro/backendlore

dewey 6y ago
I just read it but I think it focuses too much on specific tools (Redis, Node,...) and their configurations which might not be the best for most use cases. Especially if it's for a beginner who maybe doesn't have to start out with a load balancer and Redis.

_pmf_ 6y ago

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

joe_fishfish 6y ago
Fourteen years later, I still think about this. I have three half-written drafts of blog posts about things this essay has inspired me to do. I think part of the mystique of it is that the authors kind of faded into the background after publishing it. I've never been able to find a follow-up paper from them.
yboris 6y ago
It's super great! I loved it. Hope to re-read in a year or two as a reminder. https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf https://github.com/papers-we-love/papers-we-love/blob/master...
akkartik 6y ago
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 http://curtclifton.net/papers/MoseleyMarks06a.pdf. I think it's a siren and takes away attention that could be spent on better papers.
- nordsieck 6y ago
  > 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.

colecut 6y ago

I saw the Inventing on Principal video several years ago and I’m very happy to come across it again. Thanks for sharing!

vrnvu 6y ago

Lately I've been into what I would call "the classics", Knuth, Peter Norvig, Minsky, Dijkstra... I realised most of what nowadays is called modern software/techniques basically consist in re-framing old essays from them. Some of my references: the famous Norvig view on design patterns [1] and also his view of clean code [2]. Knuth on programming [3] also really enlighting. 1. https://norvig.com/design-patterns/design-patterns.pdf https://norvig.com/design-patterns/design-patterns.pdf 2. https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf 3. http://www.paulgraham.com/knuth.html http://www.paulgraham.com/knuth.html

zvrk 6y ago

"Reflections on Trusting Trust" - https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

jjice 6y ago
The first time I read this, I had to read it a few times to really understand. Great essay/lecture, but what else would one expect from Ken Thomposon?

sbuttgereit 6y ago

I read Peter Naur's "Programming as Theory Building" and thought it quite good. http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf At the time I found it I was was working where the key challenge was not so much technical as much as ensuring that simple technology, spread across a large breadth of functionality, adhered to a consistent vision of the business domain that was being implemented. The program became an implementation of the mental model I developed of the business domain itself: its purpose, its uses, and its allowances and prohibitions. The Naur paper hit exactly not only on what I had been implementing in code, but on what other developers would have to know in order to maintain that code over time.... and had the kind of knowledge that had been lost over the life of application by the time I came to be involved.... and part of why my project existed.

hnick 6y ago
The examples near the start reminded me of another piece shared here before, "How to Build Good Software". Most notably the part near the end, titled "Software Is about Developing Knowledge More than Writing Code". https://www.csc.gov.sg/articles/how-to-build-good-software https://www.csc.gov.sg/articles/how-to-build-good-software It has a few great quotes scattered throughout. "Building good software involves alternating cycles of expanding and reducing complexity." "Software should be treated not as a static product, but as a living manifestation of the development team's collective understanding." "Software projects rarely fail because they are too small; they fail because they get too big."

loopz 6y ago

One of the last links, but probably most significant: Inventing on Principle https://vimeo.com/36579366 https://vimeo.com/36579366