The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

christian_ (4) [Avatar] Offline
#1
I am reading the book and noticed a minor point that I think could be improved.

On page 6, the text is:

Sure enough, Elm has both a ++ and a + operator. They are used for different things:
• The ++ operator is for appending. Using it on a number is an error.
• The + operator is for addition. It can only be used on numbers.


I think it would be more appropriate to refer to the ++ operator as one for "concatenation" rather than "appending", especially for Elm beginners coming from JavaScript. To append usually means to take one element (say a string) and add it to a container (an array or a list). To concatenate means to take two things of the same type and make them one.

With the point of this section being that Elm is very explicit, it may even be a good idea to briefly mention the :: operator, which does serve to append.
rtfeldman (60) [Avatar] Offline
#2
Fair point! Since concatenation is an accurate description of what's happening here, this seems like a reasonable change.

Thanks for pointing it out!
tempusfugit (144) [Avatar] Offline
#3
Can we please stop making up names for operators and just stick to one single official name?

The official documentation:

Put two appendable things together. This includes strings, lists, and text.

So "appending" is actually closer to the official documentation - though I would prefer that Evan Czaplicki would actually "pick a name".

I still remember with loathing the frustration that I experienced when trying to hunt down some good information on the thread first and thread last macros when I was learning Clojure - because every source seemed to make up their own names for them:
  • Online searches for operators are notoriously difficult because of their use of non-alphanumeric characters - unless you happen to know what the operator is called.

  • If different sources use different names, online search results will be sub-optimal because you need to know all the possible names.

  • Whatever you may think of Eric J. Evans Domain Driven Design it is hard to dispute the benefit of ubiquitous language - and having more than one term for the same concept does not promote clarity.


  • The same applies to forward function application** which is introduced on p.93 (4.1.2) as the "Pipeline Operator". (Un)common usage notwithstanding, I think Elm neophytes need to be introduced to the "official" name first and repeatedly - using the same language just makes communication (written and spoken) so much easier.

    **non-alphanumerics don't work for URL fragments that great either - "always" is two positions above "|>".
    rtfeldman (60) [Avatar] Offline
    #4
    Yeah the original reason I chose that wording was that there's an Elm term called "appendable" (and ++ works with appendable values).

    The problem is that "append" in JavaScript is a name for a specific function which adds one element to an array, whereas ++ adds two collections.

    This does make me wonder whether anyone has actually been confused by the current wording, or whether it's a theoretical concern. Since I can't do both (using a consistent Elm term and avoiding the related JavaScript term) I think I'm going to default to the status quo and leave it as "appending".
    tempusfugit (144) [Avatar] Offline
    #5
    Also in Elm the notion of concatenation is already cornered by List.concat (and String.concat) - it's not too much of a stretch to imagine that List.concat could at some point be generalized to merging a list of "appendables" rather than a list of lists.

    Finally it's List.append and String.append that redirect to (++), not List.concat (or String.concat) .
    christian_ (4) [Avatar] Offline
    #6
    What prompted me to make this post is the fact that a team member who is learning Elm tried to use (++) to append a string to a list of strings based off of the documentation (we have started using Elm at work). The easiest way to explain was to say that (++) is to used to concatenate two lists and an operator like (::) can be used to prepend (or append to the front) an element to a list.

    The table in section 1.4 on page 22 compares JavaScript functions with their Elm equivalents. Elm's (++) operator is the equivalent of "Array.prototype.concat()". It seems to me that (++), List.concat, and List.append all do concatenation (with the only difference between them being slightly different arguments), (::) or "cons" is what does "prepending", and there is no way to directly "append" to the end of a list in Elm. I can see why this is confusing for a beginner and I think it would make more sense to avoid using "concatenate" and "append" for what is effectively the same operation.

    To address the point of what it says in the official docs:
    Put two appendable things together. This includes strings, lists, and text.

    The problem is that we can't agree on what the term for "Put two [things of the same type] together" is. I argue that it makes more sense to call this action "concatenate", but based off of the names of the functions in the List module, it is not clear, as both "concat" and "append" are used for this purpose.

    EDIT:

    It looks like the issue of making comparisons to JavaScript is being raised by some in other topics, which is part of the source of this issue. Personally I am for comparisons between Elm and JavaScript, since I think it is somewhat unlikely that someone will be writing Elm without ever having written JavaScript before. The very start of the book is a personal anecdote from Richard on finding Elm as a solution after trying several JavaScript libraries/frameworks. I think this sets the tone for the rest of the book and there is no reason to pretend people are learning Elm in a vacuum.
    tempusfugit (144) [Avatar] Offline
    #7
    christian_ wrote:I argue that it makes more sense to call this action "concatenate", but based off of the names of the functions in the List module, it is not clear, as both "concat" and "append" are used for this purpose.

    I find whenever understanding continues to elude me in Elm (or Haskell) that focusing on picking apart the function types in excruciating detail often provides me with the last little insight that I need to move on. So in this case:

    -- List.append
    append : List -> List -> List
    
    -- String.append
    append : String -> String -> String
    
    -- List.concat
    concat : List List -> List
    
    -- String.concat
    concat : List String -> String
    
    


    So concatenation refers the process of merging a List of n instances of a mergable type into a single instance of that type.

    append simply takes two instances of a mergable type and returns a single instance of that type.

    (++) is a binary operator which just like append simply takes two instances of a mergable type and returns a single instance of that type - only rather than taking two parameters (++) takes a left and right operand.

    christian_ (4) [Avatar] Offline
    #8
    Fair point. But this raises the question: what verb would you use to describe what the (::) operator does?

    > (::)
    <function> : a -> List a -> List a
    
    > 1::[2,3]
    [1,2,3] : List number
    
    tempusfugit (144) [Avatar] Offline
    #9
    (::)
    Add an element to the front of a list. Pronounced cons.

    For historical reasons adding a new head to a linked list is referred to as cons (construct).

    christian_ wrote:The very start of the book is a personal anecdote from Richard on finding Elm as a solution after trying several JavaScript libraries/frameworks. I think this sets the tone for the rest of the book and there is no reason to pretend people are learning Elm in a vacuum.

    Elm has its roots in Haskell which is extremely rigorous - JavaScript by comparison comes across as extremely sloppy (no offence intended). So I wouldn't expect the transition from JavaScript to Elm to be without friction.
    christian_ (4) [Avatar] Offline
    #10
    tempusfugit wrote:Elm has its roots in Haskell which is extremely rigorous - JavaScript by comparison comes across as extremely sloppy (no offence intended). So I wouldn't expect the transition from JavaScript to Elm to be without friction.


    And yet Evan has clearly designed Elm to be a lot simpler than Haskell so that web developers can learn and use it with ease. Do not get me wrong, I am a fan of Haskell and learning it is what brought me to Elm, but "simplicity and ease of use" are key tenets of Elm's design, which is not the case with Haskell. This is obvious in everything from its compiler errors to the fact that even in 0.18 we saw the removal of primes in function names and "[1..x]" notation in list declarations.

    I like how rigorous Haskell is, but Elm is not Haskell, and minor annoyances like this one can turn people off from the language. If someone is looking for the rigor of Haskell for front end web development, they should an alternative like PureScript. Having the same expectation of Elm is not in line with a big component of its core philosophy.
    tempusfugit (144) [Avatar] Offline
    #11
    christian_ wrote:"simplicity and ease of use" are key tenets of Elm's design, which is not the case with Haskell. ... but Elm is not Haskell, and minor annoyances like this one can turn people off from the language.

    In this case I suspect that "simplicity and ease of use" actually refers somewhat to Rich Hickey's talk Simple made Easy (transcript) which clearly makes the point that "easy" is more often than not associated with "familiar", while something can be "simple", yet "unfamiliar" and therefore may not be perceived as "easy". People need to stop shying away from the "unfamiliar" in order to grow and progress.

    Evan's goal seems to be to make Elm more "accessible" by keeping concepts like monads and higher kinded types at arms length while exploiting their properties behind the scenes within the Elm runtime - so I don't see him giving up on "rigor" which is evidenced for example by the fact that only the Elm runtime is allowed to generate side effects.