9 ms·

> The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other

> The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other languages do. Swift was designed by highly experienced and mature compiler devs and is notorious for making breaking changes. It's just a difference of opinion. I prefer to suffer the occasional upgrade pain in exchange for clean and consistent APIs. And I totally understand those who don't want to deal with that. Although to be fair to them, Swift is much younger than Clojure and the number of breaking changes has steadily declined with each major release. In seven years maybe they will take the backwards compatible approach too.

tombert 8y ago
I'm in the same boat; I work for a company that's been around for awhile, and as a result they've accrued a lot of Java code, a lot of it using deprecated APIs. It's quite frustrating to dig through them, and I would have been happier if Oracle had just phased out a lot of these things from the compiler (though my understanding is that JDK11 is making steps for that).
jwr 8y ago
> Swift was designed by highly experienced and mature compiler devs "Compiler devs". I think that is exactly my point. I should have said "app developers" or "system designers". If you listen to a Rich Hickey talk, you'll see that he is all about Getting Things Done in the real world, and much less about theoretical concepts. Language design is subservient to app developer needs.
- krn 8y ago
  I would put it simply: Clojure was designed by a thinker, who creates when he is away from the keyboard, not in front of it. When one releases and breaks the code in his head first, very few breaking changes are left for the public releases.
  - JBiserkov 8y ago
    Rich Hickey is a great thinker. But he's also an application developer (Datomic). So breaking changes don't just break "other people's code" in the abstract. The pain is real and immediate. By wearing multiple hats he's finding the right balance in a way that language designers who don't code day-to-day simply can't.
    - trevor-e 8y ago
      The deification of Rich Hickey in this thread is amusing. No doubt he's a great developer and language designer, but dogfooding your own language is not exactly novel.
      - ghufran_syed 8y ago
        I think the original statement was implicitly about using the language to build large complex systems in industry, not just about "using" the language which I agree would be kind of silly - who would work on a language they don't use in some way? But I always had the impression that most language designers were academics, e.g Alan Kay, Stroustrup, or professional programmers building what were initially 'hobby' languages (Ruby, python) rather than building something they would use in production in industry. Standards must be low if that's now "deification" :)
        trevor-e 8y ago
        I got the point of the original statement, but again, even building a large and complex system is not unique to Clojure. Go was used internally within Google, Swift within Apple, and Rust within Mozilla, to name a few.
      - jwr 8y ago
        I'm not really sure where you see this "deification" — but as for me, I simply have a lot of respect for him. Mostly because every year or so he comes back with another solution to one of my problems. I don't agree with all his choices (I find some of his naming compromises particularly bad), but I still respect (not "deify") him. Listen to some of his talks and you will see why people respect Rich.
- bad_user 8y ago
  The "getting things done in the real world" theme is overrated and mostly a myth. In static FP languages, the exotic features being added are almost always demanded by users in the industry. As a fun fact for Haskell, developers in academia are more likely to stick with the Haskell 98 language for stability and compatibility. As an example Simon Peyton Jones in a recent chat with Martin Odersky at Scala eXchange was describing how he was approached by developers at GitHub, who are using Haskell for language analysis, saying that they can't wait for GHC 8.6 because they want "quantified constraints", a new and very exotic GHC extension. The "real world" you're talking about wants expressive static type systems where they matter. And the problem with static typing is that the language acquires more features and thus becomes more prone to suffering from backwards incompatible changes. And note that more features doesn't mean more complexity, rather it can mean more tools to cope with complexity, otherwise we'd all be programming in RISC assembly. When it comes to Clojure, sure it's stable and that's a good thing, however it has no static type system (therefore it's apples versus oranges) and by encouraging people to work with raw data (e.g. everything is a list, a vector or a map) in a sense it's actually a step backwards from classic OOP. Rich Hickey was fond of saying that OOP complects data with the operations done on that data. However the need for OOP's encapsulation and polymorphism came from the experience people had with procedural languages like C, and that experience has been forgotten, but the fact remains that some of the biggest software projects around are built with static OOP languages. Correlation doesn't imply causation of course, it might be that such projects are built in static OOP languages because these languages are popular (chicken and egg issue), but at the very least we have empirical evidence that they work, whereas the empirical evidence for what makes LISP great pretty much doesn't exist. Basically as an application grows, so do the data structures, being inevitable and to be able to cope with that: (1) you need good encapsulation and (2) you need the ability to do refactoring cheaply. And I think standard Clojure, like other dynamic or LISP languages before it, fails hard at both. My point being that ... it's really not impossible to keep compatibility in a language that doesn't care much about correctness. And I also believe that the "real world programmer" meme is a symptom of anti-intellectualism.
  - roenxi 8y ago
    Lisps are so flexible you aren't going to be able to make a solid feature-based argument why one is bad. They can do any logical feature expressively and easily if you want it for your own work. If another language does something better then it isn't hard to lift it either. Lisps fall down on writing performant code easily, on ease-of-learning and on community, but you're setting yourself an interesting challenge claiming that there are technical issues. Common Lisp for example is famous for having everything, usually before and usually better than other languages. Static typing isn't a bad idea, but it wasn't implemented because it had interesting logical implications. Languages like, eg, C, used static typing because it is critical to the entire design of C that you know how large an object is in memory, and that like is where I suspect most of its popularity comes from - I assume that to write high-performance code, you need fine-grained to control RAM. For the benefits of a static type system, Clojure is decoupling that implementation detail of size from the interesting logical implications of dynamic typing using the spec library (which has been present since 1.9.0, and is likely to be a pretty strict improvement on static typing for anything except raw performance). I doubt it is the first language to do that, but it is the first I've used. As for encapsulation and refactoring it would be interesting to hear about where you think it falls down. I havn't used the language for anything large-scale, but for personal projects Clojure's approach to encapsulation with protocols is far more likely to capture what-I-actually-wanted than an inheritance system like the classic model in C++. Clojure makes it at least as easy to refactor as any other language. Basically, Clojure cares a huge amount about correctness, that has been a focus for 1.9.0 and now 1.10.0. They just think that static types are a bad way of solving for correctness, because static typing puts a bunch more constraints on an object than are required.

tombert 8y ago

I'm in the same boat; I work for a company that's been around for awhile, and as a result they've accrued a lot of Java code, a lot of it using deprecated APIs. It's quite frustrating to dig through them, and I would have been happier if Oracle had just phased out a lot of these things from the compiler (though my understanding is that JDK11 is making steps for that).

jwr 8y ago

> Swift was designed by highly experienced and mature compiler devs "Compiler devs". I think that is exactly my point. I should have said "app developers" or "system designers". If you listen to a Rich Hickey talk, you'll see that he is all about Getting Things Done in the real world, and much less about theoretical concepts. Language design is subservient to app developer needs.

krn 8y ago
I would put it simply: Clojure was designed by a thinker, who creates when he is away from the keyboard, not in front of it. When one releases and breaks the code in his head first, very few breaking changes are left for the public releases.
- JBiserkov 8y ago
  Rich Hickey is a great thinker. But he's also an application developer (Datomic). So breaking changes don't just break "other people's code" in the abstract. The pain is real and immediate. By wearing multiple hats he's finding the right balance in a way that language designers who don't code day-to-day simply can't.
  - trevor-e 8y ago
    The deification of Rich Hickey in this thread is amusing. No doubt he's a great developer and language designer, but dogfooding your own language is not exactly novel.
    - ghufran_syed 8y ago
      I think the original statement was implicitly about using the language to build large complex systems in industry, not just about "using" the language which I agree would be kind of silly - who would work on a language they don't use in some way? But I always had the impression that most language designers were academics, e.g Alan Kay, Stroustrup, or professional programmers building what were initially 'hobby' languages (Ruby, python) rather than building something they would use in production in industry. Standards must be low if that's now "deification" :)
      - trevor-e 8y ago
        I got the point of the original statement, but again, even building a large and complex system is not unique to Clojure. Go was used internally within Google, Swift within Apple, and Rust within Mozilla, to name a few.
    - jwr 8y ago
      I'm not really sure where you see this "deification" — but as for me, I simply have a lot of respect for him. Mostly because every year or so he comes back with another solution to one of my problems. I don't agree with all his choices (I find some of his naming compromises particularly bad), but I still respect (not "deify") him. Listen to some of his talks and you will see why people respect Rich.
bad_user 8y ago
The "getting things done in the real world" theme is overrated and mostly a myth. In static FP languages, the exotic features being added are almost always demanded by users in the industry. As a fun fact for Haskell, developers in academia are more likely to stick with the Haskell 98 language for stability and compatibility. As an example Simon Peyton Jones in a recent chat with Martin Odersky at Scala eXchange was describing how he was approached by developers at GitHub, who are using Haskell for language analysis, saying that they can't wait for GHC 8.6 because they want "quantified constraints", a new and very exotic GHC extension. The "real world" you're talking about wants expressive static type systems where they matter. And the problem with static typing is that the language acquires more features and thus becomes more prone to suffering from backwards incompatible changes. And note that more features doesn't mean more complexity, rather it can mean more tools to cope with complexity, otherwise we'd all be programming in RISC assembly. When it comes to Clojure, sure it's stable and that's a good thing, however it has no static type system (therefore it's apples versus oranges) and by encouraging people to work with raw data (e.g. everything is a list, a vector or a map) in a sense it's actually a step backwards from classic OOP. Rich Hickey was fond of saying that OOP complects data with the operations done on that data. However the need for OOP's encapsulation and polymorphism came from the experience people had with procedural languages like C, and that experience has been forgotten, but the fact remains that some of the biggest software projects around are built with static OOP languages. Correlation doesn't imply causation of course, it might be that such projects are built in static OOP languages because these languages are popular (chicken and egg issue), but at the very least we have empirical evidence that they work, whereas the empirical evidence for what makes LISP great pretty much doesn't exist. Basically as an application grows, so do the data structures, being inevitable and to be able to cope with that: (1) you need good encapsulation and (2) you need the ability to do refactoring cheaply. And I think standard Clojure, like other dynamic or LISP languages before it, fails hard at both. My point being that ... it's really not impossible to keep compatibility in a language that doesn't care much about correctness. And I also believe that the "real world programmer" meme is a symptom of anti-intellectualism.
- roenxi 8y ago
  Lisps are so flexible you aren't going to be able to make a solid feature-based argument why one is bad. They can do any logical feature expressively and easily if you want it for your own work. If another language does something better then it isn't hard to lift it either. Lisps fall down on writing performant code easily, on ease-of-learning and on community, but you're setting yourself an interesting challenge claiming that there are technical issues. Common Lisp for example is famous for having everything, usually before and usually better than other languages. Static typing isn't a bad idea, but it wasn't implemented because it had interesting logical implications. Languages like, eg, C, used static typing because it is critical to the entire design of C that you know how large an object is in memory, and that like is where I suspect most of its popularity comes from - I assume that to write high-performance code, you need fine-grained to control RAM. For the benefits of a static type system, Clojure is decoupling that implementation detail of size from the interesting logical implications of dynamic typing using the spec library (which has been present since 1.9.0, and is likely to be a pretty strict improvement on static typing for anything except raw performance). I doubt it is the first language to do that, but it is the first I've used. As for encapsulation and refactoring it would be interesting to hear about where you think it falls down. I havn't used the language for anything large-scale, but for personal projects Clojure's approach to encapsulation with protocols is far more likely to capture what-I-actually-wanted than an inheritance system like the classic model in C++. Clojure makes it at least as easy to refactor as any other language. Basically, Clojure cares a huge amount about correctness, that has been a focus for 1.9.0 and now 1.10.0. They just think that static types are a bad way of solving for correctness, because static typing puts a bunch more constraints on an object than are required.