[wellpast]

> Much of the rhetoric that is currently flying around is a false dichotomy.

The author here is missing the rhetoric. The rhetoric is not about the programming language but about how we should be doing information processing. Except that the author isn't missing that point:

> In Haskell we typically “concrete” data with record types, but we don’t have to.

Great. That is the dichotomy. And it's not a "false" one. This is the question: should we be "concreting"? That's the whole dichotomy/point that is being made. By encoding EDN/Clojure in Haskell the author has gone through a cute intellectual puzzle but hasn't contributed to the crux of the discussion. (Indeed, he's tried to dismiss it as "false".)

The ergonomics that he ends up with are fairly lean (at least in the examples he's shown), though the Clojure expressions are a little leaner. But that's probably because Clojure has actually taken a stance/belief/opinion on the very real question/dichotomy at hand.

[GreaterFool]

It's a little bit more than just a cute intellectual puzzle. One could build an efficient EDN library based on that or very similar type. See Haskell's JSON library:

https://github.com/bos/aeson/blob/master/Data/Aeson/Types/In...

> though the Clojure expressions are a little leaner

Yes they are. The price is complete lack of type safety. And the benefit is an insignificantly small reduction in boilerplate code.

The number of bugs I've seen where somebody would "get" a number that turned out to be a string or string that turned out to be a number...

[dustingetz]

EDN is not JSON. EDN is Extensible. OP has everyone in this thread arguing about a strawman.

[tome]

Then I think you're really going to need to educate us about what EDN really is ...

[escherize]

Educate yourselves. https://github.com/edn-format/edn/blob/master/README.md#tagg...

[tome]

> edn supports extensibility through a simple mechanism. # followed immediately by a symbol starting with an alphabetic character indicates that that symbol is a tag

OK, so it's trivial to add that as a constructor to the Haskell EDN type in the post, and you can even support it in JSON with a dictionary like

    #myapp/Person {:first "Fred" :last "Mertz"}

is represented as

    {"#myapp/Person" : { "first" : "Fred", "last" : "Mertz" } }

What are the remaining objections?

[dustingetz]

EDN is much more like XML than it is JSON.

1) When I read #uri "http://google.com" my app code sees (java.net.URI. "http://google.com"), not Tag "URI" "http://google.com" or whatever. clojure.core/map does not see tagged values, it does not know that the values were ever read from edn.

2) Extension happens in userland library code, you don't need to go modify the hardcoded pattern match in core. (Talking about reifying actual instances that we can code to, not reader tags)

3) Data is just information. Information isn't coupled to code, it's abstract values, totally separate from the concrete implementation. As RH says: "code is data. But data is not code until you define a language around it." Typeclasses are about code.

4) EDN values are cross platform and a platform's EDN reader can reify the value into an idiomatic type for that platform. E.g. a haskell edn reader could reify #error "foo" into Left String; a Java reader a Throwable to be re-thrown later.

5) The whole prism diversion is sophomoric. Once you've read the EDN into concrete values of whatever platform type, you can use whatever platform abstractions you like to manipulate them. Clojure has lenses too: http://funcool.github.io/lentes/latest/#composition

You can watch the EDN talk or read the transcript if you'd like to learn more. This topic is very deep but this thread is not doing it justice.

[marcosdumay]

> This is the question: should we be "concreting"?

At some point your program has to do some specific task over some specific kind of data. Maybe you wanted to ask when should we be concreting?