This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-03
Channels
- # 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)
@seancorfield : is the racket editor / repl written in racket?
Who knows how to speed up the react native, it works very slowly:slightly_frowning_face:: https://portal.vloop.io
@vloop I think you should be more precise in your question
and there is a re-natal channel by the way
what is slow in your app ?
An astonishing display of incidental complexity
ClojureScript is by comparison simple
Every time they add a new feature, they go about it in the way that will induce the most quirks possible.
Case in point: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator
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.
@fellshard What about clojure makes it so it doesn’t have this problem?
@octopuscabbage no OOP for one, extensible syntax is another.
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
single dispatch at that...
@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
or maybe that's not what you meant by dependency breaks
the person claimed that api changes happen less frequently in clojure packages than in other languages
and there’s absolutely no reason to believe that
@octopuscabbage my experience validates that
except that maybe clojure packages tend to have less developers so they get updated less frequently
Less breaking changes, that's for sure
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
things tend to be pretty plain, so that changes don't need to break things
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"
aka...it'll work until it doesn't
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 ?