Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Currying

wiki.haskell.org

Post reply on HN
Print view View original

71–80 of 134 posts

Re: Currying

#71

Post by [deleted] »

luc4 wrote: post #66
kerkeslager wrote: post #61

Earlier quoted context omitted.

> My answers are almost always less intented for the person who's post I'm responding to, but more for a general audience Same. I don't expect you're going to admit your mistake, but I'm pointing it out because the general audience is the sort of audience who is prone to this mistake (which I only know because I myself have been corrected for making this mistake). > As others have already posted the part about "curry…

It's ironic that your responses come off as much more rude and condescending than the comment in question.

[deleted]

Re: Currying

#72

Post by nightlyherb »

kerkeslager wrote: post #57
kamray23 wrote: post #45

Earlier quoted context omitted.

I don't think currying happens without you asking to, though. It happens because it happens, it's part of the language, and it's something you implicitly keep in the back of your mind every time you see a function call. I don't program a lot in Haskell, only some maths things I sometimes might need since it is rather useful for that, but the concept of currying is so natural that it's constantly expressing itself in…

> I don't think currying happens without you asking to, though. It happens because it happens, it's part of the language, and it's something you implicitly keep in the back of your mind every time you see a function call. Eh, but that's my point: I want less cognitive load. Currying is another thing that I have to keep in the back of my mind, and Haskell already has way too many of those, and it's not a particularly…

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 code is badly written, and especially not because the reader is stupid.

The given Haskell code reads naturally to me now. (I'm only a little uncertain because I can't write Haskell.) It would have been line noise to me before before point-free style clicked.

I tend to read Haskell code in articles from right to left, and it reads: "Choose the symbols whose first letter is '*', get their respective (neighboringNumbers numbers), and choose the results whose length is 2". I read (neighboringNumbers numbers) as if it were a noun.

I don't know how this clicked, but I'm pretty sure it has nothing to do with stupidity. Perhaps it was by chance, or perhaps it was by banging my head against the wall enough times.

Would I introduce point-free style in a JS codebase? Probably not. People are unfamiliar with this kind of style. Would I introduce this style in a Haskell codebase? Almost certainly, because it's clear and I think it reflects how Haskell programmers think.

Re: Currying

#73

Post by fxj »

Currying is only a part of the functional programming stack. It can make your life easier when you combine it with other functional programming techniques like tacit programming. e.g. you have a function with a very long arguments list and dont want to write the arguments over and over again, but still dont want to define an additional function.

https://en.wikipedia.org/wiki/Tacit_programming

https://medium.com/@jesterxl/real-world-uses-of-tacit-progra...

when you use tacit programming and currying together you can write code in a "bash-like" pipe style which not only makes the program more readable but also is less error prone.

https://wiki.haskell.org/Pointfree

Re: Currying

#74

Post by bPspGiJT8Y »

kerkeslager wrote: post #68
bPspGiJT8Y wrote: post #65

Earlier quoted context omitted.

> What if you forget, not in quotes, to give the second argument? I will get a type error and it will take me 2-3 seconds to figure out what it is about. > Why on earth would you want to get a type error in a completely different part of the code because you got a function instead of an integer? Why would it be in a completely different part of the code? At most it would be 2 lines away, but usually on the same line.

> I will get a type error and it will take me 2-3 seconds to figure out what it is about. You should really screen capture yourself coding sometime. On a large codebase you're lucky if the compiler even runs in 10 seconds. > Why would it be in a completely different part of the code? At most it would be 2 lines away, but usually on the same line. Because possibly you return the partial assuming it's a number, and try…

> Because possibly you return the partial assuming it's a number, and try to use it somewhere else, possibly even in another file.

Sorry, I must've been more explicit instead of implying certain usage patterns. What I meant here is that I have a hard time imagining this happening because I would start working on a function by writing its type signature. Unless my types check out, I won't be able to mark this function as "done" and jump to another part of code. So the situation "you return the partial assuming it's a number" simply can not happen, that's exactly what type checking is for. By the time I use it in another place, it has to already have been type checked.

Re: Currying

#75

Post by fxj »

solardev wrote: post #2

In my entire life as a programmer, this is the one thing that I've found most confusing. Our old codebase used a lot of curried Ramda functions and nobody on the team could read any of it. We spent a week ripping every single instance of it out and replaced it with regular lodash and never looked back and never had an issue with it again. After like ten or fifteen hours of trying to understand what currying is, I sti…

In my experience, functional programming really shines in rapid prototyping. However, in production code I would try to avoid it, because it can confuse developers that are not used to it and also sometimes I struggle myself when decoding the short "clever" one-liner that I wrote 5 years ago. But if you want to write very powerful code withing a single line it is really great and makes you very productive for finding solutions fast. It is a bit like the Perl throw-away code we were writing in the 1990s. ;-)

just my 2 ct

Re: Currying

#77

Post by boxed »

fxj wrote: post #73

Currying is only a part of the functional programming stack. It can make your life easier when you combine it with other functional programming techniques like tacit programming. e.g. you have a function with a very long arguments list and dont want to write the arguments over and over again, but still dont want to define an additional function. https://en.wikipedia.org/wiki/Tacit_programming https://medium.com/@jest…

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.

Re: Currying

#79

Post by fxj »

boxed wrote: post #77
fxj wrote: post #73

Currying is only a part of the functional programming stack. It can make your life easier when you combine it with other functional programming techniques like tacit programming. e.g. you have a function with a very long arguments list and dont want to write the arguments over and over again, but still dont want to define an additional function. https://en.wikipedia.org/wiki/Tacit_programming https://medium.com/@jest…

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".

high level abstraction can make you very productive, but it can also be rather unreadable. e.g. two code snippets in python (yes this is valid python code with some operator overloading):

# compute pi by drawing random numbers in a circle

  1000000 >> ψ( ψ(χ>>op("(x**2+y**2)**0.5>Σ*4>> _/_)
or this:

  # 10 fibonacci numbers

  [x:=[1,1]] + [x := [x[1], sum(x)] for i in range(10)]
I would of course not use that in production code, but for a rapid prototype it is priceless to do something like this in python.

just my 2 ct

Re: Currying

#80

Post by solardev »

MarkSweep wrote: post #29
solardev wrote: post #14

Earlier quoted context omitted.

Yeah, a lot of the codebase was like that. Some lone wolf mad genius that occasionally left pieces of pure brilliance behind, but more often than not, just wrote code that was incredibly idiosyncratic and unnecessarily reinvented. Like he'd spend several files making a color gradient visualization system with his own scales, with an enthusiastic but limited understanding of color theory, that ended up producing mostl…

> But then again, he's a multi millionaire now and I'm a rando nobody living paycheck to paycheck, so I'm in no place to judge lol. If he had not made such a big mess, you might not be getting this paycheck to clean it up. I think they call this “creating scope for other people” at big companies, real staff engineer stuff. =)

Heh, exactly. Some of us are just software janitors for the bigwigs.
Post reply on HN