3 ms·
The two issues I have with Reason for me are: 1) It is not compatible with advanced optimizations in Google Closure's compilation process. 2) I've been burned
by hellofunk 9y ago
The two issues I have with Reason for me are:
1) It is not compatible with advanced optimizations in Google Closure's compilation process.
2) I've been burned by less than ideal implementations of immutable data structures for functional programming in the past, particularly in Elm. I haven't done enough with Immutable-Re to know if it has similar issues, but all functional data structures are not created the same. I'm spoiled by ClojureScript's implementation which has never thrown a stack overflow error for me, unlike Elm. In Elm, if you have a list that gets too large, you have to manually break it up into different lists and do weird concatenation stuff that is quite clunky because somehow it's not doing structural sharing quite right to ensure these things are transparent under the hood. Experienced Elm users helped explain this to me, and it's not something I like to think about when writing in a functional style.
So I've been a bit hesitant to embrace just any functional programming language for serious enterprise work. But I'm very intrigued by Reason and Bucklescript and am keeping a very close eye on them. I probably won't do more than toy projects in them any time soon, but it would be great to someday.
- deleted 9y ago[deleted]
- rtfeldman 9y ago> In Elm, if you have a list that gets too large, you have to manually break it up into different lists To clarify, for anyone who comes across this later: there was a bug in the Elm 0.18 compiler that was triggered by enormous list literals. (Hence the workaround of concatenating smaller literals.) Nothing to do with the data structure itself. After all, it's a singly linked list; there's not a whole lot of variation in how those are implemented. ;)
- hellofunk 9y agoIs Elm using a particular library for its persistent structures, or are they custom for Elm? I've read that it has both List and Array, yet neither appears to be ideal for proper functional programming; List, as you say, is a linked list, yet it is recommended [0] over Array for functional operations like map, fold, etc -- but you wouldn't normally want linked lists for that sort of thing, esp. if your maps and folds were part of a larger data transformation of composed functions. Does Elm offer anything similar to the structure of ClojureScript's persistent vector? I have learned that FP without the guts of serious persistent structures is not so good in practice. [0] https://stackoverflow.com/questions/37707577/array-vs-list-in-elm#comment67060087_37707812 https://stackoverflow.com/questions/37707577/array-vs-list-i...
- drdiablo 9y agoBucklescript used to support closure output but we removed it because nobody was using it. We can get it back if enough people want it.
- hellofunk 9y agoI saw an issue or thread somewhere about the technical problems of supporting Closure Advanced in Bucklescript. I'm surprised they were solved at one point then regressed. What would be the reason for removing it, unless maybe it was easier to implement new features by no longer supporting it? Closure Advanced has many benefits so it's really nice to support it, especially if you're writing a whole site app of decent size all in one codebase.