> less clearly humanist in their relation to original thinking or diversity of thought
So what you're frustrated with is that a group of likeminded individuals celebrates their common point of interest and doesn't make room for you to nay-say them?
> So much of Elm community dialogue (in talks, in articles, in the Elm slack which I follow daily) is simply those with more experience initiating those with lesser experience into the "Elm way" of doing things
This could be said of a lot of PL environments. How many Python tutorials stop midstride to browbeat you about how great Python's way of doing things is? Sure feels like a lot to me.
> The inability to even acknowledge the unprecedented labor required simply to parse a JSON response is a perfect example of the cultish mentality emerging in this community.
Right but... what do you want? Acknowledgement? My friend, literally everyone here is agreeing it's harder than JSON.parse. No one argues it is "easier." I can't find a handy example in this thread of anyone saying, "Yeah this is great." There are tools to ease this pain, and there are ways to call external JS code that does this.
At the end of the day though, validating data structures on the wire both structurally and for content is a lot of work. Most Javascript projects don't do it. Hell, most typescript projects just say, 'Well if it breaks it breaks.'.
By pure coincidence this redacted typescript snippet is up on my other screen:
function validateTaskArgs(cdata: any, ldata: any): [boolean, IDomainObject1, IDomainObject2] {
if (cdata === null || ldata === null) {
return [false, null, null]
}
const cdkeys = ["key1", "key2", "key3"]
const ldkeys = ["key1", "key2", "key3", "key4"]
const checkKeys = (keyset: string[], obj: any) => {
const result = keyset.reduce(
(p, c) => { return p && !!obj[c]},
true)
return result
}
return [
checkKeys(cdkeys, cdata) && checkKeys(ldkeys, ldata),
cdata as IDomainObject1,
ldata as IDomainObject2
]
}
This ugly bit of custom logic just to validate a pair of objects in a larger json datastructure, and even that has bugs. This can't deal with a bunch of problems, but it's just too much pain to actually string together the logic in a composable way in typescript, so I accept this kind of drudgery.
But earlier I actually linked a much more sophisticated piece of purescript that's about the same size and not only is easier to read and is self-describing (the code to build the objects IS the spec), but it uses those properties to report console errors. You can see it here:
If you want to make Elm better at JSON, that's the sort of stuff you wanna ask for. And folks will rightly be resistant. Because the programming concepts that make that work (free applicative, in this case) are not things the elm target audience has learned about, yet. Elm's leadership is acutely aware of how big a stack of new concepts they're putting on everyone's plate, and they're cautious about offering more.
Thanks for the code snippets. That actually helps me to understand quite a bit how Elm's JSON parsing situation can be improved within the FP paradigm.
> So what you're frustrated with is that a group of likeminded individuals celebrates their common point of interest and doesn't make room for you to nay-say them?
I'm not frustrated with responses to criticisms I've made. In fact, I haven't made any criticisms (except of course, the ones in the last comment :P). So I don't have any experience of anyone not making room for me. But I have observed some smart people with well-articulated suggestions get shut down. It's not that their suggestions weren't accepted but it was the way that their ideas were received. I haven't actually seen someone who isn't Evan C. contribute something significant that isn't "doing X like Evan would do it." In the entire world of this language, there seems to be 1 architect and a community of implementers. Now, there's nothing wrong with being an implementer. I am an implementer. But it seems easy to see that cultures are healthier when there are a diversity of ideas.
I think that your characterization of the Elm community as a "group of likeminded individuals celebrat(ing) their common point of interest" is actually close to what I'm talking about. It's great when a programming language community is passionate about the language. If people enjoy using that language, it's certainly a good sign. But I wouldn't trust the judgment of a group of people who can't critique what they love and are unwelcoming to those who do.
The counterpoint here is Dan Abramov and the Redux community. Dan is continually pushing people to understand why they are using Redux and not to see it as a solution for everything. That kind of transparency, and the continual acknowledgement by Redux maintainers that there is more than one good way to do something, is the kind of intellectual honesty that I'm using as a standard in my assessment of Elm.
> How many Python tutorials stop midstride to browbeat you about how great Python's way of doing things is?
I couldn't say and it wouldn't change my opinion of Elm.
So what you're frustrated with is that a group of likeminded individuals celebrates their common point of interest and doesn't make room for you to nay-say them?
> So much of Elm community dialogue (in talks, in articles, in the Elm slack which I follow daily) is simply those with more experience initiating those with lesser experience into the "Elm way" of doing things
This could be said of a lot of PL environments. How many Python tutorials stop midstride to browbeat you about how great Python's way of doing things is? Sure feels like a lot to me.
> The inability to even acknowledge the unprecedented labor required simply to parse a JSON response is a perfect example of the cultish mentality emerging in this community.
Right but... what do you want? Acknowledgement? My friend, literally everyone here is agreeing it's harder than JSON.parse. No one argues it is "easier." I can't find a handy example in this thread of anyone saying, "Yeah this is great." There are tools to ease this pain, and there are ways to call external JS code that does this.
At the end of the day though, validating data structures on the wire both structurally and for content is a lot of work. Most Javascript projects don't do it. Hell, most typescript projects just say, 'Well if it breaks it breaks.'.
By pure coincidence this redacted typescript snippet is up on my other screen:
This ugly bit of custom logic just to validate a pair of objects in a larger json datastructure, and even that has bugs. This can't deal with a bunch of problems, but it's just too much pain to actually string together the logic in a composable way in typescript, so I accept this kind of drudgery.But earlier I actually linked a much more sophisticated piece of purescript that's about the same size and not only is easier to read and is self-describing (the code to build the objects IS the spec), but it uses those properties to report console errors. You can see it here:
https://gist.github.com/KirinDave/9af0fc90d005164743198692f3...
If you want to make Elm better at JSON, that's the sort of stuff you wanna ask for. And folks will rightly be resistant. Because the programming concepts that make that work (free applicative, in this case) are not things the elm target audience has learned about, yet. Elm's leadership is acutely aware of how big a stack of new concepts they're putting on everyone's plate, and they're cautious about offering more.