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. On Wednesday, October 19, 2016 at 5:15:20 PM UTC-4, Francesco Orsenigo wrote: > > > 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) > > > On Thursday, October 20, 2016 at 7:56:11 AM UTC+11, mbr wrote: >> >> 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. >> >> >> >> >> >> >> On Wednesday, October 19, 2016 at 3:06:58 AM UTC-4, Peter Damoc wrote: >>> >>> 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 |> >>> >>> >>> >>> On Wed, Oct 19, 2016 at 4:28 AM, mbr <[email protected]> wrote: >>> >>>> 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 ? >>>> >>>> -- >>>> 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. >>>> >>> >>> >>> >>> -- >>> There is NO FATE, we are the creators. >>> blog: http://damoc.ro/ >>> >> -- 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.
