Elm angetestet

elm

#1

Ich habe mal sehr oberflächlich mit Elm herumgespielt. Herausgekommen ist ein kleines Tic-Tac-Toe:

elm

Und dazu mein Noob-Code:

import Html exposing (Html, button, div, text, br)
import Html.Events exposing (onClick)
import List exposing (map, all, any)
import Array exposing (Array, get, set, fromList, repeat, length, filter, toList)

main =
  Html.beginnerProgram
    { model = model
    , view = view
    , update = update
    }

-- MODEL

type Field
   = None
   | X
   | O

type Model
  = Model
  (Array Field)  -- board
  (Maybe Field)  -- winner

model : Model
model =
  Model (repeat 9 None) Nothing

-- UPDATE

type Msg
  = Move Int
  | Restart

update : Msg -> Model -> Model
update msg (Model board winner) = case msg of

  Restart ->
    model

  Move index ->
    let
      count field =
        board
          |> filter ((==) field)
          |> length

      playerToMove =
        if count X == count O then X else O

      newBoard =
        set index playerToMove board

      findTriple =
         all <| \i -> get i newBoard == Just playerToMove

      newWinner =
        if any findTriple [[0,1,2],[3,4,5],[6,7,8],[0,3,6],[1,4,7],[2,5,8],[0,4,8],[2,4,6]]
        then Just playerToMove
        else if any ((==) None) (toList newBoard) then Nothing else Just None

    in
      Model newBoard newWinner

-- VIEW


view : Model -> Html Msg
view (Model board winner) =
  let
     buttonText n =
        case get n board of
          Just X -> "X"
          Just O -> "O"
          _ -> "..."

     buttonAttributes n =
        if get n board == Just None && winner == Nothing
        then [onClick (Move n)]
        else []

     makeButton n =
        button (buttonAttributes n)  [ text (buttonText n) ]

     endButtonText = case winner of
        Nothing   -> "Restart"
        Just X    -> "X has won"
        Just O    -> "O has won"
        Just None -> "Draw"

  in div []
    [ div [] (map makeButton [0,1,2])
    , div [] (map makeButton [3,4,5])
    , div [] (map makeButton [6,7,8])
    , br  [] []
    , div [] [button [onClick Restart] [text endButtonText]]
    ]

Das Programm war für mich mit etwas Haskell-Erfahrung kein größeres Problem, ich habe nur hin und wieder ein paar Haskell-Features vermisst, was aber nicht weiter ins Gewicht fiel. Sicher kann man noch vieles verbessern, aber im Großen und Ganzen bin ich damit recht zufrieden - war ja auch nur ein Test.

Das Tooling von Elm könnte natürlich besser sein, aber der elm-reactor ist schon recht hilfreich.

Wie gut das ganze skaliert, kann ich schlecht beurteilen, und wie leicht einem bei komplizierteren Layouts das Styling fällt, ebenfalls nicht. Die konzeptionelle Einfachheit hat jedenfalls ihren Charm.

Letztendlich entspricht Elm als Sprache ziemlich genau dem Paradigma, was mit React, Immutable.js u.s.w. erst mühsam in Javascript hineingeprügelt werden musste. Insgesamt sehe ich durchaus Potential für die Sprache, insbesondere da, wo es weniger um hübsche Seiten, sondern mehr um korrektes Arbeiten mit komplizierten Abläufen und Modellen geht.


#2

Joa, sieht ganz interessant aus. Um das ganze - d.h. das, was man sieht - “hübsch” und für reale Anwendungen aussagekräftiger zu machen, müßte halt noch CSS, I18N, Server-Kommunikation & Co rein, wodurch es (jetzt: der Code!) potentiell “häßlich” würde.

Aber … ein bißchen Polemik, als Provokation, ich würde mich auf Widerspruch freuen (weil er so leicht in Grund und Boden zu stampfen wäre) : Wenn für sowas mit React dutzende Zeilen (ungetyptes!) JavaScript mit reingewurstetem JSX geschrieben werden und das dann von Babel mit LessJS-CSS-Templates verrührt werden muss, liegt die Latte dafür, etwas “besser” zu machen nun nicht sooo hoch. (Haar. Sträu. Bend.)

Wichtig wäre auch ein vernünftiger Debugger, da muss man sich wohl http://debug.elm-lang.org/ mal näher ansehen.

Ein Blogbeitrag, den ich mir vielleicht auch nochmal ansehen werde: http://www.elmbark.com/2016/03/16/mainstream-elm-user-focused-design

Warum? Dieses Bild hat mein eye gecatcht:

I have a feeling that we’re at another one of these crisis points where the issue again is maintainability.

When you talk to companies that have fifty thousand or a hundred thousand lines of JavaScript, they’re in this place that when they add a new feature, they’re going to break three.

Full ack erstmal soweit. (Ob Elm da nun “Die Lösung®” ist? Dafür habe ich davon vieeel zu wenig Ahnung. Aber ich weiß, dass JavaScript keine Lösung ist, sondern ein Problem)


#3

Der Debugger ist einer der coolsten überhaupt, er kann “back in time”. Hab’s allerdings selbst noch nicht ausprobiert. Allgemein sehr gelobt werden übrigens die netten und hilfreichen Fehlermeldungen des Compilers, was ich auch bestätigen kann.

Es gibt natürlich auch JS-Interop, also könnte man ja erst mal Wrapper-Module schreiben (keine Ahnung wie schwierig das in der Praxis ist).