why no more primes on 0.18 ?

[mbr]

just learned that primes and backticks won't be on elm 0.18.

What are the reason for their removal? 

I will miss the primes quite a bit. Am I the only one here that feels this way ?

For instance, I would have to write headerModel___ and headerModel__ instead of headerModel''' and headerModel''

In the prime case I count the 'while on the underscore case I will compare its length.

at the end of the day, I will just skip the underscore and use number like headerModel03 and headerModel02.

And my case for backticks, I understand it will make the andThen API easier, but why completely remove it from the language ?

I guess my main question is, What is the motivation for their removal ?

[Martin DeMello]

Agreed; I'll definitely miss being able to use primes in variable names!

martin

--
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 elm-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Orford]

I am coming around to the make things as easy as possible for newbs approach.

Elm is a big jump for people coming from JS, every little helps, including removing string syntax misinterpretations.

Having said that, I suspect a total programming newcomer would find Elm right now easier than JS... 

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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 elm-discuss...@googlegroups.com.

[Peter Damoc]

Elm optimizes for learning and in doing so, encourages people to write clear code.

I too had a brief love affair with primes after watching Leslie Lamport videos about TLA+ and discovering that they are allowed in Elm.

I was encouraged to move away from them and favor a more explicit name  like newModel. I did it and never looked back.

I found that if I needed more than one prime, it was a very good sign that I might need to use functions.
Instead of naming my intermediary values something silly and useless like model03, I named the process something meaningful and then chained the processes with |> 

--
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 elm-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Nick H]

Re: primes. Totally agree with Peter. One prime is kinda nice for a temporary variable, but beyond that... you can add a short word to your variable name, and then you won't have to do any counting!

Re: backticks.

Evan's explanation from elm-dev:

The backtick syntax is neat, but ultimately, it is redundant. In practice, it is recommended against in every case, with the one exception of andThen.

My take on this: Backticks are not needed because they are redundant with the forward pipe operator.

The only situation where backticks are useful is when you are doing a single function call, and "foo `function` bar" is easier to read than "function foo bar". I haven't seen this crop up too many times. But if it does, "foo |> function bar" is just as good. 

If you are chaining together multiple function calls, backticks are a disaster. The preferred way of writing functions in Elm is to put the argument being "modified" last. That makes it easy to chain together function with pipes. For example:

map : (a -> b) -> Maybe a -> Maybe b

something |> map multiplyByThree |> map toString |> map translateToSpanish

Functions that are designed this way can't be chained using backticks. On the other hand, if you design a function to work with backticks, it is not going to chain correctly with any of the other functions.

andThen : Maybe a -> (a -> Maybe b) -> Maybe b

something |> map multiplyByThree |> flip andThen actFlippantly

Because they are so rarely needed, better to remove backticks completely and not have to worry about another `andThen` style API coming along!

On Tue, Oct 18, 2016 at 6:28 PM, mbr <mark...@gmail.com> wrote:

[Janis Voigtländer]

2016-10-19 9:27 GMT+02:00 Nick H <falling...@gmail.com>:

The only situation where backticks are useful is when you are doing a single function call, and "foo `function` bar" is easier to read than "function foo bar". I haven't seen this crop up too many times. But if it does, "foo |> function bar" is just as good. 

Except, "foo |> function bar" would be wrong. It would have to be "bar |> function foo". :-)

[Nick H]

Noooooooo

--

[Janis Voigtländer]

???

[Janis Voigtländer]

Nick, can you elaborate on why you think that my statement that foo `function` bar corresponds to bar |> function foo rather than foo |> function bar is wrong?

​

[Nick H]

Oh no, sorry for being confusing. You are 100% correct. That was a reaction to myself having made such a silly mistake :-)

[Max Goldstein]

Hey folks, this really should be on the dev list.

That said I agree with most of what's been said here. The place I'll miss primes the most is actually the grammatical possessive: root'sValue, etc. But that's not a huge deal.

[Mark Hamburg]

I use primes surprisingly often as well since if I have "newModel" then I probably also want "oldModel" rather than just "model" but I don't feel really strongly about it.

I do, however, think that underscores would be worse than primes for API cases where the normal identifier isn't available because of name conflicts. I say this because convention in a number of other programming languages uses underscores to indicate privacy of some detail and within Elm underscores are used for "don't care".

Mark

[Janis Voigtländer]

I'm pretty sure that if this were on the dev list, we would be told that it should be on elm-discuss because the dev list is "for work, not for discussion". :-)

> Am 19.10.2016 um 22:41 schrieb Max Goldstein <maxgol...@gmail.com>:
>
> Hey folks, this really should be on the dev list.
>
> That said I agree with most of what's been said here. The place I'll miss primes the most is actually the grammatical possessive: root'sValue, etc. But that's not a huge deal.
>

> --
> 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 elm-discuss...@googlegroups.com.

[mbr]

Naming sometimes can be hard.

While I agree that model03 or model''' is a code smell.

But often you are just transforming some data and the intermediate variables names are meaningless (besides reminding us that they are related)

I've seen things like newModel being used everywhere and then later a newestModel shows up.

I do also agree that triple primes is a sign that your function should be split. 

On the other hand, 3 lines functions everywhere adds too much indirection and, IMO, are code smell as well.

Another things about primes, is that its used in calculus all the time as well and I feel nostalgic about it. Silly right?

What I really wish, is that things like type_ is used instead of type' but the ability for us to use primes on out variables name not be removed from the language.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Francesco Orsenigo]

Primes can be confusing even when doing pure maths (I studied physics), it's just so easy to miss them, so good riddance.

When it comes to model names, I always try to 1) pipe my functions so that I need the least intermediate variable names and 2) use descriptive names no matter what; for example, after I applied the tick function, i get a `tickedModel`. If I need more than one or two intermediates, I rework things so I can pipe.

(Also, if I use `newModel` I never use `model` but rather `oldModel` to kill *any* possibility for ambiguity)

[mbr]

Sometimes piping is not always possible.

Let's say we want to deconstruct a tuple, pass its first item to some other function and then compare the "old" and the "new" version of it.

And about descriptive names, you end up using some variation of old, new or prev, next attached to the variable name.

Now, for the sake of argument, let's say you have two older versions of some record and you want to compare them with the actual version of it.

I could spend some time trying to find some nice descriptive name. 

But honestly, I would just attach numbers or capital letter to the end of them instead. Which is less than ideal.

There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

Some other people have mentioned somewhere here that their removal will make it easier to learn the language from those coming from JS world.

JS people are smart and they can learn little things like this. Its like the argument about JSX being too hard for designers.

At the end of the day, it's not a big deal.

[Francesco Orsenigo]

I'd happily use modelA and modelB if they can be used interchangeably. =)

Re your example, I'd say you can totally pipe the tuple into an ad-hoc function.

[Nick H]

Sometimes piping is not always possible.

Let's say we want to deconstruct a tuple, pass its first item to some other function and then compare the "old" and the "new" version of it.

Is it possible to do that with backticks?

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscribe@googlegroups.com.

[Nathan Schultz]

Primes I'll miss for convenience, like when naming an inner tail-recursion function to distinguish it from its wrapper. But it's not a big deal.

As for back-ticks, I've never used them in Elm, but I use them in F# for defining human readable Unit Tests names. For example:

[<Test>]
let ``Test that roman numerals have no more than one V``() = ...

[OvermindDL1]

On Wednesday, October 19, 2016 at 7:39:25 PM UTC-6, Nathan Schultz wrote:

Primes I'll miss for convenience, like when naming an inner tail-recursion function to distinguish it from its wrapper. But it's not a big deal.

The convention for that in a few other languages is the name 'aux', such as in this copy/paste, perhaps that same convention could be brought in for that purpose?

  let rle list =
    let rec aux count acc = function
      | [] -> [] (* Can only be reached if original list is empty *)
      | [x] -> (x, count + 1) :: acc
      | a :: (b :: _ as t) ->
         if a = b then aux (count + 1) acc t
         else aux 0 ((a, count + 1) :: acc) t
  in aux 0 [] list 

[Bob Hutchison]

On Oct 19, 2016, at 2:59 AM, John Orford <john....@gmail.com> wrote:

I am coming around to the make things as easy as possible for newbs approach.

Elm is a big jump for people coming from JS, every little helps, including removing string syntax misinterpretations.

Having said that, I suspect a total programming newcomer would find Elm right now easier than JS… 

I’ve got no problems catering to newbs either, as long as nobody forgets there’s non-newbs using elm too. The suggestion that model’ is less clear than model_ is ludicrous. Further I’d say that the set of newbs coming from JS who are able to get past functional programming, infix functions, types, and immutable data and then get confused by model' is empty. The arguments that there usually clearer ways of doing things other than using a prime is undisputedly often true, but sometimes the prime is the best way to convey meaning to the reader. Anecdotally, when I was first learning Haskell I found the prime distinctly clearer to not having it when I learned erlang (but, then, I absolutely was not a newb coming from JS). When showing Haskell to (very skilled) C and C++ programmers, using a prime when showing how to deal with immutability, results in an “Ah! Okay.” not confusion. And I *often* (as in always) use them when first writing a function because I don’t necessarily know how to name them better at the time, then fix the naming later when cleaning up. If you think primes can be abused, wait 'til you see what newbs come up with on their own to ’solve’ the problem. And yes, backticks are another thing for the newb to learn to not abuse, but sometimes they solve a syntactic problem very nicely.

Of course this is now a done deal so my whining about catering to non-existent newbs is pointless.

[John Orford]

For the record I loved using primes for the first time in Haskell - it gave me the feeling of doing maths again, but while programming : )

I agree with your '_' point. Perhaps it should also be nixed following your line of logic... But I love my underscore and forget variables also : /

[Andrew Radford]

Yeah comparing underscore length seems inferior to counting back ticks.. Maybe that was the idea? to discourage the use of double/triple primes etc and steer people to a more point free style?  The 0.18 migration guidance does not mention anything like that though

[Wouter In t Velt]

The primes I currently use mostly in msg' and in model' in update functions.

It will take some getting used to, but not too bad I guess. I agree that newModel or similar is easier to read, so probably an improvement.

The backticks like in `andThen` I won't miss. It is probably more consistent anyway to use the piping pattern e.g. someMaybe |> Maybe.andThen someFunc

I am curious though, does anyone know what the 0.18 name for the current type' (with backtick) variable will be?

from html.Attributes, as used e.g. in input [ type' "text", value "my text input field" ] []

[Wouter In t Velt]

Never mind my question: type' will be type_

[Andrew Radford]

Yeah but it does beg the question whether

type''

should become type__

and of course suggesting a possible hell scenario when this goes further: type__, type___, type____ ?!

Or, is that considered a code smell anyway so it should not be catered for? 

[Wouter In t Velt]

Op woensdag 26 oktober 2016 13:51:03 UTC+2 schreef Andrew Radford:

Yeah but it does beg the question whether

type''

should become type__

The type' variable was in the 0.17 Html.Attributes package. I don't think double primes are an issue there.

For other variables, that we define, I can see that double underscores would be less readable than double primes. But I guess the double [whatever] is probably a code smell, better served by a descriptive variants like oldModel, cleanedModel, newModel etcetera.