I hope that the authors have cleared the name with FrozenByte studios ...
Trine – A utility library for functional programming in JavaScript
71–80 of 116 posts
Re: Trine – A utility library for functional programming in JavaScript
#72Earlier quoted context omitted.
I disagree. I think that extending and improving a language is good, and it's certainly not a Javascript-only phenomenon. Off the top of my head, other languages that are considering and implementing syntax extensions include Python (e.g. "yield from"), C# (e.g. "async/await"), and Java (lambda expressions). I actually think that it's pretty low to accuse ECMAScript of "mangling" JS syntax when they are just trying t…
My objections are around the rate of change and the fact that JavaScript is growing into a large, complex language that people are becoming really uncertain how to use.
I could see how that's a legitimate concern, it reminds me of some of the complaints I hear about C++ having too many features (I don't use C++, so this is just hearsay). But Javascript is still a much smaller and simpler language than almost anything else out there. Sure, it has some semantic quirks, but the syntax is fundamentally minimal. I think it will be a long time yet before we reach the point of being really overcomplicated.
I think the uncertainty around Javascript (and I do agree that there seems to be a real sense of confusion in the community when you look at the explosion of libraries and frameworks) is more related to the fact that we are trying to solve hard problems in a language that really gives us no help. We get no type checking, no good concurrency APIs, no immutability, no good sequence abstractions until iterators, just a fairly low-level and extremely hackable language with an unusual prototypal inheritance system.
Well, who knows. I would personally like to see some more stuff be standardized in the language or the official APIs so we don't end up with four competing libraries implementing "map" and "reduce", or promises, or whatever other thing.
Re: Trine – A utility library for functional programming in JavaScript
#73Earlier quoted context omitted.
I disagree. I think that extending and improving a language is good, and it's certainly not a Javascript-only phenomenon. Off the top of my head, other languages that are considering and implementing syntax extensions include Python (e.g. "yield from"), C# (e.g. "async/await"), and Java (lambda expressions). I actually think that it's pretty low to accuse ECMAScript of "mangling" JS syntax when they are just trying t…
You have a point but you mention C#, it's worth thinking of how you'd handle one of the examples in C#: items .filter(isOk) .map(toOtherType) ::flatten() In C# that sort of case is primarily handled by extension methods. They have their issues not least in terms of collisions, but to me they are a beautiful solution. The equivalent in JS would seem to be the always unpopular choice of adding these methods to the prot…
I think extension methods in C# are basically a way to work around the fact that you can't just stick a method on the prototype like you can in Javascript. I also like the C# solution, actually, I just love C#. It's a great "daily driver" language in my book.
If you took the function bind syntax to its natural extreme, you end up with a model like Python or Nim, where all instance methods accept their "this" as a first parameter, and "a.call(b)" is equivalent to "call(a, b)". Personally I always thought that was a particularly elegant way of implementing instance methods, because it doesn't require inheritance or modifying the original type.
In Nim it even lets you do some very interesting method chaining to replace nested calls, like "toInt(sqrt(toFloat(num)))" can be equivalently written "num.toFloat.sqrt.toInt"
Re: Trine – A utility library for functional programming in JavaScript
#74About 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…
I was almost afraid no one else thought this way. This just makes JavaScript illegible, and adds a negligible number of new features. The only JS I'm ever going to write is ES5, at this point, because the difference between function Person(){ this.age = 0; setInterval(() => { this.age++; }, 1000); } and function Person(){ this.age = 0; var my = this; setInterval(function(){ my.age++; }, 1000); } are barely visible, b…
Do you know that the arrow function was the main reason that I made the switch from Chrome to FF Dev as my primary web browser and I never looked back?
You don't know how much you're missing here. I wish that ECMAScript* considers adding support for "indented syntax" like in Sass to make it even more easier to read and go through the codebase without seeing all these ugly braces around.
*: or a white knight programmer volunteering to offer this functionality for us all :)
Re: Trine – A utility library for functional programming in JavaScript
#75About 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.
I'm not sure it's purely a matter of taste and fashion.
Let's say I make a new language called javascript++.
Instead of having `function` be a keyword, I chose `functioooooooooooooooooooooooooooon`. Based on their syntaxes, do you find one fundamentally better?
Re: Trine – A utility library for functional programming in JavaScript
#76(Disclosure: one of the authors of Ramda here, so I may well be biased toward a very different approach.) This is an interesting approach, but I get caught right at the beginning, where you say "What you'd really want to do is this: items .filter(isOk) .map(toOtherType) .flatten() But what I really want to do is build a reusable function: var process = seq(filter(isOk), map(toOtherType), flatten); So I can at my leis…
Seems like you could just do var process = items => items.filter(isOk).map(toOtherType).flatten()
The difference starts to show when you want to partially apply some values.
// process1 :: (Item -> Bool) -> [Item] -> [OtherType]
// process2 :: [Item] -> [OtherType]
process1(isOk, items); //=> [otherType1, otherType2, ...]
process2(items); //=> [otherType1, otherType2, ...]
var processR1 = seq(filter, map(toOtherType), flatten);
var processR2 = processR1(isOk);
var processT1 = (isOk, items) => items.filter(isOk).map(toOtherType).flatten()
var processT2 = items => processT1(isOk, items)
Re: Trine – A utility library for functional programming in JavaScript
#77Earlier quoted context omitted.
I was almost afraid no one else thought this way. This just makes JavaScript illegible, and adds a negligible number of new features. The only JS I'm ever going to write is ES5, at this point, because the difference between function Person(){ this.age = 0; setInterval(() => { this.age++; }, 1000); } and function Person(){ this.age = 0; var my = this; setInterval(function(){ my.age++; }, 1000); } are barely visible, b…
Do you know that the arrow function was the main reason that I made the switch from Chrome to FF Dev as my primary web browser and I never looked back? You don't know how much you're missing here. I wish that ECMAScript* considers adding support for "indented syntax" like in Sass to make it even more easier to read and go through the codebase without seeing all these ugly braces around. *: or a white knight programme…
That's CoffeeScript right there for you.
Re: Trine – A utility library for functional programming in JavaScript
#78Earlier quoted context omitted.
Do you know that the arrow function was the main reason that I made the switch from Chrome to FF Dev as my primary web browser and I never looked back? You don't know how much you're missing here. I wish that ECMAScript* considers adding support for "indented syntax" like in Sass to make it even more easier to read and go through the codebase without seeing all these ugly braces around. *: or a white knight programme…
That's CoffeeScript right there for you.
I'm familiar with CoffeeScript but AFAIK it's a distinct language probably a dialect of JS.
I just want the indentation without all the baggage that comes along with CoffeeScript.
Re: Trine – A utility library for functional programming in JavaScript
#79It seems to me like everybody wants a framework in every language that allows them to write it like a language they're more comfortable with. I would much prefer to see the evolution of FFIs, and things like that, than just writing a DSL that's more or less just sugar. Let's embrace the native strengths of languages, and allow ourselves to use more languages together.
Re: Trine – A utility library for functional programming in JavaScript
#80Earlier quoted context omitted.
I disagree. I think that extending and improving a language is good, and it's certainly not a Javascript-only phenomenon. Off the top of my head, other languages that are considering and implementing syntax extensions include Python (e.g. "yield from"), C# (e.g. "async/await"), and Java (lambda expressions). I actually think that it's pretty low to accuse ECMAScript of "mangling" JS syntax when they are just trying t…
My objections are around the rate of change and the fact that JavaScript is growing into a large, complex language that people are becoming really uncertain how to use.
JavaScript has always been a language people were uncertain how to use.
The only difference with ES6+ is that the uncertainty will come from the addition of features people have complained were missing, instead of the traditional uncertainty that came from the intersection of its flexibility and dev's desire not to learn it.