This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (5)
- # beginners (7)
- # boot (1)
- # calva (1)
- # cider (7)
- # circleci (2)
- # clara (5)
- # clj-kondo (1)
- # clojure (19)
- # clojure-chicago (1)
- # clojure-dev (3)
- # clojure-europe (1)
- # clojure-spec (1)
- # clojure-sweden (5)
- # clojure-uk (25)
- # clojurescript (4)
- # crux (10)
- # cursive (2)
- # data-science (1)
- # datomic (44)
- # graphql (9)
- # hoplon (2)
- # klipse (2)
- # luminus (1)
- # nrepl (1)
- # off-topic (38)
- # planck (1)
- # precept (1)
- # quil (1)
- # re-frame (3)
- # reagent (5)
- # shadow-cljs (12)
- # spacemacs (13)
- # sql (2)
I think she is totally on target in most of this. asyncio is particularly egregious in how horrible it is - and a large part of the chaos in that can be directly laid at the feet of GVR (it's too bad he didn't resign twenty years ago). Word to the wise - anyone wanting to do any sort of async work in Python (3 only sadly) - use Trio and friends. Trust me, you will be spared an enormous amount of pain.
One thing I like about Clojure is that external libraries, even if not maintained for a long time, still work - and that’s not been my experience with other languages. But at the same time stdlib provides some amount of curation / trustworthiness.
I wonder if it would be possible to have a “code critic” position, a member of a core team that declares libraries as recommended 😄
Oh man, the mental pain that Python 3 transition put me in. I eventually abandoned the language entirely... still feel sad as the Python community was very warm and welcoming (at least, 10 years ago, no idea about it now).
I just hope Java will not end up that way. It seems some libraries don't want/need to go past Java 8, and with extended support form other vendors they also don't really need to. At some point this will probably break things (instead of just warnings about unsafe/reflection).
I think the power dynamics are inverted though. In Java, it will be end-users that will put the pressure on lib maintainers to add compatibility for Java 11. And most of the times, it seems like it’s a relative minor burden (I might be wrong here). In contrast, the core Python team was the one that put the pressure on everyone else, which led to a lot of anger, and put the lib maintainers under a lot of stress, and end users were forced to pick camps at some point.
Most cases this will probably be fine, and things like spring etc. will move on. I was a bit surprised the latest 'hippo' was still java 8, https://documentation.bloomreach.com/library/about/system-requirements.html but they depend on an open source stack with some parts have little users then there own. So they should either invest time making those java 11 compliant, or switch them for other ones who already do. Another problem they might have is have a lot of cross module dependencies making it hard to properly support modules.
I mean, the reason the Twisted people are wary of dropping support for Python 2, is that to my knowledge they receive funding and also do work for businesses. Asking businesses (their clients) to shoulder the burden of months of dev time just to do a (seemingly unnecessary) version bump isn’t going to fly.
The python 2/3 debate is so torn for me. At one side, Python 3 is a much better language than 2 but the cost are indeed tremendous. What I would like to add is that this was a transition that wasn’t done on this scale before, the usual cycle for (flawed) programming languages is to be succeeded and die out. I understand their desire to do something about what they (the core maintainers) felt could be the nail in the coffin for Python.
I don’t think there is a way to do this right. Breaking compatibility was a bad plan, but not breaking also. To me it feels like it was picking the lesser of the two evils.
Sad thing that there are no alternative timelines. I wonder where Python would be if they didn’t break compatibility.
The funny thing is that to my understanding, there could be some interoperability between 2/3, if that was an explicit goal. But the rationale was also that the Python interpreter was getting bloated and adding support for both flavors would be too much of a burden. Then a lot of semi-religious arguments broke out and here we are now...
Regardless which camp is right (or most right, for some definition of right), and however much better the new version became, it's not much fun to be in the middle of a low-key war as a language user. Rich's recommendation springs to mind here: maybe they should have changed the name of the language.
They surely should have done it with Angular(js). Especially non tech people now think it's almost the same thing.
I’m not aware of a language that has manoeuvred this successfully, but there certainly are other dramatic version changers (Perl 5 vs ...6?, PHP 5.6 vs 7.*)
It’s a branding decision; personally I’m a fan of new names (not changing the name makes it easier for devs to sell the business on an upgrade though...)
I think the name-change opinion comes precisely from observing these kinds of developments, where the version number becomes fused with the name and stops being an independent semantic unit. Like you say, maybe the effect is the same in the end, but perhaps there would be a difference in terms of turmoil and confusion. Of course, it also means that the new language would have a lot more marketing to do, which perhaps comes for free if you get everyone riled up. If you fork and then mutate the language to the point of incompatibility, yet retain the name, maybe you can at least get 50% of the previous community (and a war).
I know it makes it easier to sell the upgrade, but that's mostly the reason I don't like it. It's hard to make the case that instead of moving from AngularJs to Angular (as an 'upgrade'), we might better move to react.
I guess it’s also a discussion of sentiment, to the ones making Python 3 is is ‘just Python with all mistakes fixed’
Well, you could call Rust "C++ with all mistakes fixed". To disagree, we'd have to have a discussion of nuances and degrees to differentiate why Rust warrants a different name but Angular and Python do not. Or you take the hardline stance that if it's fundamentally incompatible, it's a different language/framework. Lot's of languages and frameworks resemble one another closely, on purpose (since familiarity is a huge selling point for those to whom programming is strictly a job and not a passion), yet do not share names.
Yeah right, it is always easier to say that ‘incompatibility’ means ‘different’ than to try to negotiate where the line is between ‘different but same’ and ‘different’.
That said, it is perfectly possible to write Python that runs on both 2 and 3 and there are very deliberate attempts at making this transition easier. So if I were to compare that to the Rust/C++ example I would place it closer to ‘different but same’. But that certainly ends in a discussion of nuance which I don’t intend to invoke.
Python still not have a good package system Python community stills uses system-wide deps, lock file, versions ranges and not have a single and easy solution
Virtualenv has always been a strong standard when I have worked with python. requirements.txt is disappointing due to the inability to remove transitives.
pipenv is a good solution. It's kind of yarn for python (lockfile, cache downloaded deps...). It's a good solution, but it's not widely used (and it took me a few weeks to find this solution)
Yeah, that is the same issue I have with
pipenv, the hustle that I have to go through building a docker image or something along those line with just
pipenv really annoyed me.