Live data from Hacker News

Trine – A utility library for functional programming in JavaScript

github.com

11–20 of 116 posts

Re: Trine – A utility library for functional programming in JavaScript

#11

Looks interesting, especially in concert with the proposed bind syntax. Fortunately, that syntax is in Babel now, so we can play with these ideas straight away. That being said, the readme did not address why Ramda uses the data as the last parameter and not as `this`: To facilitate partial application.

Ramda actually uses data as the last parameter usually, whereas lodash has it as the first. However, I agree, the readme doesn't quite show the full power of Trine. Trine has `partial`, which allows you to do partial application as so: `parseInt::partial(_)`, that would create a function that acts as parseInt but only takes one argument. This is in sync with the partial application syntax proposal: https://gist.githu…

May I ask what do you mean by "single arrow function"?

Do you mean thin arrow fn(s)?

Re: Trine – A utility library for functional programming in JavaScript

#13
post #11

Earlier quoted context omitted.

Ramda actually uses data as the last parameter usually, whereas lodash has it as the first. However, I agree, the readme doesn't quite show the full power of Trine. Trine has `partial`, which allows you to do partial application as so: `parseInt::partial(_)`, that would create a function that acts as parseInt but only takes one argument. This is in sync with the partial application syntax proposal: https://gist.githu…

May I ask what do you mean by "single arrow function"? Do you mean thin arrow fn(s)?

Yes, sorry, thin arrow, not single - `() -> this.foo()` for function expressions and possibly even `let/const fn () -> this.foo()` for declarations.

Re: Trine – A utility library for functional programming in JavaScript

#15
post #11

Earlier quoted context omitted.

May I ask what do you mean by "single arrow function"? Do you mean thin arrow fn(s)?

Yes, sorry, thin arrow, not single - `() -> this.foo()` for function expressions and possibly even `let/const fn () -> this.foo()` for declarations.

Excuse my ignorance but I only have experience in JS and not any other "advanced" or well-established programming langs, how's thin arrow syntax gonna fix this prob that fat arrow can't?

Re: Trine – A utility library for functional programming in JavaScript

#16

You could always use FP languages for FP and leave JS be...

Well you can't really. If you want to write frontend apps, for example, you have to use JS. You could technically use some FPLang-to-JS compiler, but those suck more often than not.

Also, I don't see how "let's not make a thing better just because it was not meant to work this way" is an argument.

I'm sure there is a fallacy name for this, but consider some other examples: "You could always use fridges for cooling and let cars be" or "You could always use computers for browsing the internet and leave phones be".

Re: Trine – A utility library for functional programming in JavaScript

#17
post #15

Earlier quoted context omitted.

Yes, sorry, thin arrow, not single - `() -> this.foo()` for function expressions and possibly even `let/const fn () -> this.foo()` for declarations.

Excuse my ignorance but I only have experience in JS and not any other "advanced" or well-established programming langs, how's thin arrow syntax gonna fix this prob that fat arrow can't?

Fat arrow functions have lexical this: this inside the function is bound to what it was outside. Thin arrow functions have a dynamic this, determined by how they are called. Because the library relies on dynamic this as the place where the data is sent, fat arrow syntax isn't useful with it.

Re: Trine – A utility library for functional programming in JavaScript

#18

You could always use FP languages for FP and leave JS be...

Well you can't really. If you want to write frontend apps, for example, you have to use JS. You could technically use some FPLang-to-JS compiler, but those suck more often than not. Also, I don't see how "let's not make a thing better just because it was not meant to work this way" is an argument. I'm sure there is a fallacy name for this, but consider some other examples: "You could always use fridges for cooling an…

I'm using on my day to day ClojureScript and have, till now, 0 technical issue. Is this the perfect platform ? Hell no, it can be annoying to set, and interop can be annoying (mostly due to the fact that the world of side effect is still there, lurking and come at odds to my immutable language). The upside is that it works. For me it's a relief to use a FP compare to OO, some would prefer a logic (prolog) approach, or else - and again, we can, right now and it's no harder than using grunt, bower or any of the other tool that have appeared recently.

Re: Trine – A utility library for functional programming in JavaScript

#19

Earlier quoted context omitted.

What's stopping you from doing that, exactly?

He's probably having issues with async gubbins. Some sort of 'rewind time' in the debugger so you could determine what happened when to get to this state of error.

I also want to be able to run javascript (and the rest of the browser) deterministically in a test environment, and run tests, each with different timing characteristics.

Of course, I want to run my server in the same way.

So perhaps this is better done inside some "deterministic virtual machine", where the browser and server are run deterministically hand-in-hand.

Re: Trine – A utility library for functional programming in JavaScript

#20

Earlier quoted context omitted.

What's stopping you from doing that, exactly?

He's probably having issues with async gubbins. Some sort of 'rewind time' in the debugger so you could determine what happened when to get to this state of error.

The best vendor-neutral term for rewinding time in a debugger is probably "historical debugging" or "reverse debugging".
Post reply on HN