There're a few good suggestions there. One thing that caught my eye was 5a, (List.singleton). No lambda is needed.... singleton is just the function repeat 1. But yeah, consistency with the other collection types would be nice.
(And I'm sure #6 is a non-starter.... let's give beginners some credit for being able to learn a word. We all did. :) ) On Wednesday, July 13, 2016 at 1:31:37 AM UTC-7, John Bugner wrote: > > I dislike the names of certain standard library functions. Below, I list > each one and explain why I dislike it. > > (1) Basics.max, Basics.min, List.maximum, List.minimum > (a) The names 'max' and 'min' do not clearly convey what these functions > do. When I see 'max 13 10' or '3 `max` 10', I think of the sentence '13 > maximum of 10', with 2 separate meanings, but both lead me astray! (I'm > still not sure what phrase/sentence I'm supposed to think of that makes > these function names make sense. > (i) I expect it to return 10; 'max' sets the upper bound, of course! > (ii) I expect it to return False, as if I was standing in front of an > express checkout line, and checking whether I was under the limit. > (b) 'max' and 'min' are needlessly truncated, going against the Elm style > guidelines ( > http://package.elm-lang.org/help/design-guidelines#use-human-readable-names > ): > >Abbreviations are generally a silly idea for an API. Having an API that > is clear is more important than saving three or four characters by dropping > letters from a name. > (c) I have a feeling that these names were kept just because that's what > older languages (Haskell, C++, etc) have done. If Elm is serious about > putting usability first, it shouldn't be afraid of breaking with the > unclear past tradition to start a new clear tradition. (I note that Elm has > already done this in the past when it replaced the keywords 'data' and > 'type' with 'type' and 'type alias'.) > (d) I suggest changing the names to 'greater', 'lesser', 'greatest', and > 'least'. These names clearly describe what each function does: It returns > the *greater* or the *lesser* of 2 values, or the *greatest* or *least* of > a list of values, and makes the connection with (>) and (<), which are > pronounced 'greater than' and 'less than', more obvious. > > (2) (&&), (||) > (a) These names needlessly use uncommon symbols where names of letters: > ('and' and 'or') would work perfectly fine. People already pronounce the > functions that way anyways! (And if they don't, then they're probably > confused, which just proves my point.) Again, this is against Elm style > guidelines. > (b) The Bitwise module uses the names 'and', 'or', and 'xor' for its > bitwise functions, but the boolean functions are '(&&)', '(||)', and 'xor'. > Why do they share 'xor' but not the others? There should be one pattern, > not two. > (c) Again, I think these functions are named this way to mimic older > languages. Thus, I must ask, again, is Elm about putting usability first > and making things clear? (especially for beginners who may never have > programmed before), or maintaining the poorly-named status quo? > > (3) List.member > (a) This function returns of boolean, but its name is a noun. How strange! > I've seen coding standards that would never allow this, because a function > that returns a boolean must be a *verb*, not a noun! When I read the name, > I expect it to return an item from the list, not a boolean about whether a > value is in the list. > (b) I suggest changing the name to 'isMember', 'isMemberOf', 'contains', > or (what I think is the simplest) 'has'. > (c) A small downside: The last two don't work well as an infix function. I > suppose 'member' is trying to look like JS and Python 'in', but I've never > written 'member' (or Haskell 'elem') as an infix function. > (d) There could also be a dedicated function for 'not <<< has', (where > (<<<) composes the functions correctly) which could be called 'lacks', > because it's easier to think of the concept with one name instead of two > combined. (I don't expect many people to agree with this though...) > > (4) List.filter > (a) The problem is that I forget (more often than I would like to admit) > whether the function filters the items by *keeping* the items that satisfy > the predicate, or filters the items by *tossing out* the items that satisfy > the predicate. > (b) I suggest the clearer and shorter names 'keep' or 'take'. > (c) A downside: For 'take', the old 'take' would have to change to > 'takeFront', 'takeFirst', or something else. > (d) There could also be a dedicated function for 'filter (not << f)', > which could be called 'toss' (in the sense of 'throw away'), 'discard', or > 'drop' (Again, the old 'drop' would have to change.), because, again, it's > easier to think of the concept with one name instead of two combined. > (Also, I think a name like Python's 'itertools.filterfalse' is unclear and > annoyingly long.) > (e) Evan himself has already voiced his own distaste for the name 'filter' > in this thread ( > https://groups.google.com/forum/#!searchin/elm-discuss/filter$20list/elm-discuss/4PSA48ws5JU/nkEAXRLftEAJ > > ), but strangely, it seems that nothing ever happened afterwards! The > thread just sorta fizzled out and people forgot about it. I bring this up > again, because I strongly believe that a function this common and important > should have a simple and clear name that doesn't confuse people. (Indeed, I > would be fine with the names 'keepIf' and 'dropIf' for these functions as > that thread suggested. I note though, that if Elm went that route, then > 'take' should be changed to 'keep' to keep things orthogonal.) > > (5) The ones that don't exist (in List and/or Array): singleton, range, > none, tails, shuffle > (a) 'singleton' : Dict and Set have it, why not List? Because I can just > do '[a]'? But what if I want to pass it as an argument? Creating a lambda > right there just for that feels silly. > (b) 'range' : Again, I want to be able to pass it into another function > without creating a one-time-use lambda for '[a .. b]'. > (c) 'none' : 'all (not << f)'. Again, it's simpler to reason about one > name than two: 'none isRed' sounds more natural than 'all (not << isRed)'. > (d) 'tails' : It's in Haskell's Data.List, so why not here? Is it too > rarely-used and intimidating to the beginner who stumbles upon it in the > standard library, perhaps? They'll be grateful the day when they realize > that they need it though. > (e) 'shuffle' : This *really* should be provided. Do we really want > everybody and their dog reinventing the square wheel? Writing a > fisher-yates shuffle improperly can introduce subtle imbalances in the > output that can go unnoticed for a long time. Elm can nip all these errors > in the bud by providing a correct fisher-yates shuffle in the standard > library. Wanting to shuffle a list or array isn't even an uncommon thing to > do!, so I was surprised when it wasn't in the standard library. > > When exploring a new language, I hate having to write a bunch of basic > functions to finish what feels like an incomplete standard library. I want > to get to writing *my* program right away, without first having to > supplement the standard library. > > (6) Honorable Mention: String (the type) > (a) The name is completely opaque to beginners to programming. However, > changing this to 'Text' would be a huge breaking change. > (b) The snarky side of me always asks: "A string *of what*?" > > Thanks for reading. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
