5 ms·

I'm slightly surprised that a simple tic-tac-toe game in high-level FP takes 400 lines of code.

s4vi0r 9y ago
Elm is pretty kludgy - its nice for learning FP for beginners, but because they're really committed to staying in that niche (which I think is great tbh, the more people write functional code the better!) the language lacks a lot of nice features that enable better code reuse and conciseness.
- fiatjaf 9y ago
  Not true. Who said they are commited to that? Elm doesn't even advertise itself as FP. In fact, the Elm style, although still FP, goes against a lot of FP ideals and canonical practices[1]. Instead, I think it would be more correct to say that Elm aims to be its own thing, totally independent from the Javascript and FP community, at the same time welcoming people from both (as it has been doing for quite a long time now). [1]: http://taylor.fausak.me/2015/04/09/write-more-understandable-haskell-with-flow/ http://taylor.fausak.me/2015/04/09/write-more-understandable...
  - dwohnitmok 9y ago
    Elm is definitely FP and advertises itself as such. The first sentence of the Elm guide is "Elm is a functional language that compiles to JavaScript" (https://guide.elm-lang.org/ https://guide.elm-lang.org/). I'm not sure what your link has to do with FP in the large. It's a Haskell library that aims to de-emphasize point-free programming and emphasize reverse function application over normal function composition. Neither of these choices are defining features of FP (e.g. Scala can't really express point-free programming and method calls are essentially reverse function application, OCaml doesn't have a built-in function composition operator and as a result the community very rarely uses point-free, Haskell generally uses normal function composition, F# generally uses reverse function application, etc.). FWIW, Elm's standard library has all the operators defined in that library (pipe i.e. reverse function application, reverse function composition) as well as their ordinary Haskell equivalents (forward function application and forward function composition).
    - fiatjaf 9y ago
      Elm was basically equal to Haskell in the beggining. It is getting increasingly different from it on every version.
  - dragonwriter 9y ago
    Why are you referencing a blog post about importing F# style into Haskell for a statement about “FP ideals and canonical practices”? Do you think FP is defined by F# instead of F# being I've of many FP languages, none of which individually defines canonical FP practices?
    - fiatjaf 9y ago
      I meant to say that the Elm programming style is not welcome in the Haskell community.
kqr 9y ago
Not sure how you reached that number. The Elm code, with blank lines removed, is less than 320 lines. Given the incredibly spacious style its written in, I'd definitely say 300 rather than 400. But sure, that's still a lot. Part of it is that Elm lacks the proper generics support (which you can observe in the function names) and part is that the archotecture chosen by the creator may not be optimal in terms of maintainability. For example, type Cell = NotOwned CellLocation | OwnedBy CellLocation Player and I think, why not type Cell = Cell Location (Maybe Player) ? Its isomorphic (carries the same information) and it removes the need for the complicated getters.
- vishaltelangre 9y ago
  Yes, there are lot places I think I can optimize it. It is an initial implementation to get something working. Thanks.
fiatjaf 9y ago
How many lines would it take in React?
tome 9y ago
It's full of stuff like flipPlayer : Player -> Player flipPlayer currentPlayer = case currentPlayer of X -> O O -> X which is 8 lines where idiomatic Haskell would take 3. flipPlayer : Player -> Player flipPlayer X = O flipPlayer O = X I don't know if Elm encourages or mandates that verbose style but it's not some sort of "FP" requirement.
- vishaltelangre 9y ago
  Compiler throws following error if I do it. Naming multiple top-level values `flipPlayer` makes things ambiguous. When you say `flipPlayer` which one do you want? 128| flipPlayer O =

Elm is pretty kludgy - its nice for learning FP for beginners, but because they're really committed to staying in that niche (which I think is great tbh, the more people write functional code the better!) the language lacks a lot of nice features that enable better code reuse and conciseness.

fiatjaf 9y ago
Not true. Who said they are commited to that? Elm doesn't even advertise itself as FP. In fact, the Elm style, although still FP, goes against a lot of FP ideals and canonical practices[1]. Instead, I think it would be more correct to say that Elm aims to be its own thing, totally independent from the Javascript and FP community, at the same time welcoming people from both (as it has been doing for quite a long time now). [1]: http://taylor.fausak.me/2015/04/09/write-more-understandable-haskell-with-flow/ http://taylor.fausak.me/2015/04/09/write-more-understandable...
- dwohnitmok 9y ago
  Elm is definitely FP and advertises itself as such. The first sentence of the Elm guide is "Elm is a functional language that compiles to JavaScript" (https://guide.elm-lang.org/ https://guide.elm-lang.org/). I'm not sure what your link has to do with FP in the large. It's a Haskell library that aims to de-emphasize point-free programming and emphasize reverse function application over normal function composition. Neither of these choices are defining features of FP (e.g. Scala can't really express point-free programming and method calls are essentially reverse function application, OCaml doesn't have a built-in function composition operator and as a result the community very rarely uses point-free, Haskell generally uses normal function composition, F# generally uses reverse function application, etc.). FWIW, Elm's standard library has all the operators defined in that library (pipe i.e. reverse function application, reverse function composition) as well as their ordinary Haskell equivalents (forward function application and forward function composition).
  - fiatjaf 9y ago
    Elm was basically equal to Haskell in the beggining. It is getting increasingly different from it on every version.
- dragonwriter 9y ago
  Why are you referencing a blog post about importing F# style into Haskell for a statement about “FP ideals and canonical practices”? Do you think FP is defined by F# instead of F# being I've of many FP languages, none of which individually defines canonical FP practices?
  - fiatjaf 9y ago
    I meant to say that the Elm programming style is not welcome in the Haskell community.

kqr 9y ago

Not sure how you reached that number. The Elm code, with blank lines removed, is less than 320 lines. Given the incredibly spacious style its written in, I'd definitely say 300 rather than 400. But sure, that's still a lot. Part of it is that Elm lacks the proper generics support (which you can observe in the function names) and part is that the archotecture chosen by the creator may not be optimal in terms of maintainability. For example, type Cell = NotOwned CellLocation | OwnedBy CellLocation Player and I think, why not type Cell = Cell Location (Maybe Player) ? Its isomorphic (carries the same information) and it removes the need for the complicated getters.

vishaltelangre 9y ago
Yes, there are lot places I think I can optimize it. It is an initial implementation to get something working. Thanks.

fiatjaf 9y ago

How many lines would it take in React?

tome 9y ago

It's full of stuff like flipPlayer : Player -> Player flipPlayer currentPlayer = case currentPlayer of X -> O O -> X which is 8 lines where idiomatic Haskell would take 3. flipPlayer : Player -> Player flipPlayer X = O flipPlayer O = X I don't know if Elm encourages or mandates that verbose style but it's not some sort of "FP" requirement.

vishaltelangre 9y ago
Compiler throws following error if I do it. Naming multiple top-level values `flipPlayer` makes things ambiguous. When you say `flipPlayer` which one do you want? 128| flipPlayer O =