5 ms·

Very good slide here: https://github.com/matthiasn/talk-transcripts/raw/master/Hickey_Rich/EffectivePrograms/00.27.19.png https://github.com/matthiasn/talk-tra

Very good slide here: https://github.com/matthiasn/talk-transcripts/raw/master/Hickey_Rich/EffectivePrograms/00.27.19.png https://github.com/matthiasn/talk-transcripts/raw/master/Hic... Caption: "The problems of programming" And you can call them problems, and I'm going to call them the problems of programming. And I've ordered them here -- I hope you can read that. Can you read it? Yeah, ok. I've ordered them here in terms of severity. And severity manifests itself in a couple of ways. Most important, cost. What's the cost of getting this wrong? At the very top you have the domain complexity, about which you could do nothing. This is just the world. It's as complex as it is. But the very next level is the where we start programming, right? We look at the world and say, "I've got an idea about how this is and how it's supposed to be and how, you know, my program can be effective about addressing it". And the problem is, if you don't have a good idea about how the world is, or you can't map that well to a solution, everything downstream from that is going to fail. There's no surviving this misconception problem. And the cost of dealing with misconceptions is incredibly high. I'd suggest to consider the diagram cited above, it is a good representation of where the real difficulties lie in programming.

wedowhatwedo 9y ago
But we still have teams spend endless amounts of time debating on which flavor of Javascript, where the braces go, or which NPM module is the most effective.
- wellpast 9y ago
  ...and which programming language to use. One of the things Rich says more than once in this talk is that he doubts even that programming languages (including his own) are the most important aspect of doing our programming work well. And yet we talk about PLs as if they are everything. There's a term for this: bike-shedding[1]. [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
  - mikebenfield 9y ago
    Yeah I heard him say that and to be perfectly honest I don't know if I believe he truly thinks that. This is a man who devoted years of his life to create a new programming language because he found it difficult and frustrating to use existing languages. In this talk and many others he talks about how he believes Clojure's features (like dynamic typing and dynamic dispatch and the whole keyword system and others) are really key to writing good software and how many other features (like static typing) are irrelevant or harmful... and now here he's saying programming languages don't matter much?
    - Scarbutt 9y ago
      He mentioned he liked Common Lisp but they didn't let him use it in production, so he created a Lisp that runs on an industrial runtime.
      - mikebenfield 9y ago
        Yeah, I understand that. But if he really didn't care much about programming languages, why wouldn't he just use C++, which he was allowed to use in production?
        Scarbutt 9y ago
        He talks about that quite a few times in the video.
        mikebenfield 9y ago
        Yes, and the things he says about it indicate he does think programming languages are important.
        grzm 9y ago
        I think there may be a bit of people talking past each other here. I think one can reasonably say that which language one uses isn't as important as which features that language has. Also, there comment you originally responded says "that programming languages (including his own) are the most important aspect of doing our programming work well." That doesn't mean that the language or its features aren't important. They're saying that it's not the most important thing. The hierarchy Rich refers to[0] puts domain complexity and misconception as 10× more important than anything that's language specific. I believe this is the basis of the quote I pulled. I think this is compatible with thinking that language features are important, but domain complexity and misconception are more important issues when tackling a problem with code. [0]: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/EffectivePrograms/00.27.19.png https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
hellofunk 9y ago
I have some doubts about this one, despite my love and ongoing professional work with Clojure. For overall productivity, I find the issue of typos more significant than this slide leads us to believe, especially in a language like Clojure where the compiler does not catch nearly 90% of my typos. It's very easy to have a nil running through your program in Clojure because you either mistyped a keyword or you just picked the wrong one when pulling something out of a map, for example. But that is just one example, I find that I spend a fair amount of my work day tracking down silly typos at run time, which frankly disappoints me tremendously. I really like Clojure but tackling this problem has been non-trivial.
- raiflip 9y ago
  I think the mistake he's making is in that while his hierarchy is correct in that one bug from a category further up is far worse than any bug in a category below it, if you have many more bugs from lower categories they can start to become problems on the scale of a few bugs higher up the chain. Constantly dealing with typos is a great example because one or two would not be a big deal, but they can add up to significant mental effort and time loss.
- kimi 9y ago
  I agree: one of the things I do appreciate in Java is that the compiler does catch those silly things and I don't really have to think about them any more. As a side effect, refactoring is very safe and you can depend on it. Clojure - that I like quite a bit - does not help me much along these lines; and this is an annoyance.
- abc_lisper 9y ago
  I agree with this sentiment, but I find that doing small checkins to git is helpful, with a good git ui.
- lispm 9y ago
  Common Lisp OTOH uses defined arglists with keyword parameters, where the compiler can check mistyped/wrong keywords.
- raspasov 9y ago

wedowhatwedo 9y ago

But we still have teams spend endless amounts of time debating on which flavor of Javascript, where the braces go, or which NPM module is the most effective.

wellpast 9y ago
...and which programming language to use. One of the things Rich says more than once in this talk is that he doubts even that programming languages (including his own) are the most important aspect of doing our programming work well. And yet we talk about PLs as if they are everything. There's a term for this: bike-shedding[1]. [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
- mikebenfield 9y ago
  Yeah I heard him say that and to be perfectly honest I don't know if I believe he truly thinks that. This is a man who devoted years of his life to create a new programming language because he found it difficult and frustrating to use existing languages. In this talk and many others he talks about how he believes Clojure's features (like dynamic typing and dynamic dispatch and the whole keyword system and others) are really key to writing good software and how many other features (like static typing) are irrelevant or harmful... and now here he's saying programming languages don't matter much?
  - Scarbutt 9y ago
    He mentioned he liked Common Lisp but they didn't let him use it in production, so he created a Lisp that runs on an industrial runtime.
    - mikebenfield 9y ago
      Yeah, I understand that. But if he really didn't care much about programming languages, why wouldn't he just use C++, which he was allowed to use in production?
      - Scarbutt 9y ago
        He talks about that quite a few times in the video.
        mikebenfield 9y ago
        Yes, and the things he says about it indicate he does think programming languages are important.
        grzm 9y ago
        I think there may be a bit of people talking past each other here. I think one can reasonably say that which language one uses isn't as important as which features that language has. Also, there comment you originally responded says "that programming languages (including his own) are the most important aspect of doing our programming work well." That doesn't mean that the language or its features aren't important. They're saying that it's not the most important thing. The hierarchy Rich refers to[0] puts domain complexity and misconception as 10× more important than anything that's language specific. I believe this is the basis of the quote I pulled. I think this is compatible with thinking that language features are important, but domain complexity and misconception are more important issues when tackling a problem with code. [0]: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/EffectivePrograms/00.27.19.png https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

hellofunk 9y ago

I have some doubts about this one, despite my love and ongoing professional work with Clojure. For overall productivity, I find the issue of typos more significant than this slide leads us to believe, especially in a language like Clojure where the compiler does not catch nearly 90% of my typos. It's very easy to have a nil running through your program in Clojure because you either mistyped a keyword or you just picked the wrong one when pulling something out of a map, for example. But that is just one example, I find that I spend a fair amount of my work day tracking down silly typos at run time, which frankly disappoints me tremendously. I really like Clojure but tackling this problem has been non-trivial.

raiflip 9y ago
I think the mistake he's making is in that while his hierarchy is correct in that one bug from a category further up is far worse than any bug in a category below it, if you have many more bugs from lower categories they can start to become problems on the scale of a few bugs higher up the chain. Constantly dealing with typos is a great example because one or two would not be a big deal, but they can add up to significant mental effort and time loss.
kimi 9y ago
I agree: one of the things I do appreciate in Java is that the compiler does catch those silly things and I don't really have to think about them any more. As a side effect, refactoring is very safe and you can depend on it. Clojure - that I like quite a bit - does not help me much along these lines; and this is an annoyance.
abc_lisper 9y ago
I agree with this sentiment, but I find that doing small checkins to git is helpful, with a good git ui.
lispm 9y ago
Common Lisp OTOH uses defined arglists with keyword parameters, where the compiler can check mistyped/wrong keywords.
raspasov 9y ago