Hello, I’ve been sort of reading up on Elm now and again. I decided to follow through a bit with an actual coding project without giving up…and I did manage to “do something”.
Here is that something–it’s a box in which you can click points and get numbered dots connected by lines…as well as my account of getting there:
It was largely a good experience, and went smoothly once it got going. But I mention some feedback points on the Try Elm examples–in particular the Playground.
From the “Conclusion” way down at the bottom:
Once I got started with it, Elm did not feel hard to grasp. Strangely, the
“easy” examples on the “Try Elm” site were the part that threw me off the
most. Something about their presentation created a barrier to being able to
contextualize just what it was that I was looking at.
I can empathize with why the playground examples are included. They are
actually a fairly sophisticated demonstration of abstracting away application
structure. It’s in a style that would be difficult in many other languages.
But the purple dot example–with no user state and deliberately unused
parameters–really just added confusion for me. The lack of type signatures
and comments turned it into a cryptic puzzle to be solved about advanced
abstraction features, as opposed to an “easy” example for teaching! And
once the puzzle was solved, I found I had to throw it all out…which makes
me feel the Playground is a bad entry point.
I’d be happy to elaborate on this. One concrete suggestion I’d certainly make here is that the samples themselves follow the Elm Style Guide. It mentions type signatures and qualified names. I’d have been able to search much more effectively if
game had been called out as
Playground.game, for instance. It would also be ideal if the examples were engineered in such a way that they did not need to use