This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-20
Channels
- # 100-days-of-code (2)
- # aleph (53)
- # architecture (2)
- # aws (3)
- # beginners (230)
- # boot (15)
- # calva (3)
- # cider (19)
- # cljs-dev (1)
- # clojure (139)
- # clojure-conj (3)
- # clojure-italy (47)
- # clojure-nl (19)
- # clojure-spec (26)
- # clojure-uk (98)
- # clojurescript (152)
- # clojutre (4)
- # core-async (22)
- # cursive (5)
- # datomic (48)
- # emacs (11)
- # events (1)
- # figwheel-main (219)
- # fulcro (15)
- # instaparse (3)
- # jobs (4)
- # jobs-rus (1)
- # leiningen (30)
- # luminus (8)
- # off-topic (67)
- # onyx (5)
- # pedestal (16)
- # re-frame (1)
- # reagent (4)
- # reitit (31)
- # ring (8)
- # ring-swagger (3)
- # shadow-cljs (115)
- # specter (4)
- # videos (1)
- # vim (20)
- # yada (15)
A couple of days ago I was talking about the relative lack of applicability of Java vs Clojure arguments to Javascript, so here’s an argument for Clojure - doing any kind of data structure work with JS is so so horribly verbose and clunky.
I find myself needing things like mapcat, or a tree walk etc all the time. Not to mention the horrible clunkiness that is the JS iterators. And the fact that the new Map and Set data structures have so little functionality.
what are some other immutable FP-languages with dynamic typing besides Clojure, Erlang and Elixir?
lacks dynamic typing @lady3janepl
Maybe a better question isn't whether you are allowed to mutate data in Scheme, but what does the Scheme developer community stress vs. discourage, and do the most commonly used libraries stress immutability, or typically use mutability? I don't know the answer to that, but just because Scheme allows mutability isn't enough to say. Clojure allows mutability, too, especially using Java interop.
I can't remember set!
ever being used in the little schemer. anyone having read SICP that can chip in whether that is fully immutable as well?
SICP teaches you about set!
and then teaches why mutating state would be bad and then encourages to avoid it whenever possible.
Sadly, scheme doesn’t come with persistent data structures by default (I think Racket does have them) nor atomic containers like we do in clojure.
Just for aesthetics, deprecate the things few people use (maybe I am wrong, but defstruct
?) or that just don't feel like they belong in core (`xml-seq`?)
@U11BV7MTK Is this an official question? Or just a hypothetical one?
Just by calling it 2.0, we're achieving PR buzzword compliance. Maybe that's the killer feature for 2.0?
i think i would want core.match moved into clojure itself and the method too large problem tackled
highly unlikely that core.match would ever be integrated. and afaict the method too large problem can and should be solved without breaking any apis
Until clojure 1.11? And you determine that's your minimum. No different than using transducers or reducers, etc.
It's only breaking if it changes an existing API.
Sooooo… maybe contains?
finally does what everyone thinks it does when they first see the word used?
It's hard to think about improvements that would be valuable enough to break existing APIs.
Someone mentioned to me that transducers would have been more dominant in Clojure in place of lazy sequences if they'd have been thought of earlier.
Tbh, you could do a clojure "2" by coming up with a new ns macro and eradicating the old one from documentation. But such a thing wouldn't be done lightly.
we would never eradicate ns. but we might make an ns2 :)
when you don’t want lazy seq’s or you want to preserve a data type - like keep a vector from a source vector after transformations, transducers are awesome
My default mapping idiom has become (into [] (map (fn [x] ...)) xs)
It’s so easy to add transducers to the stack
I was just about to say. If seq operations preserved their type... Though that's not even a 2.0 thing... Maybe a whole different language.
Stuff like this is one area where Specter shines. Most (all?) of what is being discussed in this context is already there in Specter and likely done much better than hand rolled one offs.
I love transducers. They produce a heady feeling of power. If they were a car, I would probably be a danger to society.
I love transducers because there’s something really powerful about how they separate collection consumption from what the transducer actually likes to do
which is really all map
does, call a function, it just does it over some bunch of elements
I most a sort
transducer though. But sort needs to know the complete collection, so I don’t see how that would work. Nevertheless.
For small, defined sets it could possibly work. Like, we know that the output will be positive integers, so buffer until 0 comes along…
you can always try to write the transducer yourself! They’re really not all that difficult
I have no idea of how to write a general sorting transducer though. What if the stream is infinite?
right, a general one simply doesn’t work because sorting doesn’t really fall under the types of problems that transducers solve
You could make a partial one that takes a buffer argument. I.e., it buffers 10 and sorts those before sending them on. Could perhaps be useful in certain edgecases, when you have chunked stuff that should be internally sorted.
hmm, you might be able to do that now without writing a transducer from scratch. partition
the input into your buffer size, and then mapcat
over each partition and sort it
Stuff like this is one area where Specter shines. Most (all?) of what is being discussed in this context is already there in Specter and likely done much better than hand rolled one offs.
Just for aesthetics, deprecate the things few people use (maybe I am wrong, but defstruct
?) or that just don't feel like they belong in core (`xml-seq`?)