This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # arachne (31)
- # aws (9)
- # bangalore-clj (7)
- # beginners (46)
- # boot (18)
- # cider (21)
- # cljs-dev (8)
- # clojure (154)
- # clojure-dusseldorf (5)
- # clojure-filipino (3)
- # clojure-ireland (4)
- # clojure-italy (9)
- # clojure-russia (6)
- # clojure-spec (6)
- # clojure-uk (52)
- # clojureremote (3)
- # clojurescript (173)
- # clojurewest (14)
- # cursive (24)
- # data-science (2)
- # datomic (18)
- # defnpodcast (1)
- # devcards (1)
- # hoplon (4)
- # instaparse (29)
- # jobs (2)
- # juxt (1)
- # leiningen (3)
- # lumo (78)
- # off-topic (46)
- # om (9)
- # onyx (42)
- # pedestal (33)
- # perun (3)
- # re-frame (9)
- # reagent (6)
- # slack-help (5)
- # spacemacs (2)
- # specter (6)
- # unrepl (157)
- # untangled (99)
- # yada (32)
Who knows how to speed up the react native, it works very slowly:slightly_frowning_face:: https://portal.vloop.io
Every time they add a new feature, they go about it in the way that will induce the most quirks possible.
well to be fair.... it's pretty hard to add new stuff without introducing quirks the way it was originally designed.... and they didn't introduce any breaking changes AFAIK.
I'd argue that's still a flaw in the foundation of JS; the fact they had to make a workaround like this to avoid breaking things is a pretty hefty indicator.
does anyone know if there's a way for github to notify you of a release in a dependency? Ie, there's an issue open and the issue is actually fixed by a pull request in a separate project on which the original depends. So it won't be visible until a new release of the dependency.
doesn't that depend on how we define OOP? To my eye clojure is OO, and uses exactly the parts of OO that are worth using.
@tbaldridge https://clojure.org/reference/multimethods i would argue it’s OO. people claim clojure has these magic bullets a lot. someone recently claimed clojure doesn’t have dependency breaks as much as other languages but couldn’t come up with a concrete reason why they believe it
Very true, @noisesmith I was thinking of closed-dispatch, inheritance-oriented, OOP
@octopuscabbage I agree about OO, but objectively speaking I can adapt very old clojure code to the latest clojure compiler with minor changes
and this is because of a lot of working going into the initial design, and vetting features
the person claimed that api changes happen less frequently in clojure packages than in other languages
except that maybe clojure packages tend to have less developers so they get updated less frequently
I remember when Stuart updated clojure.data.json once and broke the API (even though he adjusted the version number to compensate), he got flack for years over that one
no, it's because we don't make data types just because (for starters), and we don't introduce interfaces / abstractions just because, either
Exactly, and the overall design of Clojure is: "if it takes a map, allow extra stuff to tag along"
yeah - a breaking api change is rare, and the amount of shit stuart got for such a minor change is a sign of that
And now contrast that with LLVM's latest approach: "we will not break the API...except when we do"
"The new version of the Developer Policy instead specifies that LLVM will currently load any bitcode produced by version 3.0 or later. When developers decide to drop support for some old bitcode feature, the policy will be updated"
hello @tbaldridge , can you put the link of the paper you’re talking about in your
Logic Programming tuto => https://www.youtube.com/watch?v=7CWEPRKOwgI&index=1&list=PLhi8pL3xn1OSlyhqnqFmH8il3z_LiYGza ?