Show HN: Tic Tac Toe Implemented in Elm | Hacker News Reader

Show HN: Tic Tac Toe Implemented in Elm

vishaltelangre.com

I did a few games with Elm but used the SVG route myself. It's usually a lot easier to work with and you don't really have to deal with CSS and the DOM update is still lazy.

Finally, I think there are a few red flags in your code. For example you have a hardcoded list of cell locations but you use a method to compute the number of rows which has a sqrt in it... might as well hardcode the number of rows :)

Is the code for these games available? I've never programmed a game before, I want to do it. Maybe doing it in Elm will be a good idea.

I don't mean to be a naysayer, but if you want to program a real game, Elm really isn't the language to do it in. Perhaps at some point in the future it'll be a language to watch, but there are far better options available right now, even if you want to stay functional.

I am thinking to change the board model to use Dict instead of List altogether to reduce the hacks and chances of having a model which represents invalid states. Thanks.

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

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.

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...

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/).

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).

Elm was basically equal to Haskell in the beggining. It is getting increasingly different from it on every version.

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?

I meant to say that the Elm programming style is not welcome in the Haskell community.

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.

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

How many lines would it take in React?

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.

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 =

Source code is at https://github.com/vishaltelangre/elm-tic-tac-toe.

shameless self plug: a chutes and ladders game in elm on the client, python (flask) on the server. https://github.com/guyromm/snakes-and-ladders

That was fun

Reply on news.ycombinator.com