3 ms·

I keep going back to the Simple Made Easy talk by Rich Hickey, creator of Clojure. Easy vs Hard as in: - Easy to learn - Familiar looking - I know most of it a

by didibus 10y ago

I keep going back to the Simple Made Easy talk by Rich Hickey, creator of Clojure. Easy vs Hard as in: - Easy to learn - Familiar looking - I know most of it already vs - Hard to learn - Nothing works as I'm used too - It's all new to me Simple vs Complex: - Its parts are self-contained - The parts don't depend on each other - Quick to get something done once you understand it vs - Can't separate the parts from the whole - Each part depends on other parts - Slow to get something done even if you understand it Most programmers and businesses value Easy vs Hard, because they think about themselves, not delivery of great quality software. If you focused on delivery of great quality software, you'd conclude hopefully that easy vs hard doesn't matter as much as simple vs complex. Having said that, I think Go is easy, and for the most part, it is also pretty simple. While Rust I'd say is hard, but also very simple. Its simple in Rust to make correct software, but not easy. C is easy, but complex. C++ is kinda hard, and also complex. So both Go and Rust are great improvements. Go chose to still be easy, at the detriment of how far it could innovate, but it still innovates. This approach is pretty smart, because what will happen probably is that a lot of people will move to Go, as it is not a very hard change from what they know, and then they will move to Go + 1, and then Go + 2, and then Go + 2, and eventually they'll end up at Rust, or something similar. Doing it that way is easier.

brandonbloom 10y ago
You're missing a key element from Rich's talk: Complexity occurs when things are complected. That is, when two separate concerns are tied together. There's lots of this in Rust, especially in the form of premature specialization. If you define a struct or a method in Rust, you might be forced to make some decisions about lifetime, static vs dynamic dispatch, memory representation, mutability, etc. These things are tied together deeply in order to create a tractable space in which the type solver may operate. Granted, this may also create a tractable space in which for you to think about these same issues, but that doesn't mean its any less complected/complex.
- kibwen 10y ago
  And yet that's inherent complexity, not accidental complexity. The way that other languages simplify this is by hiding the complexity behind a garbage collector, which Rust's domain can't tolerate.
  - brandonbloom 10y ago
    I don't necessarily disagree. Although in the context of the simple vs easy notion, I suggest you grep this page for "inherent complexity": https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi... He talks about the inherent complexity in resource contention. I will point out one choice quote: "It's making things complex because that's a decision that needs to be made by someone who has better information." Rust addresses this by forcing you to highly parameterize code statically, which is probably the least bad solution we have right now for this sort of stuff in a low-level language.
    - didibus 10y ago
      I know Rust is complected somewhat, that's why I specified that it's simple to write correct programs in Rust. So in that perspective, it's very simple at tackling such a complex problem. You'll find doing so is even more complected in C. I'd agree that to me that's just inherent complexity. Let me explain. Imagine the safest language ever, literally, by design, it prevents all bugs, except for functional ones. Now implementing anything to the extent that there's 0% bugs is inherently complex. It might be so complex that possibly no program ever written even achieves this, in any language. That hypothetical language would not be able to make that complexity disappear, because it's part of the problem space, and not the specific design of the language. In most languages, we avoid this complexity by ignoring it. We allow buggy software. We generally say, as long as the bugs that exist either don't occur in practice, or don't impact users that much, it's good enough. But, let's go back to Rich's talk. Why was he talking about Simple vs Complex? Because complex code leads to bugs. If your language's complexity leads to bug free software, the argument would change. In this case, just work harder to understand the complexity and get it done. You're then guaranteed safety. Rust is by no means this language, but it's the closest we have currently in that space. Because of that goal, it's tackling quite a lot of complexity. Maybe some of it is accidental, and Rust2 could improve on that. Having said this, sometimes it's fine to allow bugs, if it allows productivity. Use Clojure in those cases :p

by didibus 10y ago

brandonbloom 10y ago

You're missing a key element from Rich's talk: Complexity occurs when things are complected. That is, when two separate concerns are tied together. There's lots of this in Rust, especially in the form of premature specialization. If you define a struct or a method in Rust, you might be forced to make some decisions about lifetime, static vs dynamic dispatch, memory representation, mutability, etc. These things are tied together deeply in order to create a tractable space in which the type solver may operate. Granted, this may also create a tractable space in which for you to think about these same issues, but that doesn't mean its any less complected/complex.

kibwen 10y ago
And yet that's inherent complexity, not accidental complexity. The way that other languages simplify this is by hiding the complexity behind a garbage collector, which Rust's domain can't tolerate.
- brandonbloom 10y ago
  I don't necessarily disagree. Although in the context of the simple vs easy notion, I suggest you grep this page for "inherent complexity": https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi... He talks about the inherent complexity in resource contention. I will point out one choice quote: "It's making things complex because that's a decision that needs to be made by someone who has better information." Rust addresses this by forcing you to highly parameterize code statically, which is probably the least bad solution we have right now for this sort of stuff in a low-level language.
  - didibus 10y ago
    I know Rust is complected somewhat, that's why I specified that it's simple to write correct programs in Rust. So in that perspective, it's very simple at tackling such a complex problem. You'll find doing so is even more complected in C. I'd agree that to me that's just inherent complexity. Let me explain. Imagine the safest language ever, literally, by design, it prevents all bugs, except for functional ones. Now implementing anything to the extent that there's 0% bugs is inherently complex. It might be so complex that possibly no program ever written even achieves this, in any language. That hypothetical language would not be able to make that complexity disappear, because it's part of the problem space, and not the specific design of the language. In most languages, we avoid this complexity by ignoring it. We allow buggy software. We generally say, as long as the bugs that exist either don't occur in practice, or don't impact users that much, it's good enough. But, let's go back to Rich's talk. Why was he talking about Simple vs Complex? Because complex code leads to bugs. If your language's complexity leads to bug free software, the argument would change. In this case, just work harder to understand the complexity and get it done. You're then guaranteed safety. Rust is by no means this language, but it's the closest we have currently in that space. Because of that goal, it's tackling quite a lot of complexity. Maybe some of it is accidental, and Rust2 could improve on that. Having said this, sometimes it's fine to allow bugs, if it allows productivity. Use Clojure in those cases :p