Essays on programming I think about a lot
benkuhn.net
Essays on programming I think about a lot
1–10 of 99 posts
Re: Essays on programming I think about a lot
#2So 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...
Re: Essays on programming I think about a lot
#3So 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.
Re: Essays on programming I think about a lot
#4"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.
Re: Essays on programming I think about a lot
#5Love the list, but I definitely think Programming Sucks [1] should be on any list of programming essays. :)
Re: Essays on programming I think about a lot
#6Sadly 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.
___
Re: Essays on programming I think about a lot
#7"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.
The essay was written in early 2015, around the same time NodeJS foundation was set up.
Re: Essays on programming I think about a lot
#8So 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...
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.
Re: Essays on programming I think about a lot
#9So 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...
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.
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.
Re: Essays on programming I think about a lot
#10Earlier quoted context omitted.
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.
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…
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.