Haskell for JavaScript programmers 

me to

It's not really true about "no arrays", you could have it if your really need it (for performance-critical parts for instance), look at this package: hackage.haskell.org/package/array But how you work with this arrays differs from how you do it in imperative languages.

See also hackage.haskell.org/package/vector

@@johnnyphoney5669 Was asking this as a standalone comment. Array/Vector is much more efficient if you do non-iterative stuff. In fact, lists are even discouraged in haskell for anything but iteration. Length, index, elem, everything that does more than `head` is discouraged. www.imn.htwk-leipzig.de/~waldmann/etc/untutorial/list-or-not-list/

Also note there are a lot of purely functional datastructures and the following book is a good resource for them: www.cambridge.org/core/books/purely-functional-data-structures/0409255DA1B48FA731859AC72E34D494

is that make any sense that we're rejecting arrays, but allowing hashmaps a.k.a objects? because hashmaps are more complicated in their implementation, and usually based on arrays under the hood. and if array are not allowed, does that mean that standard JS map/filter/reduce are not pure?

@Gabriel Klenner well I can think of one you might have missed, vim is not Emacs.

Gabriel Klenner VS Code + HLS + HLINT, emacs is for sheeps

@@obinator9065 man, microsoft marketing is taking a bazaar route these days.

@いあ I'm so torn apart. Using vim for a couple or years now, but only "really" using it for a couple of months to program. I don't want this big emacs ship, also vims community is much bighger. But so many advantages when using emacs as an IDE...I don't know.

@@bratezoran2102 I'm not a pro, so take all this with a truckload of salt -- but neovim remedies some of vim's disadvantages as a IDE (& some of its features are 'backported', so to speak, into regular Vim via plugins). The upcoming 0.5.0 introduces a native LSP client & syntax engine; & the RPC interface makes it easily extensible, as it makes it trivial to communicate with whatever else over tcp or unix sockets.

If you watch his streams you'll learn he doesn't. He probably just speeds it up.

I don't really think strong typing is all that new of a concept to most programmers, so it's something glossed over compared to things like currying. And really given Haskell's generic patterns and typeclasses, the strong typing isn't really as big an issue as most would expect. And honestly while you can pass in a bunch of weird arguments of different types into a JS function, you probably shouldn't. It makes the code a lot harder to understand.

They're equivalent solutions... so probably his was the first one that came to his mind

@@DavidAguileraMoncusi One is more efficient than the other though.

@@jacobscrackers98 efficiency is clearly not a high priority in these examples (although of course Haskell does gain efficiency through pure functional laziness).

@@chromosundrift If it doesn't cost anything extra, one should go for the more efficient option imo

@@jacobscrackers98 Efficiency in Javascript wasn't the point. Lots of stuff he's doing like function currying are horribly inefficient in JS, but the idea was to understand Haskell better. Keep in mind that in haskell the compiler optimizes a lot of these things for you. So a lot of inefficient practices in JS aren't inefficient in Haskell, because Haskell is designed for that style of solution in mind.

Saaammeee

In functional programing else is mendatory, because expressions always have value. Ternary operator enforces this constraint in procedural language.

if is a statement and returns no value, so it cant be used

It's probably a bit late, but the Haskell "if ... then ... else ..." works like a ternary. The thing that's not allowed is just if ... then ..., because then there is no return value when the check fails.

forEach indeed does not exist, because in pure functional code it could not do anything; it returns undefined. The closest equivalent in Haskell is forM_ which operates within a monad as a way to model side effects. filter, on the other hand, is one of three core higher order operations on collections: map, filter, and reduce. Each of these produce a result, using some number of calls to a worker function they've been passed (mapping, predicate or reduction). Such higher order functions (often based on folds) usually replace loops, but recursion is the core mechanism. The core reason is that looping relies on side effects (something must be changing for the loop to complete). Without side effects, programs are easier to reason about and we can do things like evaluate multiple portions simultaneously.

It's different in that it forces each branch to produce a value, so all the logic is in the context of an expression. Basically, it works around having to remember to always include an else and two returns. Writing one language within another will tend to have awkward translations.

Yeah well, good luck designing the modern extremely complex UIs with those strict pure functional rules. Especially the avoiding side effects part.

@@Leonhart_93 thanks

@@Leonhart_93 thanks

Recursion is not more performant that straightforward iteration, it's the opposite. Firstly there is a call stack limit and if you reach it then the program crashes. Secondly, instead of a single CPU instruction like in a single iteration, an iteration using recursion also involves creating the function object.

@@Leonhart_93 yeah i know... Unless the language optimises tail call recursion, or you use recursive functions that isn't optimisable, it's quite limited in depth. But I meant using arrays in JavaScript is significantly faster than a homemade linked list would be. But I'm pretty sure the functional built in functional methods like map, filter etc. on the array objects are just as fast or faster than a for loop is in most js implementatons.

@@SteinGauslaaStrindhaug I do not think they are faster than low level loops. There is no imaginable reason why they would be faster than doing i++. Their purpose is to simplify working with arrays and stuff, for faster dev implementation, and not for more efficient runtime.