Live data from Hacker News

Generalizing JSX: Delivering on the Dream of Curried Named Parameters

tolmasky.com

1–10 of 29 posts

Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters

#3

A certain portion of programmers seems convinced that currying offers a huge amount of power, and we just haven't unlocked it yet. But I don't think I understand why they feel that way.

It mostly allows you to write extremely short code.

E.g. `sumList = reduce(sum)`

It has a variety of drawbacks though, like being harder to inspect at runtime, and arguably harder to read.

Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters

#4
post #3

A certain portion of programmers seems convinced that currying offers a huge amount of power, and we just haven't unlocked it yet. But I don't think I understand why they feel that way.

It mostly allows you to write extremely short code. E.g. `sumList = reduce(sum)` It has a variety of drawbacks though, like being harder to inspect at runtime, and arguably harder to read.

Yup, couldn't agree more and that's exactly one of the concerns I'm trying to address in the blog post ("All in all, the resulting effect in my exprience is that currying makes writing code far more pleasurable, but often makes reading code somewhat confusing."). I think the combination of named parameters actually makes it more readable.

Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters

#6

"Dream of Curried Named Parameters" What dream, this is a daily reality in OCaml.

Yeah definitely an inspiration (and mentioned twice in the blog post). The main differences (unless I'm mistaken), are the parameter name mapping (which make it easy for differing APIs to interact well) and the idea of separating function application from argument binding, which allows for both re-currying (which actually unifies default parameters under curried parameters) and also for leaving fully-curried functions in a callable state.

Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters

#7
This is a good post with a lot of ideas to stew on.

I think my only criticism of the current approach in the linked GitHub repo [1] is the use of `eval`, as that could make it tough to utilize in low security/sandboxed environments such as mobile apps and CSP-controlled sites.

I'll save attempting an actual code exercise for later, but my first thought was maybe using JS implicit `this` to your advantage (even while trying to stray away from classes) and using `this[functionName]` to index into it. (You'd still have security concerns with `this` defaulting to `window` or `global`, but you'd avoid the need for `eval` and you can take advantage of the depth of abilities of constructor functions and ES2015 class syntax.)

[1] https://github.com/tolmasky/generic-jsx

Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters

#8

This is a good post with a lot of ideas to stew on. I think my only criticism of the current approach in the linked GitHub repo [1] is the use of `eval`, as that could make it tough to utilize in low security/sandboxed environments such as mobile apps and CSP-controlled sites. I'll save attempting an actual code exercise for later, but my first thought was maybe using JS implicit `this` to your advantage (even while…

Yeah the use of eval is purely to get it working today. The ideal would be to just change the JSX parser to place whatever is in the JSX tag directly. That would also give you arbitrary expressions:

    
    
 
If you look at the implementation in the repo, you'll see its actually a little more complex than just eval now (since JSX will pass the actual reference when the tag name starts with a capital letter), but again this was solely to provide something that people could use with their existing Babel implementations and a simple require.

Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters

#9
I think you mixed some nice ideas with a very weird idea for no good reason. I kept looking for why you want to do this through JSX, but I just didn't find anything convincing.

I like the idea of using the "from" function to rename applied parameters. But that and everything else would be equally possible and a lot less confusing if it didn't involve JSX, no?

Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters

#10

A certain portion of programmers seems convinced that currying offers a huge amount of power, and we just haven't unlocked it yet. But I don't think I understand why they feel that way.

it offers some elegance, here's a timeout function blogpost.

http://hyegar.com/2016/03/22/simple-timeouts/

In it the timeout function only takes one arg for its timeout wrapped function, so how do we use functions with more than 1 arg? Via currying

Post reply on HN