4 ms·

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

by fxj 3y ago

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://en.wikipedia.org/wiki/Tacit_programming https://medium.com/@jesterxl/real-world-uses-of-tacit-programming-part-1-of-2-f2a0c3f9e00c 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 https://wiki.haskell.org/Pointfree

boxed 3y ago
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.
- fxj 3y ago
  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<1")@rlµ<<χ)>>Σ*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
  - boxed 3y ago
    Sure, but why implicit? 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...
skybrian 3y ago
I think a lot of people would disagree that they make code more readable. These are all ways of removing the names of intermediate results. Some names are noise, but more often, they’re useful documentation. You can make code much shorter by removing all the application-specific names and only using very abstract, domain-independent names or symbols. The result can be seen in complicated regular expressions, array languages, bash scripts, and so on. In the wrong hands, these are all notoriously unreadable. But you can also go to the other extreme and give every little thing a very long name, and that’s less readable in its own way. Bob Nystrom wrote a nice article about how to combat that tendency. [1] Naming things is an art. In functional languages, let expressions are convenient and useful. When you feel like you don’t want to define another function, sometimes it’s better to resist that tendency and think about a better name. [1] https://journal.stuffwithstuff.com/2016/06/16/long-names-are-long/ https://journal.stuffwithstuff.com/2016/06/16/long-names-are...
- whateveracct 3y ago
  I read Haskell code structurally and don't pronounce symbols in my head. When it comes to names, the binding and lexical scope and position in the AST helps me read the code more than the English pronunciation. Tbh if I have a stream of English words in my head reading Haskell, it's probably already meh code at best :S I'd say I see more Haskell code made unreadable due to over-naming than under-naming in the wild (i.e. industry)

by fxj 3y ago

boxed 3y ago

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.

fxj 3y ago
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<1")@rlµ<<χ)>>Σ*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
- boxed 3y ago
  Sure, but why implicit? 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...

skybrian 3y ago

I think a lot of people would disagree that they make code more readable. These are all ways of removing the names of intermediate results. Some names are noise, but more often, they’re useful documentation. You can make code much shorter by removing all the application-specific names and only using very abstract, domain-independent names or symbols. The result can be seen in complicated regular expressions, array languages, bash scripts, and so on. In the wrong hands, these are all notoriously unreadable. But you can also go to the other extreme and give every little thing a very long name, and that’s less readable in its own way. Bob Nystrom wrote a nice article about how to combat that tendency. [1] Naming things is an art. In functional languages, let expressions are convenient and useful. When you feel like you don’t want to define another function, sometimes it’s better to resist that tendency and think about a better name. [1] https://journal.stuffwithstuff.com/2016/06/16/long-names-are-long/ https://journal.stuffwithstuff.com/2016/06/16/long-names-are...

whateveracct 3y ago
I read Haskell code structurally and don't pronounce symbols in my head. When it comes to names, the binding and lexical scope and position in the AST helps me read the code more than the English pronunciation. Tbh if I have a stream of English words in my head reading Haskell, it's probably already meh code at best :S I'd say I see more Haskell code made unreadable due to over-naming than under-naming in the wild (i.e. industry)