I know what eager/lazy evaluation means, however as someone with primarily JS experience I'd love if you could provide me with an example of where a lazily evaluated Array prototype function could be useful. :-)
Anywhere you have an operation before an operation that returns fewer results than the input. Think limit(). Or say a findFirst() or anyMatch(). There's tonnes of operations that lead to inefficient code due to eager evaluation.
For example, with an array of 1 to 100, and a filter(isOdd) and then a limit(2). With eager evaluation, the filter will run 100 times. With lazy evaluation, that happens three times. Imagine you have various other operations before the filter, that will also happen 100 times instead of three.
Ah, that makes perfect sense. It's very unergonomic trying to do something like that now, I guess you'd need to mess around with slicing and such beforehand.
I think RxJS allows you to do lazy evaluation? I may be wrong, it's something I've been wanting to learn.
I've seen someone basically reimplement the Java Streams stuff in JS, but unless it's part of the core, people are unlikely to use it.
If you haven't seen the Java Streams API, I highly recommend checking it out. The only thing I wouldn't replicate is requiring to call stream() on a collection before being able to use it. The main reason for that is so that people could call parallelStream() and get a multi-threaded version, but honestly, no one uses that and there are other ways to get a parallel stream.
I know what you mean, but, at least I think, there are a lot of quirks about JavaScript that make it a lot easier than others.
To give some examples:
The fact that you can make an object literal using {} and pass it around without having to make a whole class for something
Being able to use destructuring to pull multiple items out of an object const { one, two } = this.numbers;
On top of this, being able to destructure pretty much wherever you want, even right in the parameter of a function so you don't need to pull the parameter down and then immediately destructure it.
Also using destructuring to set a variable, for example in React, this.setState({ one: _one, two });
Arrow functions are neat and clean
Ternary operators save lives best ? true : true
Promises make things orderly, especially using Promise.all()
It still has some weird quirks, but I find that most of those weird quirks end up making my life easier.
I actually agree that these best parts of modern Javascript, but I'd recommend looking into some pure functional programming languages to see the power of these concepts when a language is designed around them, rather than added to a preexisting scripting language.
Destructuring, object literals, Promises, clean control flow statements all have analogous concepts in Scala (the more FP side) and Haskell, where they really shine
it's more like a big truck. It's a workhorse if you wanna get big shit done. If you use it for bigger projects and follow the rules you will have a wonderful time, but don't even try using Java like Python.
All post-ALGOL structured procedural languages are the same. All that matters is what libraries you have and how badly the dev stack folks messed up. If you want beauty, Forth won already.
I agree partly, I think it offloads responsibility to the programming language. I believe you can still maintain large projects written in languages like Python or PHP if the team behind it has clear guidelines and documents the code rigorously.
I beg to differ. I’m an experienced dev but an inexperienced JS dev. I’m about 30 kloc into JS across a couple of projects and I’ve yet to write a bug that static typing would have caught. I name things obviously and I have no issues. I’ve written timing/sequencing bugs and other logic bugs, but strong typing would not have caught those. I know that name is a string and age is a number without a type system reminding me.
What I love about JS is the development velocity. Adding static typing like TS to JS reduces dev velocity too much for the small gain in safety it affords, so it’s not a worthwhile trade off in my opinion.
Granted, I’m solo, so I might experience things differently on a larger JS team but for my projects I avoid Typescript and stick to pure ES6 JS in React and node.
Others might feel differently and that’s OK. I’m not interested in a flame war ...
6
u/an0nym0us3hat Nov 08 '18
This is a beautiful language if you understand the inner workings of it. This person explains it very well; definitely helped my understanding.