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

Trine – A utility library for functional programming in JavaScript

github.com

Post reply on HN
Print view View original

31–40 of 116 posts

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

#31

Post by TazeTSchnitzel »

thomasfoster96 wrote: post #27

Perhaps what programmers of modern JavaScript should be doing is going back and revisiting things that have been considered harmful practices for quite a while. Some work in extending prototypes would make a huge difference to the readability of lots of code - yet everyone is told this is a bad practice because extending DOM elements is problematic and people are lazy when it comes to global namespace pollution. Real…

Extending prototypes seems like a great idea, until other code running in the same environment does it, and you realise why people stopped doing that.

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

#32

Post by quinnirill »

TazeTSchnitzel wrote: post #31
thomasfoster96 wrote: post #27

Perhaps what programmers of modern JavaScript should be doing is going back and revisiting things that have been considered harmful practices for quite a while. Some work in extending prototypes would make a huge difference to the readability of lots of code - yet everyone is told this is a bad practice because extending DOM elements is problematic and people are lazy when it comes to global namespace pollution. Real…

Extending prototypes seems like a great idea, until other code running in the same environment does it, and you realise why people stopped doing that.

And also because it has prevented the language itself from standardizing some features, e.g. String.prototype.contains had to be renamed to includes because shipping it as contains would have broken sites that use mootools.

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

#33

Post by the_mitsuhiko »

> They're both (subjectively) wrong: the natural place for data in JS is the this parameter.

... said the person not understanding the language semantics.

Passing arbitrary data as this is a terrible idea. It has to be an object and as such all primitives end up boxed.

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

#34

Post by brunoc »

quinnirill wrote: post #32
TazeTSchnitzel wrote: post #31

Earlier quoted context omitted.

Extending prototypes seems like a great idea, until other code running in the same environment does it, and you realise why people stopped doing that.

And also because it has prevented the language itself from standardizing some features, e.g. String.prototype.contains had to be renamed to includes because shipping it as contains would have broken sites that use mootools.

For those of you like me who spat their coffee reading this, you can find additional information about this anecdote here.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#35

Post by inglor »

the_mitsuhiko wrote: post #33

> They're both (subjectively) wrong: the natural place for data in JS is the this parameter. ... said the person not understanding the language semantics. Passing arbitrary data as this is a terrible idea. It has to be an object and as such all primitives end up boxed.

Not in strict mode... `(function(){ console.log(typeof this); })(5);` try in sloppy and strict mode - remember modules are strict mode by default.

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

#36

Post by [deleted] »

TazeTSchnitzel wrote: post #31
thomasfoster96 wrote: post #27

Perhaps what programmers of modern JavaScript should be doing is going back and revisiting things that have been considered harmful practices for quite a while. Some work in extending prototypes would make a huge difference to the readability of lots of code - yet everyone is told this is a bad practice because extending DOM elements is problematic and people are lazy when it comes to global namespace pollution. Real…

Extending prototypes seems like a great idea, until other code running in the same environment does it, and you realise why people stopped doing that.

[deleted]

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

#37

Post by mattdesl »

gabipurcaru wrote: post #16
milkworsethan wrote: post #12

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…

> You could technically use some FPLang-to-JS compiler, but those suck more often than not.

Features like the function bind syntax are only possible with Babel or another transpiler. It will likely be years before you can use them practically without a transpiler in the browser.

A lot of the new syntax/macros/APIs/etc should just be built as modules or Babel plugins rather than core language features. Just because [Syntax X] improves a couple of code snippets doesn't mean it needs to be shipped with the next version of JavaScript.

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

#38

Post by brunoc »

thomasfoster96 wrote: post #27

Perhaps what programmers of modern JavaScript should be doing is going back and revisiting things that have been considered harmful practices for quite a while. Some work in extending prototypes would make a huge difference to the readability of lots of code - yet everyone is told this is a bad practice because extending DOM elements is problematic and people are lazy when it comes to global namespace pollution. Real…

Another thing that may change this in the future is proxies and "method not found" type of functionality in JS.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

But if people are concerned about syntax mangling now, those features are going to make things 100 times crazier.

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

#39

Post by eueueu »

bshimmin wrote: post #24

About halfway through the README, after some examples of the new bind syntax, it says "But why stop there?" Actually, please can we stop here? Just for a bit? This continual, persistent mangling of JavaScript's syntax really is starting to hurt. It's one thing to have to keep on top of the new frameworks springing up every five minutes - which you can, for the most part, ignore for at least six months until they star…

This isn't the core language changing though. This is people who are new to javascript coming to it and deciding they all must write their "hello world" framework / extension.

Most of it is just superfluous fluff that doesn't actually do anything but change the syntax to something they perceive as fundamentally better, when it's just a matter of taste and fashion.

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

#40

Post by tracker1 »

This, and eval are probably the two largest points of JS where unintended mutations and consequences happen. Also, by overloading this (which is something I always hated in jQuery), you lose the ability to compose functions together, and/or use other types of currying and binding for event handling and/or processing.

IMHO it's usually something to be avoided, not championed...

Post reply on HN