8 ms·

From the perspective of a (fairly large-scale at this point) app developer: I find it great that Clojure places such emphasis on backwards compatibility. In gen

by jwr 8y ago

From the perspective of a (fairly large-scale at this point) app developer: I find it great that Clojure places such emphasis on backwards compatibility. In general, migration to newer Clojure versions is completely painless. 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.

agumonkey 8y ago
I was a bit sad that the changelog was so small. Then I realized that maybe core features were stable and that's it, what was needed wasn't big beside spec and a few other things.
- puredanger 8y ago
  A lot of the year's effort went into things outside core - 2 releases of spec, 2 releases of core.specs, many releases of tools.deps.alpha / clj, tools.gitlibs, new release of REBL, etc. Lots of small fixes and enhancements in core too.
  - agumonkey 8y ago
    blame it on rich, I'm addicted to revolutionary talks about collections that brings speed and expressiveness enhancement for free :p
trevor-e 8y ago
> 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.
porpoisely 8y ago
Clojure's emphasis on backwards compatibility is commendable, but keep in mind Clojure is still a very young language ( only about 10 years old ) so there isn't much backwards compatibility to worry about.
- KingMob 8y ago
  Maybe, but this was true even when Clojure was younger still. The language changes are overwhelmingly additive; Hickey places great stock in not breaking existing code.
  - thaumasiotes 8y ago
    I'm going to bring up again how + used to autopromote ints if your result was out of the primitive int range, and now throws an error instead.
    - KingMob 8y ago
      I didn't say there were no breaking changes, just fewer than most languages.
    - roenxi 8y ago
      If you want to demand perfection, then Clojure isn't going to meet your standards (what would?). The issue here is that, based on the way they (particularly Rich) talk, we can expect they will not do Bloody Stupid things like the old Python 2->3 changeover. Things like big, breaking changes that require architectural changes to keep current, or break all the available tutorials. If the problem can be fixed with a macro or single function (like a change to plus behavior) it is an irritant, not a threat to productivity. That is not a concern.
      - thaumasiotes 8y ago
        You don't think a breaking change to + is any more significant than a breaking change to some other part of the language?
thaumasiotes 8y ago
Didn't Clojure change the + function (hardly obscure!) from automatically updating ints to bigints and therefore never overflowing to throwing an exception if you added ints that were too big? I've got a Clojure book with a spirited defense of why it's good that the simple symbol + just does what you'd expect instead of throwing exceptions based on an implementation detail, and it kind of falls flat now.
- puredanger 8y ago
  That was over 7 years ago, so not particularly recent. And you can get the auto-promoting behavior with +' instead.
- solussd 8y ago
  Yes, very early in Clojure's life and only after testing the change across several popular libraries.
atarian 8y ago
Which languages threw everything out and started again?
- fiddlerwoaroof 8y ago
  Python 3, Perl 6 it looks like Scala 3 is heading that way too.
  - xapata 8y ago
    Python 3 is quite similar to Python 2. They made some breaking changes, but nowhere near like Perl 6. The real stumbling block was str vs unicode, which they didn't realize would be such a pain when making the decision. There's breaking changes and there's writing a new language. It's a spectrum.
    - deleted 8y ago
      [deleted]
    - jwr 8y ago
      My computer has at least three different Python versions installed. I'd say that's a pretty big backwards compatibility problem. There is also Perl 6, and I've recently read about Go 2. Swift changes every couple of months in incompatible ways.
      - xapata 8y ago
        I also have several Pythons installed. For me that's because of incompatibility between community packages I've installed, rather than differences in Python versions. Unfortunately, the various smaller communities can't always stay in sync. Right now there's a conflict between XGBoost and NumPy using MKL on MacOS. That's not a Python problem, exactly, as the issue is conflicting use of OpenMP, written in C, C++, and Fortran.
    - b2gills 8y ago
      It also seems like all of the changes in Python are all changes that Perl5 has done over the years without breaking backwards compatibility. Unfortunately this does mean you often have to opt-in to the new functionality. use v5.24; use feature 'unicode_strings'; use feature 'fc'; use feature 'postderef'; … Note that the `'postderef'` feature is now always enabled so that line is pointless if you use a new enough version of Perl5. The `'unicode_strings'` also isn't always necessary.
lsh 8y ago
S-expressions are perhaps partly responsible as well. They don't suffer the same brittleness as regular programming languages (is there a word for non-s-expression languages like c/python/etc?).
- EuAndreh 8y ago
  M-expressions: https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression
  - lsh 8y ago
    that's a great link, cheers
- snorremd 8y ago
  I think so as well. When you have macros and can add syntax and features to a language at will, then the language and core library does not need to be very big. This probably helps immensely when trying to avoid breaking changes. New macros can very well be prototyped and battle-hardened in external libraries before being added to core.

by jwr 8y ago

agumonkey 8y ago

I was a bit sad that the changelog was so small. Then I realized that maybe core features were stable and that's it, what was needed wasn't big beside spec and a few other things.

puredanger 8y ago
A lot of the year's effort went into things outside core - 2 releases of spec, 2 releases of core.specs, many releases of tools.deps.alpha / clj, tools.gitlibs, new release of REBL, etc. Lots of small fixes and enhancements in core too.
- agumonkey 8y ago
  blame it on rich, I'm addicted to revolutionary talks about collections that brings speed and expressiveness enhancement for free :p

trevor-e 8y ago

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

porpoisely 8y ago

Clojure's emphasis on backwards compatibility is commendable, but keep in mind Clojure is still a very young language ( only about 10 years old ) so there isn't much backwards compatibility to worry about.

KingMob 8y ago
Maybe, but this was true even when Clojure was younger still. The language changes are overwhelmingly additive; Hickey places great stock in not breaking existing code.
- thaumasiotes 8y ago
  I'm going to bring up again how + used to autopromote ints if your result was out of the primitive int range, and now throws an error instead.
  - KingMob 8y ago
    I didn't say there were no breaking changes, just fewer than most languages.
  - roenxi 8y ago
    If you want to demand perfection, then Clojure isn't going to meet your standards (what would?). The issue here is that, based on the way they (particularly Rich) talk, we can expect they will not do Bloody Stupid things like the old Python 2->3 changeover. Things like big, breaking changes that require architectural changes to keep current, or break all the available tutorials. If the problem can be fixed with a macro or single function (like a change to plus behavior) it is an irritant, not a threat to productivity. That is not a concern.
    - thaumasiotes 8y ago
      You don't think a breaking change to + is any more significant than a breaking change to some other part of the language?

thaumasiotes 8y ago

Didn't Clojure change the + function (hardly obscure!) from automatically updating ints to bigints and therefore never overflowing to throwing an exception if you added ints that were too big? I've got a Clojure book with a spirited defense of why it's good that the simple symbol + just does what you'd expect instead of throwing exceptions based on an implementation detail, and it kind of falls flat now.

puredanger 8y ago
That was over 7 years ago, so not particularly recent. And you can get the auto-promoting behavior with +' instead.
solussd 8y ago
Yes, very early in Clojure's life and only after testing the change across several popular libraries.

atarian 8y ago

Which languages threw everything out and started again?

fiddlerwoaroof 8y ago
Python 3, Perl 6 it looks like Scala 3 is heading that way too.
- xapata 8y ago
  Python 3 is quite similar to Python 2. They made some breaking changes, but nowhere near like Perl 6. The real stumbling block was str vs unicode, which they didn't realize would be such a pain when making the decision. There's breaking changes and there's writing a new language. It's a spectrum.
  - deleted 8y ago
    [deleted]
  - jwr 8y ago
    My computer has at least three different Python versions installed. I'd say that's a pretty big backwards compatibility problem. There is also Perl 6, and I've recently read about Go 2. Swift changes every couple of months in incompatible ways.
    - xapata 8y ago
      I also have several Pythons installed. For me that's because of incompatibility between community packages I've installed, rather than differences in Python versions. Unfortunately, the various smaller communities can't always stay in sync. Right now there's a conflict between XGBoost and NumPy using MKL on MacOS. That's not a Python problem, exactly, as the issue is conflicting use of OpenMP, written in C, C++, and Fortran.
  - b2gills 8y ago
    It also seems like all of the changes in Python are all changes that Perl5 has done over the years without breaking backwards compatibility. Unfortunately this does mean you often have to opt-in to the new functionality. use v5.24; use feature 'unicode_strings'; use feature 'fc'; use feature 'postderef'; … Note that the `'postderef'` feature is now always enabled so that line is pointless if you use a new enough version of Perl5. The `'unicode_strings'` also isn't always necessary.

lsh 8y ago

S-expressions are perhaps partly responsible as well. They don't suffer the same brittleness as regular programming languages (is there a word for non-s-expression languages like c/python/etc?).

EuAndreh 8y ago
M-expressions: https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression
- lsh 8y ago
  that's a great link, cheers
snorremd 8y ago
I think so as well. When you have macros and can add syntax and features to a language at will, then the language and core library does not need to be very big. This probably helps immensely when trying to avoid breaking changes. New macros can very well be prototyped and battle-hardened in external libraries before being added to core.