Something like (*2) would not really work well in most cases in Elixir as functions can have multiple arities (though not in *), and how would you know which to choose?
In languages like ML’y languages where every function is arity 1 (every-single-one) then something like (*2) becomes trivial to implement as it is not currying at all, it is instead just calling */1, which happens to return another function that is also arity 1. ^.^
I agree with you about the mental effort of giving names to trivial things. I find anonymous functions to be used a lot in Elixir. No, that shorthand syntax doesn’t come from Ruby.
if you don’t know what a thing should be called, you cannot know what it is. If you don’t know what it is, you cannot sit down and write the code.
…
If you can’t name it, you can’t write it. If you change the name 3 times, then you should stop until you know what you are trying to build.
I would have just said: “If you can’t name it, how do you know it’s doing what it needs to do?”
I like naming things - like you, I feel they act as documentation of sorts
Some people (like DHH) go further and do not like comments at all, but instead prefer long(ish) variable and function (or in his case, method) names so they can replace comments.
I don’t think they are devoid of meaning, they signify the 1st, 2nd, 3rd etc
What is I``jk and [x|xs]?
[h|t] is fine as I imagine most people will know what that is (similarly perhaps, common abbreviations such as r``g``b - though personally I would prefer to be explicit).
Having said that, I gathered @mmport80 to be doing something like:
While that may signify a parameter position within the function it doesn’t contribute any information about what the parameter’s role is within the problem that the function is solving.
i, j,k typically a whole number counter that is part of an exit condition for iteration, recursion.
[x|xs]x - a single element at the head of the list; xs a list of 0 or more elements (of the same type as x) - essentially what Haskell-ites use instead of [h|t], but it can come up in any language, in code that is written by someone who has used Haskell because it intuitively conveys: one x vs. zero-to-many of the type of x.
I seem to be in the minority but I feel that code that makes extensive use of anonymous functions is ultimately harder to reason about.
Source code isn’t for the computer, it’s for the person who has to maintain it down the road (possibly yourself after 10 or so other projects/products in 6 different languages have already passed through your brain). It ultimately forces the reader to be a human parser and make up names on the fly in order to compartmentalize the details.
I much prefer short (hopefully expressively) named functions where I only have to parse a tiny bit of code to get a general notion of what it does so that I can ditch the details and recall the “general notion” whenever I encounter the name.
In the particular case of the above with expression replacing the anonymous functions with named functions we could get an initial impression of what the code is all about - anonymous function force us to parse every nitty gritty detail.
This is precisely a good example of why well typed functions are useful. You don’t often need to name things since the types themselves already name them (and in any good IDE you get those on hover or in inline fake comments or so).
Anonymous functions are much easier and readable in a typed world.
This is precisely a good example of why well typed functions are useful. You
don’t often need to name things since the types themselves already name them
Really?
int → int → int
? However that may not be what you mean well-typed? and you’d rather
use type aliases or similar to give context (probably not the right word
to use here) to the types?