Fork me on GitHub
#off-topic
<
2018-09-20
>
john01:09:38

Crossposting here since I usually hang out in #off-topic

👍 4
orestis08:09:23

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.

orestis08:09:37

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.

borkdude15:09:52

what are some other immutable FP-languages with dynamic typing besides Clojure, Erlang and Elixir?

borkdude15:09:20

(by immutable I don’t count JS, Python and Common Lisp)

dpsutton15:09:44

lacks dynamic typing @lady3janepl

3Jane15:09:38

ah right :woman-facepalming:

mpenet15:09:36

All the other beam languages:

mpenet15:09:58

So luaerl, clojerl, lfe, alpaca etc

mpenet15:09:48

Well alpaca is a ML like lang, so maybe not this one

borkdude15:09:22

does Scheme emphasize immutable data?

akond17:09:33

no, you can do (define a 1), and then (set! a 2)

andy.fingerhut17:09:14

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.

uosl18:09:03

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?

pablore02:09:27

SICP teaches you about set! and then teaches why mutating state would be bad and then encourages to avoid it whenever possible.

pablore02:09:26

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.

dpsutton18:09:17

what breaking change would you want in Clojure 2.0?

polymeris22:09:29

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`?)

polymeris22:09:34

oh, and unify the names of cljs and clj namespaces

dpsutton22:09:28

yeah that gets me sometimes. some are and some aren't

pablore02:09:37

Take spec out of alpha. And better stack traces/error messages!

sveri04:09:02

@U11BV7MTK Is this an official question? Or just a hypothetical one?

dpsutton04:09:48

Officially be me. But I hold no official position anywhere

henrik18:09:08

Just by calling it 2.0, we're achieving PR buzzword compliance. Maybe that's the killer feature for 2.0?

dominicm18:09:43

If we go for 5.0, maybe we can bandwagon with html5? Is it too late?

dpsutton18:09:54

i think i would want core.match moved into clojure itself and the method too large problem tackled

alexmiller19:09:00

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

dpsutton18:09:06

i think i would like it if it were idiomatic to use match more

dominicm18:09:12

Neither of those are breaking are they?

dpsutton18:09:15

reading racket code with match everywhere are super nice

dpsutton18:09:28

well if it were then code that used it would not work in clojure 1.9

dpsutton18:09:53

(:require [clojure.match]) would bomb on every existant clojure

dominicm18:09:53

Until clojure 1.11? And you determine that's your minimum. No different than using transducers or reducers, etc.

dpsutton18:09:56

that's a good point

henrik18:09:40

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?

henrik18:09:16

It's hard to think about improvements that would be valuable enough to break existing APIs.

dominicm19:09:45

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.

mikerod19:09:05

I use transducers all the time though

👍 4
dominicm19:09:16

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.

alexmiller19:09:20

we would never eradicate ns. but we might make an ns2 :)

dominicm20:09:48

This is what I was trying to articulate, badly 😊

mikerod19:09:34

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

dominicm19:09:50

I'm agreeing. Transducers are the primitive.

mikerod19:09:58

I can probably see your point though

mikerod19:09:08

they are overlooked quite a bit perhaps since added later in the game

donaldball19:09:25

My default mapping idiom has become (into [] (map (fn [x] ...)) xs)

donaldball19:09:45

It’s so easy to add transducers to the stack

john19:09:58

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.

jsa-aerial21:09:14

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.

👍 8
donaldball19:09:11

And I try to avoid lazy seqs nowadays mostly

4
4
henrik19:09:18

I love transducers. They produce a heady feeling of power. If they were a car, I would probably be a danger to society.

dpsutton19:09:23

i like your enthusiasm but don't have a clue what that means 🙂

scriptor19:09:40

I love transducers because there’s something really powerful about how they separate collection consumption from what the transducer actually likes to do

scriptor19:09:55

like, the map transducer ultimately boils down to just a function call

scriptor19:09:19

which is really all map does, call a function, it just does it over some bunch of elements

henrik19:09:35

I most a sort transducer though. But sort needs to know the complete collection, so I don’t see how that would work. Nevertheless.

henrik19:09:43

For small, defined sets it could possibly work. Like, we know that the output will be positive integers, so buffer until 0 comes along…

scriptor19:09:50

you can always try to write the transducer yourself! They’re really not all that difficult

henrik19:09:25

I have no idea of how to write a general sorting transducer though. What if the stream is infinite?

henrik19:09:52

How would it behave attached to a core.async channel?

scriptor19:09:24

right, a general one simply doesn’t work because sorting doesn’t really fall under the types of problems that transducers solve

henrik19:09:42

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.

scriptor19:09:02

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

henrik19:09:20

Yeah, true!

dominicm20:09:53

Xforms provides a sort

jsa-aerial21:09:14

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.

👍 8
polymeris22:09:29

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`?)