5 ms·

Clojure has been the most stable ecosystem I've ever dealt with. Once you get into it it's not uncommon to see libraries that are years old that function perfec

Clojure has been the most stable ecosystem I've ever dealt with. Once you get into it it's not uncommon to see libraries that are years old that function perfectly. I'm not even scared to update clojure to the latest alpha builds because things just always work. There's also this to look at on the subject: https://lkml.org/lkml/2018/8/3/621 https://lkml.org/lkml/2018/8/3/621 Reddit discussion: https://www.reddit.com/r/linux/comments/95b1hf/linus_torvalds_on_regressions/ https://www.reddit.com/r/linux/comments/95b1hf/linus_torvald...

kamaal 8y ago
I imagine in case of a Kernel that should be like a rule beyond any scope of discussion. And may be for any piece of software that is at the bottom layers of any stack. You just can't break backwards compatibility. This was a big mistake Python 3 made.
- iwintermute 8y ago
  That's why it's called Python 3 and not Python 2.x Think about it like totally new language
  - deleted 8y ago
    [deleted]
  - decebalus1 8y ago
    If it's like totally a new language, it should be called TotallyNewython 1.0
    - iwintermute 8y ago
      AlmostTotallyNewthon would be better, correct. Would shift discussion from 'upgrade' to 'migration' without all the usual cries. Other than that it's understandable that some architecture decisions from 1991 haven't aged well.
    - Roboprog 8y ago
      I think “Perl 6” was already taken, so they couldn’t use that :-)
- christophilus 8y ago
  The problem with almost all non-lisps is that you have to add / modify syntax to get a lot of new features (think async/await), whereas in a lisp, most such changes are done via macros and require no breaking changes to the language itself.
- vorg 8y ago
  > You just can't break backwards compatibility. This was a big mistake Python 3 made. At least Python's backers had the guts to release a breaking version 3, unlike some other dynamic languages, specifically Ruby and Apache Groovy. Ruby's backers have tentatively slated 2020 for a (MRI) Ruby 3 release after two more Ruby 2.x versions. As for Groovy, 2 months ago its backers canceled its version 2.6 release which was to backport the planned features of Groovy 3 into a JDK 7 compatible release. Looks like we won't be seeing version 3 of either language anytime soon.
  - dragonwriter 8y ago
    > At least Python's backers had the guts to release a breaking version 3, unlike some other dynamic languages, specifically Ruby and Apache Groovy. The backward-compatibility breaking Ruby release often held up as a parallel to Python 3—Ruby 1.9—was released December 25, 2007, about a year before Python 3. If Python had as much guts as Ruby in this area we'd be seeing a backward-compatibility breaking Python 4 around 2021.
  - pjmlp 8y ago
    Gradle is the only thing holding Groovy alive, beyond maintenance projects. I remember attending JSF Days in 2009 and how we would be all writing Groovy JEE Beans in the near future, show in different ways across a few sessions, and here we are.
    - vorg 8y ago
      ... and Android Studio could be the only thing keeping Gradle alive, beyond 20-liner build scripts. When Google finally releases Fuchsia, it will virtually replace Android's market share within 2-3 yrs. Because Flutter uses Dart for building apps, it'll probably go with Dart for specifying build scripts as well. Although one of the Apache Groovy PMC is probably busy politicking inside Google to get them to use Gradle for Flutter, hopefully that team won't repeat Android's mistake. Otherwise the 3rd-party app market for Fuchsia will be stillborn.
      - pjmlp 8y ago
- natbobc 8y ago
  there was freedom I feel Ruby had that Python didn't which allowed Ruby to successfully go from 1.8 to 1.9; * Ruby had better dependency management. Python's only recently introduced Pipenv which provides a standard approach for managing development and prod dependencies. VirtualEnv's been around for a while but didn't handle scope. * Ruby wasn't used as extensively as Python in stuff like system libs and start-up scripts so system packages weren't constrained in the same way. * Ruby's ecosystem was more focused around web development. Rails in particular was fairly early in adopting new versions of Ruby within about 1 year of the release of Ruby 1.9. Django on the other hand was about 5 years before it had it's first Python 3 compatible release. * "microbenchmarks" generally got better with Ruby releases whereas Python 3 seemed to have gotten worse from what I remember. I don't think microbenchmarks are terribly useful out of the context of an actual application but many people use them as indicators. * subjectively I think the Ruby community was more committed to unit testing which made "fearless upgrades" a little more palatable.
taeric 8y ago
It is amusing, because the very thing that leads to stability is among the things that causes people to claim ecosystems like CL have gone "stagnant." Similarly, TeX shows the halmarks of stability. I can reliably rebuild any document I've ever written. However, that means that the styles I used to use to write documents have to still be supported. Contrast that with HTML, where they constantly give new methods to do something because they changed their mind about how it should be done. Worse, they no longer support the old ways, because they were supposedly "never supported." I think there is some merit to change driving progress. It is just frustrating when so much change is effectively user hostile.
- erlongsb 8y ago
  Yea, that was my impression about the CL ecosystem and clojure made me rethink that. Nowadays it's pretty much the other way around for me - CL serves as an example of how clojure could keep dying and still be a useful tool for years to come
  - jwhitlark 8y ago
    I think part of the point of clojure is a hosted, small core, programmable programming language can't really die, it would just be dormant and could spring back whenever someone needed it. It's weird to me when people claim clojure is dying, yet the ecosystem is evolving rapidly and people are making money with it. It's not a model that's easy to starve, it's too lightweight to collapse under it's own load, and there's no way to kill it, so how is it dying? Mindshare ebbs and flows, but being THE programming language was never clojure's goal.
    - taeric 8y ago
      I think most of the crowd claiming that clojure is dying are those that feel that way by virtue of it being a lisp. And, oddly, most habits in most languages tend for them to pull more and more into them such that they are all looking for an uber language.
      - 8y ago
natbobc 8y ago
I have enormous respect for Alex et al that are maintaining Clojure at Cognitect. From my observations there tends to be few changes in core which is reinforced by a fireside chat with the guys at Cognitect showing the level of Java code churn over time has continually decreased. Everything has benefits and tradeoffs. The benefit of this lack of churn is a stable foundation but I think the tradeoff is that there aren't as many eyes on that code and the depth of familiarity required to improve the code for legibility, maintainability, performance, and security is lost with lack of intimacy. Much of the Java code is undocumented and at times can be hard to follow with unused variables and little if any tests available to validate behaviour. It's delegated much higher up the stack. During the release of 1.9 there were some issues relating to spec, libraries, and build tools in the pre-release versions. So I'm not sure I would say the rule is followed to the letter such that you can consume Alpha releases are safe. It was prerelease candidate so no biggie. I know there were some discussions on the mailing list of a formal security audit of the Clojure but I'm not sure where that went but I'd be interested in seeing the results.
wereHamster 8y ago
> Maybe it worked because the user had taken the bug into account, maybe it worked because the user didn't notice - again, it doesn't matter. It worked for the user. That's also an argument for keeping security holes around. By definition those are bugs and users (albeit malicious ones) depend on them. How dare you fix a security hole and break a perfectly working exploit!
- taeric 8y ago
  Only at an absurd reduction. Few security holes are actually built on features for users. Now, there is a tradeoff between security and convenience. That is also why fraud techniques haven't taken away credit cards as a thing. To that end, sometimes it is better to engineer a detection/mitigation strategy instead of removing the convenience. And life seems to be full of more strawmen then makes sense. So, yes, you can easily find examples for this in either direction.

kamaal 8y ago

I imagine in case of a Kernel that should be like a rule beyond any scope of discussion. And may be for any piece of software that is at the bottom layers of any stack. You just can't break backwards compatibility. This was a big mistake Python 3 made.

iwintermute 8y ago
That's why it's called Python 3 and not Python 2.x Think about it like totally new language
- deleted 8y ago
  [deleted]
- decebalus1 8y ago
  If it's like totally a new language, it should be called TotallyNewython 1.0
  - iwintermute 8y ago
    AlmostTotallyNewthon would be better, correct. Would shift discussion from 'upgrade' to 'migration' without all the usual cries. Other than that it's understandable that some architecture decisions from 1991 haven't aged well.
  - Roboprog 8y ago
    I think “Perl 6” was already taken, so they couldn’t use that :-)
christophilus 8y ago
The problem with almost all non-lisps is that you have to add / modify syntax to get a lot of new features (think async/await), whereas in a lisp, most such changes are done via macros and require no breaking changes to the language itself.
vorg 8y ago
> You just can't break backwards compatibility. This was a big mistake Python 3 made. At least Python's backers had the guts to release a breaking version 3, unlike some other dynamic languages, specifically Ruby and Apache Groovy. Ruby's backers have tentatively slated 2020 for a (MRI) Ruby 3 release after two more Ruby 2.x versions. As for Groovy, 2 months ago its backers canceled its version 2.6 release which was to backport the planned features of Groovy 3 into a JDK 7 compatible release. Looks like we won't be seeing version 3 of either language anytime soon.
- dragonwriter 8y ago
  > At least Python's backers had the guts to release a breaking version 3, unlike some other dynamic languages, specifically Ruby and Apache Groovy. The backward-compatibility breaking Ruby release often held up as a parallel to Python 3—Ruby 1.9—was released December 25, 2007, about a year before Python 3. If Python had as much guts as Ruby in this area we'd be seeing a backward-compatibility breaking Python 4 around 2021.
- pjmlp 8y ago
  Gradle is the only thing holding Groovy alive, beyond maintenance projects. I remember attending JSF Days in 2009 and how we would be all writing Groovy JEE Beans in the near future, show in different ways across a few sessions, and here we are.
  - vorg 8y ago
    ... and Android Studio could be the only thing keeping Gradle alive, beyond 20-liner build scripts. When Google finally releases Fuchsia, it will virtually replace Android's market share within 2-3 yrs. Because Flutter uses Dart for building apps, it'll probably go with Dart for specifying build scripts as well. Although one of the Apache Groovy PMC is probably busy politicking inside Google to get them to use Gradle for Flutter, hopefully that team won't repeat Android's mistake. Otherwise the 3rd-party app market for Fuchsia will be stillborn.
    - pjmlp 8y ago
natbobc 8y ago
there was freedom I feel Ruby had that Python didn't which allowed Ruby to successfully go from 1.8 to 1.9; * Ruby had better dependency management. Python's only recently introduced Pipenv which provides a standard approach for managing development and prod dependencies. VirtualEnv's been around for a while but didn't handle scope. * Ruby wasn't used as extensively as Python in stuff like system libs and start-up scripts so system packages weren't constrained in the same way. * Ruby's ecosystem was more focused around web development. Rails in particular was fairly early in adopting new versions of Ruby within about 1 year of the release of Ruby 1.9. Django on the other hand was about 5 years before it had it's first Python 3 compatible release. * "microbenchmarks" generally got better with Ruby releases whereas Python 3 seemed to have gotten worse from what I remember. I don't think microbenchmarks are terribly useful out of the context of an actual application but many people use them as indicators. * subjectively I think the Ruby community was more committed to unit testing which made "fearless upgrades" a little more palatable.

taeric 8y ago

It is amusing, because the very thing that leads to stability is among the things that causes people to claim ecosystems like CL have gone "stagnant." Similarly, TeX shows the halmarks of stability. I can reliably rebuild any document I've ever written. However, that means that the styles I used to use to write documents have to still be supported. Contrast that with HTML, where they constantly give new methods to do something because they changed their mind about how it should be done. Worse, they no longer support the old ways, because they were supposedly "never supported." I think there is some merit to change driving progress. It is just frustrating when so much change is effectively user hostile.

erlongsb 8y ago
Yea, that was my impression about the CL ecosystem and clojure made me rethink that. Nowadays it's pretty much the other way around for me - CL serves as an example of how clojure could keep dying and still be a useful tool for years to come
- jwhitlark 8y ago
  I think part of the point of clojure is a hosted, small core, programmable programming language can't really die, it would just be dormant and could spring back whenever someone needed it. It's weird to me when people claim clojure is dying, yet the ecosystem is evolving rapidly and people are making money with it. It's not a model that's easy to starve, it's too lightweight to collapse under it's own load, and there's no way to kill it, so how is it dying? Mindshare ebbs and flows, but being THE programming language was never clojure's goal.
  - taeric 8y ago
    I think most of the crowd claiming that clojure is dying are those that feel that way by virtue of it being a lisp. And, oddly, most habits in most languages tend for them to pull more and more into them such that they are all looking for an uber language.
    - 8y ago

natbobc 8y ago

I have enormous respect for Alex et al that are maintaining Clojure at Cognitect. From my observations there tends to be few changes in core which is reinforced by a fireside chat with the guys at Cognitect showing the level of Java code churn over time has continually decreased. Everything has benefits and tradeoffs. The benefit of this lack of churn is a stable foundation but I think the tradeoff is that there aren't as many eyes on that code and the depth of familiarity required to improve the code for legibility, maintainability, performance, and security is lost with lack of intimacy. Much of the Java code is undocumented and at times can be hard to follow with unused variables and little if any tests available to validate behaviour. It's delegated much higher up the stack. During the release of 1.9 there were some issues relating to spec, libraries, and build tools in the pre-release versions. So I'm not sure I would say the rule is followed to the letter such that you can consume Alpha releases are safe. It was prerelease candidate so no biggie. I know there were some discussions on the mailing list of a formal security audit of the Clojure but I'm not sure where that went but I'd be interested in seeing the results.

wereHamster 8y ago

> Maybe it worked because the user had taken the bug into account, maybe it worked because the user didn't notice - again, it doesn't matter. It worked for the user. That's also an argument for keeping security holes around. By definition those are bugs and users (albeit malicious ones) depend on them. How dare you fix a security hole and break a perfectly working exploit!

taeric 8y ago
Only at an absurd reduction. Few security holes are actually built on features for users. Now, there is a tradeoff between security and convenience. That is also why fraud techniques haven't taken away credit cards as a thing. To that end, sometimes it is better to engineer a detection/mitigation strategy instead of removing the convenience. And life seems to be full of more strawmen then makes sense. So, yes, you can easily find examples for this in either direction.