91–100 of 134 posts
Currying makes positional only parameters look cooler and fancier. It's a trap. Labeled arguments is the way to go for 99% of all parameters. Accidental currying is horrible.
Currying makes positional only parameters look cooler and fancier. It's a trap. Labeled arguments is the way to go for 99% of all parameters. Accidental currying is horrible.
If you look at how people actually write PureScript, which is much like Haskell, but with anonymous records, you can see that they're not actually used 99% of the time.
It should be called Schönfinkel. But I guess, curry is easier to pronounce.
It should be called Schönfinkel. But I guess, curry is easier to pronounce.
Earlier quoted context omitted.
It is clear that that poster does not understand what currying is, as defined in the first line of the article and easily found online; also, downthread [1], nor do you. Currying is when you turn a function of multiple parameters into nested functions of single parameters. Partially applying a curried function is not called currying. Though if enough people share the confusion, I guess it becomes an alternative defin…
I can see how someone might think I don’t know the difference, but it’s rather that I don’t think the details are important. They are both ways of partially applying a function. I wanted to demystify currying and show the equivalence, but I was too brief about it. A method is a function with convenient syntax. Some of its arguments come from the “this” parameter. If the object is immutable and the method has no side-…
I have to concur with grandparent and also with user https://news.ycombinator.com/user?id=whilenot-dev in a sibling subthread.
Earlier quoted context omitted.
I think you confuse currying with partial application.
Are you saying this to be helpful, or just to show you're smarter? If you're saying this to be helpful, you should probably explain more. Currying is a subset of partial application, so I suspect the person you're responding to is just being a bit loose with their wording, as opposed to not understanding the topic.
No, it isn't; it's a different operation.
Currying refers to building (effectively) functions of multiple arguments out of only one argument functions (such as in a language that has only those).
A curried function is not understood to have been applied, partially or otherwise; none of its arguments have been bound to values, thereby reducing its arity.
Partial application is an operation that requires one or more arguments. Currying does not require arguments; rather, the result of currying requires arguments (all of them).
There is a sort of partial application (effectively) going on when the curried function is applied to the arguments, which has to be done one argument at a time through the chain. At each step, one more argument is bound, and fewer remain.
Earlier quoted context omitted.
I much prefer partial application. It just makes more intuitive sense - you take a function with many arguments, "fix" some of those arguments, and get a new function out. No need to mess with argument ordering, or all that. It's a shame the only language that did partial application well is, weirdly, Python.
Partial application just means fixing some arguments. My point was you can do that easily using lambda functions. I guess you were talking about `functools.partial`, which is basically the same as currying and also only works on the last arguments. It's better to use lambda functions. Also Python is far from the only language to have a function like that, e.g. see C++'s `std::bind` which nobody* uses since lambdas we…
I was talking about `functools.partial` yes, but it can work on any arguments in order, using keyword arguments.
e.g.
def copy(source, dest):
.....
copy_to_temp = partial(copy, dest="/tmp/")
copy_from_temp = partial(copy, source="/tmp/")Earlier quoted context omitted.
Hi, as someone who has been interested in functional programming for a while but who struggled to read point-free Haskell code until recently, I think it might be useful to share my perspective. gears = filter ((==2) . length) . map (neighbouringNumbers numbers) $ filter ((=='*') . fst) symbols If this Haskell code does not look clear, it's because people are unfamiliar with point-free style, not because the this cod…
They say that array languages are pretty readable once you get used to them, too? But you’re drastically limiting your audience. Part of readability is writing for people who aren’t as fluent as you are. Expert jargon can sometimes be useful, but it often obscures things that would be pretty simple if written some other way. With Haskell there’s a tension between saying “I only care about writing for other expert pro…
However as I mentioned, since it is not true that most people can read FP code, I mostly avoid using it. The example comes from my solution to AoC2023's Day 3, "Gear Ratios", which is just about the only thing I use Haskell for.
That doesn't mean that using it doesn't have practical applications, since being used to multiple paradigms opens you up to unconventional solutions. I've recently sped up a MATLAB function ~100x through using a more functional style to manipulate memory more efficiently. Async/await, certain styles of modern iterator manipulation and generators escaped F#, CLU and others into C# and from there into the world at large specifically because Microsoft programmers saw a problem they had had a solution for in previous functional projects. So it's not all useless.
For the record, a more imperative version could be written as
symbols = [ imagine there's stuff here ]
gears = []
for (symbol, coord) in symbols:
if symbol == '*':
ns = neighbouringNumbers(coord)
if len(ns) == 2:
gears.append(ns)
gears = [ neighbouringNumbers(coord)
for symbol,coord in symbols
if symbol == '*' and len(neighbouringNumbers(coord)) == 2 ]
Personally I just find nowadays that having to comprehend "it collects neighbour-pairs from '*' symbols" from the imperative code harder than having that be the thing that is actually written down.
Earlier quoted context omitted.
You can have partial function application without currying. The problem with currying is that it's implicit, and positional. Two very bad things in programming.
As I said in another comment down below. Currying is great for rapid prototyping because you dont have to define a new function. eg. add1 and add(1) which you then can use for map/reduce or pointfree programming. In production code it often makes more sense to be a bit more detailed and verbose to make it readable for devs who are not familiar with currying. But abstraction in general is not something that is "bad".…
x = y 3
vs
x = partial y 3
I would vastly prefer the latter. And if you do it a lot you could have a symbol for it in your language.
Your examples are unrelated to currying though...
Currying makes positional only parameters look cooler and fancier. It's a trap. Labeled arguments is the way to go for 99% of all parameters. Accidental currying is horrible.
If you look at how people actually write PureScript, which is much like Haskell, but with anonymous records, you can see that they're not actually used 99% of the time.