Fork me on GitHub
#off-topic
<
2017-04-03
>
qqq06:04:43

@seancorfield : is the racket editor / repl written in racket?

qqq06:04:17

yeah, I have it installed and am playing with it

vloop09:04:41

Who knows how to speed up the react native, it works very slowly:slightly_frowning_face:: https://portal.vloop.io

baptiste-from-paris09:04:23

@vloop I think you should be more precise in your question

baptiste-from-paris09:04:38

and there is a re-natal channel by the way

baptiste-from-paris09:04:46

what is slow in your app ?

vloop09:04:45

Perhaps there are services that will help to code the code

vloop09:04:57

Loading pages on average 7-9 seconds

pesterhazy10:04:27

An astonishing display of incidental complexity

pesterhazy10:04:29

ClojureScript is by comparison simple

vloop10:04:36

Now I will read!

fellshard17:04:32

JS is one gigantic incidental complexity, if you ask me 😛

fellshard17:04:52

Every time they add a new feature, they go about it in the way that will induce the most quirks possible.

fellshard17:04:04

And that reads in the most obfuscated possible manner.

akiroz17:04:19

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.

fellshard18:04:16

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.

dpsutton18:04:05

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.

octopuscabbage18:04:10

@fellshard What about clojure makes it so it doesn’t have this problem?

tbaldridge18:04:48

@octopuscabbage no OOP for one, extensible syntax is another.

noisesmith18:04:46

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.

octopuscabbage18:04:22

@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

tbaldridge18:04:21

Very true, @noisesmith I was thinking of closed-dispatch, inheritance-oriented, OOP

tbaldridge18:04:36

single dispatch at that...

noisesmith18:04:54

@octopuscabbage I agree about OO, but objectively speaking I can adapt very old clojure code to the latest clojure compiler with minor changes

noisesmith18:04:32

and this is because of a lot of working going into the initial design, and vetting features

noisesmith18:04:40

or maybe that's not what you meant by dependency breaks

octopuscabbage18:04:06

the person claimed that api changes happen less frequently in clojure packages than in other languages

octopuscabbage18:04:14

and there’s absolutely no reason to believe that

noisesmith18:04:23

@octopuscabbage my experience validates that

octopuscabbage18:04:24

except that maybe clojure packages tend to have less developers so they get updated less frequently

tbaldridge18:04:46

Less breaking changes, that's for sure

tbaldridge18:04:21

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

noisesmith18:04:26

no, it's because we don't make data types just because (for starters), and we don't introduce interfaces / abstractions just because, either

noisesmith18:04:39

things tend to be pretty plain, so that changes don't need to break things

tbaldridge18:04:04

Exactly, and the overall design of Clojure is: "if it takes a map, allow extra stuff to tag along"

noisesmith18:04:13

yeah - a breaking api change is rare, and the amount of shit stuart got for such a minor change is a sign of that

tbaldridge18:04:55

And now contrast that with LLVM's latest approach: "we will not break the API...except when we do"

tbaldridge18:04:47

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

tbaldridge18:04:16

aka...it'll work until it doesn't

akiroz18:04:17

damn, that's horrible... glad I'm not writing compilers targeting the LLVM.

baptiste-from-paris20:04:22

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&amp;index=1&amp;list=PLhi8pL3xn1OSlyhqnqFmH8il3z_LiYGza ?