elm points of note

gistfile1.txt

possibly nice things
--------------------

* elm packages seem to have a better-than-js story wrt js-type of breakage

* significant reduction of runtime errors

* significant amount of type inference -- contrary to claims, it doesn't 
  appear completely optional, but have only encoutered one type of
  case so far
  
* compiler's error messages are very often on the helpful side

* generative (fuzz) testing appears available

* immutable data structures

* the debugger support (https://elm-lang.org/news/the-perfect-bug-report)

may be not so nice things
-------------------------

* rh's point in his maybe not talk:

    And you will hear this said: this is the way to do this. This fixes the
    problem. What is great about it is: it forces you to check. And of course 
    that is the most important thing in programming: that somebody is watching 
    you and making sure you are checking for nils, no matter what the cost. 
    And the problem is: no one can articulate the costs. No one ever mentions 
    costs. It is all benefit.

  to expand on that a bit, if you have n alternatives to "try out" in clojure,
  you can get going without working on types.  once you have an idea of which
  path you want to take (out of the n), you can add checking and verification
  (e.g. by using spec) later and to varying degrees.  so that's paying cost for
  one thing out of n.
  
  with elm, haskell, and the like, to evaluate those n alternatives via code, 
  you must get the type info correct up front, so you are forced to pay that 
  cost if you wish to "see the code run".  so that's paying n costs, not one
  like in the clojure case.
  
  exploration in such languages (at least via code seems like it could 
  get much more expensive and time-consuming than in a typical lisp (or 
  other language that is either dynamically typed or has optional type 
  checking).

* eric normand's point about evaluating libraries in his youtube video:

    very often in libraries like you know part of the same story I would look 
    open the library the documentation for it and there's just a mass of type 
    information that you have to learn even just to evaluate whether there
    is a whether there this this has all the features you need right

    so I would start reading about these types and then have all these
    definitions like okay how do these interact and how am I supposed to use
    them

    there's just a lot going on there

    and I talked to someone who's you know very into types and about this
    because it was it was kind of bugging me it was like I I can't learn
    some weird type just to know whether the library is gonna do the right
    thing at the value level right

    you I mean you really have to trust that they got to type right to
    be able to represent the value that you need

    and so I talked to him about it and he said yeah that's a thing that
    they you know in general what's happening is people are moving
    complexity from the value level into the type level

    so they're having fun working at the type level that's like solving a
    puzzle it just feels really good to like invent things and and make
    machinery and stuff and then look how clean my value level code is

    but man to get to understand how that type level machine works
    it's a lot of work

    via: https://youtu.be/xcZ5yq_gG-4?t=981

* possibly because of 0.x status, subject to certain kinds of major changes

* breakage / change in elm that leads to tooling breaking.  for example,
  multiple elm-mode features no longer work (e.g. add annotations).
  should have expected given that elm is 0.x?  was there even any discussion
  with makers of tools before changes?

* the emacs situation became somewhat worse (0.18 -> 0.19) imo because for 
  certain features, lsp seems to be necessary, but the language server is
  built using node.  doesn't that mean that kind of tooling will suffer
  from js library churn?  want my tooling to be stable.

* vscode extension seems wonky.  keep seeing errors / warnings that
  go away if the project is closed and opened again.  hopefully this
  will get fixed.  for reading code, the vscode option seems ok, but
  for editing it's quite distracting with false alarms.

* yet another irregular syntax to learn

* the indentation of the editor tooling seems to guess seems wrong
  often.  spending a fair amount of time adjusting indentation.  not
  sure if using elm-format would fix this -- doesn't seem likely to
  work all of the time.

* had difficulty figuring out what some constructs are, e.g. Html Msg

* search for "why i'm leaving elm" blog post

* encouraging larger source files when unclear whether existing tooling
  is nice enough to compensate
  
curious things
--------------

* tuples can have up to only 3 items

* elm packages appear to follow semver, but unclear whether the language
  itself does.  language is 0.19.1 at the time of this writing, but there
  are statements that it's "production ready".