When you pass some arguments to a constructor and then later, you pass some more arguments to a method, that’s equivalent to currying.
Method calls are easier to read and work better with autocomplete.
Currying
11–20 of 134 posts
Re: Currying
#12In 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…
Function arguments work like the power rule for exponents in elementary school math:
f a b = g(a,b) = f' b a
(x^2)^3 = x^(2*3) = (x^3)^2Re: Currying
#13In 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…
Was the codebase in strict Typescript? I find currying to be sometimes useful in the right language / paradigm, as long as you can rely on the compiler to yell at you until you get it right.
Dynamically typed functional retrofit on with no type checking though? Hell no, that's a write-once read-never mess of unmaintainable shite.
(I also have been on a team with The Guy Who Wanted To Ramda, and I'm someone who writes build scripts in ocaml)
Re: Currying
#14Earlier quoted context omitted.
Ramda, lodash, no idea what currying is, ... Software is in good hands.
Almost as if an astronaut can come, do their thing in a whirlwind and leave for another company 2 years later, while the remaining plebs have to figure it all out.
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 mostly reasonable but occasionally insane color scales. We spent several days of back and forth discussions with him before understanding what he was actually trying to do (which isn't what his code was actually doing) and then replaced it with a one liner out of a standard visualization/color lib.
The entire codebase was like that. It stood out to me as the work of someone who was very smart but worked alone and never had to work with a team, and never considered what someone trying to retrace his mental process would have to go through. He left zero documentation or comments, built the whole thing in a rush, sold it to another company, and we were the ones hired later to clean up his mess.
Some of it was very good. He was really good at efficiently encoding low level network traffic over packet encodings he invented or heavily modified. Seemed like he would've been a brilliant signals engineer or cryptologist. But having to work with his ordinary business logic code was pretty nightmarish, if interesting from a reverse engineering and psychology point of view.
It's just not how I would ever want to write code meant for mere mortals. 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.
Re: Currying
#15In 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…
Function arguments work like the power rule for exponents in elementary school math: f a b = g(a,b) = f' b a (x^2)^3 = x^(2*3) = (x^3)^2
You must've gone to a pretty kick ass elementary school. In mine, we'd play Connect Four and make paintings out of fake hieroglyphs...
Re: Currying
#16Earlier quoted context omitted.
Function arguments work like the power rule for exponents in elementary school math: f a b = g(a,b) = f' b a (x^2)^3 = x^(2*3) = (x^3)^2
You must've gone to a pretty kick ass elementary school. In mine, we'd play Connect Four and make paintings out of fake hieroglyphs...
I'm fortunate my parents didn't stick with free-to-play, but were willing to spend 5-6 digits more to buy a house in the "good" school district: https://news.ycombinator.com/item?id=39946026
Re: Currying
#17I always thought currying was a bad idea. It makes the code way less readable: * more difficult to distinguish arguments and return values (there's a reason most languages have distinct syntax for them) * it encourages you to put your arguments in an order that might not be the most logical And on top of that it only works for the last argument(s). Feels like a lot of disadvantages to allow an overly clever trick tha…
> using lambda functions
or (where available) sections
Re: Currying
#18In 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…
Was the codebase in strict Typescript? I find currying to be sometimes useful in the right language / paradigm, as long as you can rely on the compiler to yell at you until you get it right. Dynamically typed functional retrofit on with no type checking though? Hell no, that's a write-once read-never mess of unmaintainable shite. (I also have been on a team with The Guy Who Wanted To Ramda, and I'm someone who writes…
It was a mishmash. The parts written by later employees were strongly typed and easy to follow. The parts he wrote weren't typed at all and frequently relied on implicit conversions and bitwise operators to do magic operations that would take us mere mortals several days to even begin to understand, all just to save what would've been like 3 lines of code and a single comment.
Inheriting that codebase felt like watching one of those serial killer dramas... obviously a really smart guy, but with a psychology unlike most people I've ever met, and really hard to follow as a normal person. I still see him with a mixture of respect, awe, curiosity, and wonder.
The thing is, none of the stuff he gave is was actually complicated. It's just a basic business dashboard. But he reinvented almost every single part of it in totally nonstandard ways that the whole project was less about coding and more about anthropology and forensic psychology.
Re: Currying
#19[flagged]
Re: Currying
#20Earlier quoted context omitted.
Was the codebase in strict Typescript? I find currying to be sometimes useful in the right language / paradigm, as long as you can rely on the compiler to yell at you until you get it right. Dynamically typed functional retrofit on with no type checking though? Hell no, that's a write-once read-never mess of unmaintainable shite. (I also have been on a team with The Guy Who Wanted To Ramda, and I'm someone who writes…
It was a mishmash. The parts written by later employees were strongly typed and easy to follow. The parts he wrote weren't typed at all and frequently relied on implicit conversions and bitwise operators to do magic operations that would take us mere mortals several days to even begin to understand, all just to save what would've been like 3 lines of code and a single comment. Inheriting that codebase felt like watch…
CSI: Code Shite Investigation