4 ms·

Coming in from the other (Functional Programming) side, Elm can be restrictive (no typeclasses, do notation etc.). But it does walk a fine balance, and I love t

Coming in from the other (Functional Programming) side, Elm can be restrictive (no typeclasses, do notation etc.). But it does walk a fine balance, and I love that there's a popular-ish language that is exploring the ease-of-use design space.

yakshaving_jgt 8y ago
Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. Also a little surprised you mentioned do notation; it's just syntax sugar after all :)
- haskman 8y ago
  > Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. I have heard this sentiment earlier, and I believe that there is a better middle ground. Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill. > Also a little surprised you mentioned do notation; it's just syntax sugar after all :) Oh it's less of an issue, but syntax does matter a lot. I find that Monads become intractable for new devs without do-notation.
  - yakshaving_jgt 8y ago
    > I find that Monads become intractable for new devs without do-notation. That's a fair point, and I agree, however this somewhat negates your previous point: > Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill. I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with. They might feel intimidated by that, and discouraged from working with the technology at all. I'm using "team" in a more abstract sense here too; it could be all the collaborators (existing or potential) of an open source project. I'm not arguing the anti-intellectual position that everything should be dumbed-down. I just believe — as you said — there is some middle ground, which also isn't universally applicable.
    - haskman 8y ago
      > I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with. Actually in practice that's much less of an issue when using typed FP. I've found that it's easy to modify parts of code which you do understand the implementation of, while still being able to use the interface of other potentially more complex parts. Of course YMMV.

yakshaving_jgt 8y ago

Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. Also a little surprised you mentioned do notation; it's just syntax sugar after all :)

haskman 8y ago
> Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. I have heard this sentiment earlier, and I believe that there is a better middle ground. Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill. > Also a little surprised you mentioned do notation; it's just syntax sugar after all :) Oh it's less of an issue, but syntax does matter a lot. I find that Monads become intractable for new devs without do-notation.
- yakshaving_jgt 8y ago
  > I find that Monads become intractable for new devs without do-notation. That's a fair point, and I agree, however this somewhat negates your previous point: > Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill. I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with. They might feel intimidated by that, and discouraged from working with the technology at all. I'm using "team" in a more abstract sense here too; it could be all the collaborators (existing or potential) of an open source project. I'm not arguing the anti-intellectual position that everything should be dumbed-down. I just believe — as you said — there is some middle ground, which also isn't universally applicable.
  - haskman 8y ago
    > I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with. Actually in practice that's much less of an issue when using typed FP. I've found that it's easy to modify parts of code which you do understand the implementation of, while still being able to use the interface of other potentially more complex parts. Of course YMMV.