17 ms·

Effective Programs: 10 Years of Clojure

215 points by kimi 9y ago

lunchladydoris 9y ago
I would recommend taking the time to actually watch the talk [0]. It's well worth it. [0] https://www.youtube.com/watch?v=2V1FtfBDsLU https://www.youtube.com/watch?v=2V1FtfBDsLU
- hyeomans 9y ago
  Thanks for this.
flavio81 9y ago
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.
- 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
wellpast 9y ago
Rich comes down hard here on statically typed languages, but before the static typers get too offended, his main attack is on the overuse of ADTs/classes to build information processing systems (i.e., what a majority of us industry programmers are doing; he takes pains to define this arena...see the slides/discussion on what Rich calls "Situated Programs"). So before the static vs dynamic typing debate gets too heated up here, I think we should focus on this point first[1]. For those of you wary of his point here, I think it's worthwhile to go through an exercise, if you have the time to explore this. Write a simple information processing app using two different paradigms: - Write it using a statically typed language and a relational database. - Then write the same app using some NoSQL store and avoid using ADTs (prefer using just maps of facts). Ideally do this in a dynamic language so the ergonomics are better for you. And then ask yourself: Which one of these felt safer? More familiar? Which one of these offered more freedom, choice, and speed? 1. I do think that once you come to terms with the problems of ADTs, you are on your way to not needing all the static type verification, but leave that to later.
- flavio81 9y ago
  >I do think that once you come to terms with the problems of ADTs, you are on your way to not needing all the static type verification, but leave that to later. Excellent thought. Also, as a side note, people that criticize Clojure for its lack of static type enforcement, forget the fact that Rich Hickey had good previous experience in C++, so it's not as if he hadn't tried a statically-typed language before.
  - throwaway7645 9y ago
    C++, Java, and C# if I recall correctly
  - pkd 9y ago
    While that is true, it's not like C++ and Java are the torchbearers of static typing. Much better type systems exist than those of C++ and Java and basing your worldview of static typing just on the experience with these two is shortsighted.
systems 9y ago
I didn't really understand his talk I think he was too abstract It is possible I am missing a lot of the background information to understand it, but still .. the talk wasnt that technical, just too abstract I think he could have shown examples, code examples .. to make a more concrete statement
- wellpast 9y ago
  I agree it'd be nicer if he could dive down deeper into tangibles. However that can take a lot of time in a talk like this. Many of the points he makes could almost warrant a whole entire talk/article on its own. For example, he rails hard on ADTs/classes -- I think he's right here, but this point could be elaborated on at length. Still, I look at Rich as someone who: - has had many years of hard-won practical experience - whose value system is ultra-pragmatic[1] Now that doesn't mean his ideas should be taken without discretion or inspection. Even hardly-mortals like are RH are subject to the flaws of man. But if you're willing to think that he might be speaking some truths, then he gives a lot of threads that we can follow to find out for ourselves. For example, are ADTs really so horrible has he claims? That is something you can start diving into and asking yourself: What if I got rid of all my ADTs and starting programming more with maps and a la carte type validation instead of static types everywhere? That is something we can go put to practice and find out if it is really so liberating as RH is saying. [1] This is important. In tech, a lot of value systems are oriented around other things: what is cool and what is fun and what is intellectually stimulating. Versus what is most pointedly addressing our business needs.
- Cthulhu_ 9y ago
  I'd argue this is the type of talk a 10x developer can make when he tries to talk on "his level"; as he mentions, he had 18 years of experience already when starting with Clojure, so that's the level he started at, and it's ten years later now. He could probably make simpler talks but he doesn't. A lot of the talks he does can be taken and studied (and all the underlying subjects) as a project that could entertain you for weeks.
- hellofunk 9y ago
  > I didn't really understand his talk I think he was too abstract Then you better stay away from another talk at the same conference, by Guy Steele [0] ! [0] https://www.youtube.com/watch?v=dCuZkaaou0Q https://www.youtube.com/watch?v=dCuZkaaou0Q
flavio81 9y ago
>I mean, why was I unhappy as a programmer after 18 years and said, "if I can't switch to something like Common Lisp, I'm going to switch careers". Why am I saying that? I'm saying it because I'm frustrated with a bunch of limitations in what I was using. >So, when I discovered Common Lisp, having used C++, I said that, "I'm pretty sure to the answer to this question is, 'yeah, absolutely'". And can we do that with a lower cognitive load? I also think, "yes, absolutely". And then the question is, "can I make a Lisp I can use instead of Java or C#?". Cuz you just heard my story, and I used Common Lisp a (?) couple of times, every time it got kicked out of production, or just ruled out of production, really not kicked out, it didn't get a chance. So I knew I had to target a runtime that people would accept. Poor Rich Hickey, he wanted to escape C++, Java and C# and rather use Common Lisp, but his employeers wouldn't accept it. Thus he invented Clojure, and now he can't escape Java, because, sadly, Clojure itself and its libraries are very coupled to the Java libraries and the JVM. Clojure makes really easy to invoke Java classes and methods; thus, rather than creating a comprehensive Clojure standard library, the choice was to mostly just use the Java libraries. Thus, migration to another VM (like the CLR runtime) means that a big amount of the Clojure code that runs under the JVM does not work anymore. Clojure is very coupled to the JVM even in it's choice of keywords, for example an "atom" in Lisp has a very different (and traditional, established) meaning than an "atom" in Clojure, which is directly tied to the java.util.concurrent.atomic class. Mind you, i am glad Clojure exists; next time a customer wants a project that should (or needs) to be heavily integrated with existing Java/JVM code, it would be my first choice; in fact, I pitch Clojure as a #1 alternative to Java. But the coupling to the Java and JVM is a problem.
- wellpast 9y ago
  > Clojure itself and its libraries are very coupled to the Java libraries and the JVM. .... Clojure is very coupled to the JVM This is not true. Clojurescript has been a very productive language for me and for many others.
  - flavio81 9y ago
    I never said Clojure wasn't productive, i'm pointing out that it is too tied to the underlying platform. ClojureScript is an excellent replacement for Javascript, however code is not 100% compatible between Clojure and ClojureScript for the reasons cited in the paragraphs above (plus the limitations of Javascript).
jcadam 9y ago
> So fundamentally, what is Clojure about? Can we make programs out of simpler stuff? I mean, that's the problem after 18 years of using, like, C++ and Java, you're exhausted. How many people have been programming for 18 years? Ok. How many for more than 20 years? More than 25? Ok? Fewer than 5? Right (?), so that's really interesting to me. It may be an inditement (?) of Clojure as a beginner's language or may be that Clojure is the language for cranky, tired, old programmers. That's about right :) Yes, I'm tired, cranky, and old.
- pklausler 9y ago
  I've been coding for forty years and I'm not going to go anywhere near a dynamically typed language ever again for any job bigger than a ten-line bash script.
  - jernfrost 9y ago
    Which dynamic language did you use? Like statically typed languages there is a huge variety. I don't group languages whether I like them based on whether they are static or dynamic. I hate JavaScript, PHP and Perl which are all dynamic. While I like Python, Lua and Julia. But I also like static languages such as Swift and Go. I have a certain fascination for Haskell, but I can't be bothered to invest the time to get any good at it. Which kind of suggest to me that Haskell is a dead end. If programming language geeks like me can't invest the time, why would the average developer ever bother. My work language is C++, which I actively hate, but I can stomach it because we work on interesting software.
  - christophilus 9y ago
    I've been programming for close to 20 years. I hate dynamic languages. Except Clojure. If you enjoy programming, and you ignore Clojure, you're missing out on a fun and interesting language.
- yogthos 9y ago
  I was a Java dev for about a decade, and I was seriously considering a career change before I discovered Clojure. Working with Java nearly convinced me that I did not enjoy programming. Moving to Clojure was pure joy for me. I've been using it for over 8 years now, and I still enjoy working with the language immensely.
systems 9y ago
was it really about static typing vs dynamic typing or more about C++ vs Lisp/Clojure
- lucozade 9y ago
  Not sure it was really about either. It's really about what experiences led him to make the decisions he made both in deciding a new language was needed and what attributes the language should have. Clearly the decisions were coloured by his experiences of C++, Java and Common Lisp. But they do appeared much more affected by his views on information structure, flow and evolution.
carljv 9y ago
I love this talk, but it does throw out a lot of complicated ideas somewhat loosely, so I get why reactions and interpretations are all over the place. I think a good companion to understanding this better is Rich's talk on "The Language of the System" (https://www.youtube.com/watch?v=ROor6_NGIWU&t=2810s https://www.youtube.com/watch?v=ROor6_NGIWU&t=2810s). I interpret his overarching thesis as this: Most "situated" programs are in the business of processing information according to complex and changing rules, in cooperation with other programs (i.e., a system). Many languages, though, are overly-concerned with how they represent data internally: classes, algebraic types, etc. This "parochialism", he calls it and "concretion" about how data aggregates should work, make them hard to adapt when the rules, data, or other parts of the system change, and make it hard for their programs to work in systems. At some point your Java class or Haskell ADT has to communicate its data to other programs that have no notion of these things. So you end up w/ a ton of surface area in your code with mappers and marshallers totally unrelated to the content of the data and purpose of the program. The idea behind Clojure is to provide easy access to simple, safe, and relatively universal structures for holding data, and a library of functions to manipulate those structures. Its "big picture" design bits are about providing semantics for multiple "programs" (from threads to services) in a system to operate on data robustly and reasonably (concurrency semantics, time and identity models, pervasive unadorned data, etc.) At some point you're going to be sending this program's data over a wire to another program, and things like "a map of strings and numbers" is pretty straightforward to transport, while a sum type implementing functor with a record data constructor that contains a Maybe SSN is not. It overly couples the underlying data to the language's representation. The plus side of doing this is that the language can check internal consistency for you. The downside is that you're carrying a lot of baggage that you can't take with you over the wire anyway. Communication in systems is also why Rich thinks making "names" for data first class is important. Existing strongly typed languages can sort of accommodate this, but don't really privilege names. So I think a lot of strong typing advocates are upset because they think Rich is saying types don't have value within programs. I don't think that's right. I think he's saying they have very limited value in open systems, which makes their costs often overwhelm their benefits in the individual programs within those systems. In general, I feel like the debate has been about examining Rich's claims in the context of programs (is Maybe String good or bad, etc.), whereas he's really interested in what works in systems. I think that's indicated by his focus on the term "parochialism" which I have not seen a lot of folks address.
nu-world-odor 9y ago
Every time I try to start with Clojure I find the syntax jarring and go back to LISP. Clojure is Not about me though, is it? ;)
zeveb 9y ago
> That was not written in C++, that was around the time I discovered Common Lisp, which was about 8 years into that 15 years. And there was no way the consumer of this would use Common Lisp, so I wrote a Common Lisp program that wrote all the yield management algorithms again out as SQL stored procedures and gave them this database, which was a program. > Eventually I got back to scheduling and again wrote a new kind of scheduling system in Common Lisp, which again they did not want to run in production. And then I rewrote it in C++. Now at this point I was an expert C++ user and really loved C++, for some value of love > [Audience laughter] > that involves no satisfaction at all. > [Audience laughter] > But as we'll see later I love the puzzle of C++. So I had to rewrite it in C++ and it took, you know, four times as long to rewrite it as it took to write it in the first place, it yielded five times as much code and it was no faster. And that's when I knew I was doing it wrong. Seems like a pretty good argument for Common Lisp here. > So, when I discovered Common Lisp, having used C++, I said that, "I'm pretty sure to the answer to this question is, 'yeah, absolutely'". And can we do that with a lower cognitive load? I also think, "yes, absolutely". And then the question is, "can I make a Lisp I can use instead of Java or C#?". Cuz you just heard my story, and I used Common Lisp a (?) couple of times, every time it got kicked out of production, or just ruled out of production, really not kicked out, it didn't get a chance. So I knew I had to target a runtime that people would accept. Pity he hadn't heard of Armed Bear Common Lisp (http://abcl.org/ http://abcl.org/), which runs on the JVM. > And the old Perlis, you know, quip about, you know, "any sufficiently large C or C++ program, you know, has a poorly implemented Common Lisp", is so true. That's actually Philip Greenspun: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule I (unsurprisingly) don't think his list of problems with Lisp are convincing. I don't mind mutable state, since the real world is not functional: real programs are all about side effects. I don't mind that not everything is a list: as he notes, lists aren't the perfect data structure. I think the package system is very clean & understandable.
- Sinidir 9y ago
  >Pity he hadn't heard of Armed Bear Common Lisp (http://abcl.org/ http://abcl.org/), which runs on the JVM. First public release of ABCL seems to be after first release of clojure.
Tehnix 9y ago
I found the discussion on /r/haskell to be much pleasant and a good take on the points Hickey make https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_the_static_typing_world_haskell_in/ https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_... (it's actually a discussion on a piece discussing his talk). I honestly don't find Hickeys arguments to be very valid, and his take on type systems honestly make him sound like he never touched something like Haskell (maybe OCaml) with much more powerful type systems and type inference. He does not sound like someone that invented a language, and more sounds like a blind evangelist for dynamic typing. > static type systems yield much more heavily coupled systems. And that a big part of that time aspect of the final diagram of what problem we're trying to solve, is dominated by coupling when you're trying to do maintenance, right? Flowing type information is a major source of coupling in programs. Having a de-, you know, pattern matching of a structural representation in a hundred places in your program is coupling, right? His arguments about coupling seems silly to me, especially since in FP you usually like generalisations and abstractions that allow you to delay specialising to a specific type until quite late. Take all the different typeclasses that exist in Haskell and things like Monads, Applicatives etc that allow such general abstraction. > Names dominate semantics, a to a, list of a to list of a [talking about `foobar :: [a] -> [a]`], it means nothing, it tells you nothing It tells so much! It tells us that it takes in a list of any element and the only operations it can perform are something that alters the structure of the list (replicate elements, drop elements etc) and no operations on the elements themselves! > How many people like UML? How many people have ever used a UML diagramming tool? Right? It's not fun, right? It's like, "no, you can't connect that to that", "oh no, you have to use that kind of arrow", "no, you can't do this", "no, you can't...", it's terrible. OmniGraffle is much better, draw whatever you want. What are you thinking about? Draw that. What's important? Write that down. That's how it should work, right? I chuckled a bit here, since Hickey just talked about Simon Peyton Jones in the previous slide, I'm assuming he at least Haskell in mind somewhat. If Hickey is seriously comparing Haskell's type system with UML, he needs to go back and take another serious look at Haskell. > Yes, IntelliSense is much helped by static types and performance optimization, which he didn't list, but I think is one of the biggest benefits. We loved that in C++. And maintenance, I think it's not true. I think that they've created problems that they now use types to solve. Oh, I pattern-matched this thing 500 places and I want to add another thing in the middle. Well thank goodness I have types to find those 500 places. But the fact was that thing I added, nobody should have cared about except the new code that consumed it and if I did that a different way I wouldn't have had to change anything except the producer and the consumer, not everybody else who couldn't possibly know about it, right? It's new. Honestly this just comes off incredibly stupid and Hickey quite clearly shows he's never programmed in a language with a type system more powerful than C++ or the likes. One of THE BIGGEST advantages of a powerful system is exactly maintenance. He makes the straw man that you have to pattern match every place you lead a type through in your code base, and that you can't "not care" about certain parts of the constructor, but that is just so incorrect. He was half onto the point of, with the compiler telling you all the places you'd have to refactor thought. And that IntelliSense is the only thing he seems to come up with as valid arguments for types...I think that says more about his understanding of types than anything. I'm gonna leave the rest of the comments up to the discussion I posted in the top, else I would just be rehashing it.

215 points by kimi 9y ago

I would recommend taking the time to actually watch the talk [0]. It's well worth it. [0] https://www.youtube.com/watch?v=2V1FtfBDsLU https://www.youtube.com/watch?v=2V1FtfBDsLU

hyeomans 9y ago
Thanks for this.

flavio81 9y ago

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

wellpast 9y ago

Rich comes down hard here on statically typed languages, but before the static typers get too offended, his main attack is on the overuse of ADTs/classes to build information processing systems (i.e., what a majority of us industry programmers are doing; he takes pains to define this arena...see the slides/discussion on what Rich calls "Situated Programs"). So before the static vs dynamic typing debate gets too heated up here, I think we should focus on this point first[1]. For those of you wary of his point here, I think it's worthwhile to go through an exercise, if you have the time to explore this. Write a simple information processing app using two different paradigms: - Write it using a statically typed language and a relational database. - Then write the same app using some NoSQL store and avoid using ADTs (prefer using just maps of facts). Ideally do this in a dynamic language so the ergonomics are better for you. And then ask yourself: Which one of these felt safer? More familiar? Which one of these offered more freedom, choice, and speed? 1. I do think that once you come to terms with the problems of ADTs, you are on your way to not needing all the static type verification, but leave that to later.

flavio81 9y ago
>I do think that once you come to terms with the problems of ADTs, you are on your way to not needing all the static type verification, but leave that to later. Excellent thought. Also, as a side note, people that criticize Clojure for its lack of static type enforcement, forget the fact that Rich Hickey had good previous experience in C++, so it's not as if he hadn't tried a statically-typed language before.
- throwaway7645 9y ago
  C++, Java, and C# if I recall correctly
- pkd 9y ago
  While that is true, it's not like C++ and Java are the torchbearers of static typing. Much better type systems exist than those of C++ and Java and basing your worldview of static typing just on the experience with these two is shortsighted.

systems 9y ago

I didn't really understand his talk I think he was too abstract It is possible I am missing a lot of the background information to understand it, but still .. the talk wasnt that technical, just too abstract I think he could have shown examples, code examples .. to make a more concrete statement

wellpast 9y ago
I agree it'd be nicer if he could dive down deeper into tangibles. However that can take a lot of time in a talk like this. Many of the points he makes could almost warrant a whole entire talk/article on its own. For example, he rails hard on ADTs/classes -- I think he's right here, but this point could be elaborated on at length. Still, I look at Rich as someone who: - has had many years of hard-won practical experience - whose value system is ultra-pragmatic[1] Now that doesn't mean his ideas should be taken without discretion or inspection. Even hardly-mortals like are RH are subject to the flaws of man. But if you're willing to think that he might be speaking some truths, then he gives a lot of threads that we can follow to find out for ourselves. For example, are ADTs really so horrible has he claims? That is something you can start diving into and asking yourself: What if I got rid of all my ADTs and starting programming more with maps and a la carte type validation instead of static types everywhere? That is something we can go put to practice and find out if it is really so liberating as RH is saying. [1] This is important. In tech, a lot of value systems are oriented around other things: what is cool and what is fun and what is intellectually stimulating. Versus what is most pointedly addressing our business needs.
Cthulhu_ 9y ago
I'd argue this is the type of talk a 10x developer can make when he tries to talk on "his level"; as he mentions, he had 18 years of experience already when starting with Clojure, so that's the level he started at, and it's ten years later now. He could probably make simpler talks but he doesn't. A lot of the talks he does can be taken and studied (and all the underlying subjects) as a project that could entertain you for weeks.
hellofunk 9y ago
> I didn't really understand his talk I think he was too abstract Then you better stay away from another talk at the same conference, by Guy Steele [0] ! [0] https://www.youtube.com/watch?v=dCuZkaaou0Q https://www.youtube.com/watch?v=dCuZkaaou0Q

flavio81 9y ago

>I mean, why was I unhappy as a programmer after 18 years and said, "if I can't switch to something like Common Lisp, I'm going to switch careers". Why am I saying that? I'm saying it because I'm frustrated with a bunch of limitations in what I was using. >So, when I discovered Common Lisp, having used C++, I said that, "I'm pretty sure to the answer to this question is, 'yeah, absolutely'". And can we do that with a lower cognitive load? I also think, "yes, absolutely". And then the question is, "can I make a Lisp I can use instead of Java or C#?". Cuz you just heard my story, and I used Common Lisp a (?) couple of times, every time it got kicked out of production, or just ruled out of production, really not kicked out, it didn't get a chance. So I knew I had to target a runtime that people would accept. Poor Rich Hickey, he wanted to escape C++, Java and C# and rather use Common Lisp, but his employeers wouldn't accept it. Thus he invented Clojure, and now he can't escape Java, because, sadly, Clojure itself and its libraries are very coupled to the Java libraries and the JVM. Clojure makes really easy to invoke Java classes and methods; thus, rather than creating a comprehensive Clojure standard library, the choice was to mostly just use the Java libraries. Thus, migration to another VM (like the CLR runtime) means that a big amount of the Clojure code that runs under the JVM does not work anymore. Clojure is very coupled to the JVM even in it's choice of keywords, for example an "atom" in Lisp has a very different (and traditional, established) meaning than an "atom" in Clojure, which is directly tied to the java.util.concurrent.atomic class. Mind you, i am glad Clojure exists; next time a customer wants a project that should (or needs) to be heavily integrated with existing Java/JVM code, it would be my first choice; in fact, I pitch Clojure as a #1 alternative to Java. But the coupling to the Java and JVM is a problem.

wellpast 9y ago
> Clojure itself and its libraries are very coupled to the Java libraries and the JVM. .... Clojure is very coupled to the JVM This is not true. Clojurescript has been a very productive language for me and for many others.
- flavio81 9y ago
  I never said Clojure wasn't productive, i'm pointing out that it is too tied to the underlying platform. ClojureScript is an excellent replacement for Javascript, however code is not 100% compatible between Clojure and ClojureScript for the reasons cited in the paragraphs above (plus the limitations of Javascript).

jcadam 9y ago

> So fundamentally, what is Clojure about? Can we make programs out of simpler stuff? I mean, that's the problem after 18 years of using, like, C++ and Java, you're exhausted. How many people have been programming for 18 years? Ok. How many for more than 20 years? More than 25? Ok? Fewer than 5? Right (?), so that's really interesting to me. It may be an inditement (?) of Clojure as a beginner's language or may be that Clojure is the language for cranky, tired, old programmers. That's about right :) Yes, I'm tired, cranky, and old.

pklausler 9y ago
I've been coding for forty years and I'm not going to go anywhere near a dynamically typed language ever again for any job bigger than a ten-line bash script.
- jernfrost 9y ago
  Which dynamic language did you use? Like statically typed languages there is a huge variety. I don't group languages whether I like them based on whether they are static or dynamic. I hate JavaScript, PHP and Perl which are all dynamic. While I like Python, Lua and Julia. But I also like static languages such as Swift and Go. I have a certain fascination for Haskell, but I can't be bothered to invest the time to get any good at it. Which kind of suggest to me that Haskell is a dead end. If programming language geeks like me can't invest the time, why would the average developer ever bother. My work language is C++, which I actively hate, but I can stomach it because we work on interesting software.
- christophilus 9y ago
  I've been programming for close to 20 years. I hate dynamic languages. Except Clojure. If you enjoy programming, and you ignore Clojure, you're missing out on a fun and interesting language.
yogthos 9y ago
I was a Java dev for about a decade, and I was seriously considering a career change before I discovered Clojure. Working with Java nearly convinced me that I did not enjoy programming. Moving to Clojure was pure joy for me. I've been using it for over 8 years now, and I still enjoy working with the language immensely.

systems 9y ago

was it really about static typing vs dynamic typing or more about C++ vs Lisp/Clojure

lucozade 9y ago
Not sure it was really about either. It's really about what experiences led him to make the decisions he made both in deciding a new language was needed and what attributes the language should have. Clearly the decisions were coloured by his experiences of C++, Java and Common Lisp. But they do appeared much more affected by his views on information structure, flow and evolution.

carljv 9y ago

I love this talk, but it does throw out a lot of complicated ideas somewhat loosely, so I get why reactions and interpretations are all over the place. I think a good companion to understanding this better is Rich's talk on "The Language of the System" (https://www.youtube.com/watch?v=ROor6_NGIWU&t=2810s https://www.youtube.com/watch?v=ROor6_NGIWU&t=2810s). I interpret his overarching thesis as this: Most "situated" programs are in the business of processing information according to complex and changing rules, in cooperation with other programs (i.e., a system). Many languages, though, are overly-concerned with how they represent data internally: classes, algebraic types, etc. This "parochialism", he calls it and "concretion" about how data aggregates should work, make them hard to adapt when the rules, data, or other parts of the system change, and make it hard for their programs to work in systems. At some point your Java class or Haskell ADT has to communicate its data to other programs that have no notion of these things. So you end up w/ a ton of surface area in your code with mappers and marshallers totally unrelated to the content of the data and purpose of the program. The idea behind Clojure is to provide easy access to simple, safe, and relatively universal structures for holding data, and a library of functions to manipulate those structures. Its "big picture" design bits are about providing semantics for multiple "programs" (from threads to services) in a system to operate on data robustly and reasonably (concurrency semantics, time and identity models, pervasive unadorned data, etc.) At some point you're going to be sending this program's data over a wire to another program, and things like "a map of strings and numbers" is pretty straightforward to transport, while a sum type implementing functor with a record data constructor that contains a Maybe SSN is not. It overly couples the underlying data to the language's representation. The plus side of doing this is that the language can check internal consistency for you. The downside is that you're carrying a lot of baggage that you can't take with you over the wire anyway. Communication in systems is also why Rich thinks making "names" for data first class is important. Existing strongly typed languages can sort of accommodate this, but don't really privilege names. So I think a lot of strong typing advocates are upset because they think Rich is saying types don't have value within programs. I don't think that's right. I think he's saying they have very limited value in open systems, which makes their costs often overwhelm their benefits in the individual programs within those systems. In general, I feel like the debate has been about examining Rich's claims in the context of programs (is Maybe String good or bad, etc.), whereas he's really interested in what works in systems. I think that's indicated by his focus on the term "parochialism" which I have not seen a lot of folks address.

nu-world-odor 9y ago

Every time I try to start with Clojure I find the syntax jarring and go back to LISP. Clojure is Not about me though, is it? ;)

zeveb 9y ago

> That was not written in C++, that was around the time I discovered Common Lisp, which was about 8 years into that 15 years. And there was no way the consumer of this would use Common Lisp, so I wrote a Common Lisp program that wrote all the yield management algorithms again out as SQL stored procedures and gave them this database, which was a program. > Eventually I got back to scheduling and again wrote a new kind of scheduling system in Common Lisp, which again they did not want to run in production. And then I rewrote it in C++. Now at this point I was an expert C++ user and really loved C++, for some value of love > [Audience laughter] > that involves no satisfaction at all. > [Audience laughter] > But as we'll see later I love the puzzle of C++. So I had to rewrite it in C++ and it took, you know, four times as long to rewrite it as it took to write it in the first place, it yielded five times as much code and it was no faster. And that's when I knew I was doing it wrong. Seems like a pretty good argument for Common Lisp here. > So, when I discovered Common Lisp, having used C++, I said that, "I'm pretty sure to the answer to this question is, 'yeah, absolutely'". And can we do that with a lower cognitive load? I also think, "yes, absolutely". And then the question is, "can I make a Lisp I can use instead of Java or C#?". Cuz you just heard my story, and I used Common Lisp a (?) couple of times, every time it got kicked out of production, or just ruled out of production, really not kicked out, it didn't get a chance. So I knew I had to target a runtime that people would accept. Pity he hadn't heard of Armed Bear Common Lisp (http://abcl.org/ http://abcl.org/), which runs on the JVM. > And the old Perlis, you know, quip about, you know, "any sufficiently large C or C++ program, you know, has a poorly implemented Common Lisp", is so true. That's actually Philip Greenspun: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule I (unsurprisingly) don't think his list of problems with Lisp are convincing. I don't mind mutable state, since the real world is not functional: real programs are all about side effects. I don't mind that not everything is a list: as he notes, lists aren't the perfect data structure. I think the package system is very clean & understandable.

Sinidir 9y ago
>Pity he hadn't heard of Armed Bear Common Lisp (http://abcl.org/ http://abcl.org/), which runs on the JVM. First public release of ABCL seems to be after first release of clojure.

Tehnix 9y ago

I found the discussion on /r/haskell to be much pleasant and a good take on the points Hickey make https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_the_static_typing_world_haskell_in/ https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_... (it's actually a discussion on a piece discussing his talk). I honestly don't find Hickeys arguments to be very valid, and his take on type systems honestly make him sound like he never touched something like Haskell (maybe OCaml) with much more powerful type systems and type inference. He does not sound like someone that invented a language, and more sounds like a blind evangelist for dynamic typing. > static type systems yield much more heavily coupled systems. And that a big part of that time aspect of the final diagram of what problem we're trying to solve, is dominated by coupling when you're trying to do maintenance, right? Flowing type information is a major source of coupling in programs. Having a de-, you know, pattern matching of a structural representation in a hundred places in your program is coupling, right? His arguments about coupling seems silly to me, especially since in FP you usually like generalisations and abstractions that allow you to delay specialising to a specific type until quite late. Take all the different typeclasses that exist in Haskell and things like Monads, Applicatives etc that allow such general abstraction. > Names dominate semantics, a to a, list of a to list of a [talking about `foobar :: [a] -> [a]`], it means nothing, it tells you nothing It tells so much! It tells us that it takes in a list of any element and the only operations it can perform are something that alters the structure of the list (replicate elements, drop elements etc) and no operations on the elements themselves! > How many people like UML? How many people have ever used a UML diagramming tool? Right? It's not fun, right? It's like, "no, you can't connect that to that", "oh no, you have to use that kind of arrow", "no, you can't do this", "no, you can't...", it's terrible. OmniGraffle is much better, draw whatever you want. What are you thinking about? Draw that. What's important? Write that down. That's how it should work, right? I chuckled a bit here, since Hickey just talked about Simon Peyton Jones in the previous slide, I'm assuming he at least Haskell in mind somewhat. If Hickey is seriously comparing Haskell's type system with UML, he needs to go back and take another serious look at Haskell. > Yes, IntelliSense is much helped by static types and performance optimization, which he didn't list, but I think is one of the biggest benefits. We loved that in C++. And maintenance, I think it's not true. I think that they've created problems that they now use types to solve. Oh, I pattern-matched this thing 500 places and I want to add another thing in the middle. Well thank goodness I have types to find those 500 places. But the fact was that thing I added, nobody should have cared about except the new code that consumed it and if I did that a different way I wouldn't have had to change anything except the producer and the consumer, not everybody else who couldn't possibly know about it, right? It's new. Honestly this just comes off incredibly stupid and Hickey quite clearly shows he's never programmed in a language with a type system more powerful than C++ or the likes. One of THE BIGGEST advantages of a powerful system is exactly maintenance. He makes the straw man that you have to pattern match every place you lead a type through in your code base, and that you can't "not care" about certain parts of the constructor, but that is just so incorrect. He was half onto the point of, with the compiler telling you all the places you'd have to refactor thought. And that IntelliSense is the only thing he seems to come up with as valid arguments for types...I think that says more about his understanding of types than anything. I'm gonna leave the rest of the comments up to the discussion I posted in the top, else I would just be rehashing it.