Hah, I'm tempted to go through the Ocaml 99 problems (which was inspired by the Prolog version) using ES6 [1]. Turns out, with recursion and a head and tail function, you can do virtually anything with lists.<p>I hope the popular JS engines optimize the hell out of the gathering operator, and adds TCO (it's on the ES6 spec, evidently). Then we won't even need to cross our fingers when we describe JS as a functional language to our peers.<p>And with the increasing emphasis on immutability, as preached by the React crowd, with cross seeding from the Clojurescript-React connections, JS grows even closer to being a Scheme [2].<p>If ES7 would lock down 'use strict' mode against even more of JS's weak-typing bloopers, things would be even better yet. I don't see why they shouldn't. They whole reason for 'use strict' is to give people who need backwards compatibility an out.<p>Incidentally, I'm also having great success using ES6 arrow functions at work, thanks to 6to5 [3]. I do a lot of d3 work, and arrow functions have made using d3, particularly the ubiquitous d3 accessor functions, so much nicer. Highly recommended.<p>For the first time since Node, I'm actually getting excited about Javascript's prospects. Now, if only they'd add types, and sum types...<p>1. <a href="http://ocaml.org/learn/tutorials/99problems.html" rel="nofollow">http://ocaml.org/learn/tutorials/99problems.html</a><p>2. No, I don't actually believe that JS is a Scheme in disguise.<p>3. <a href="https://github.com/6to5/6to5" rel="nofollow">https://github.com/6to5/6to5</a>
It's hard to believe this is javascript. I write that with a lot of love. These are some of my favorite language features but It's going to take some adjustment to be comfortable using and reading them in JS.
ES6 transpiling has been a bit of a revelation to me lately. Object destructuring is also exceedingly useful.<p>On a bit of a tangent from the article, I'm interested by the use of const as the default for variable declaration. My background is such that I've always considered constants as things that are class level constants (thank you Java), but reading up on Swift has made me rethink this.<p>Clearly const has the potential to reduce runtime errors. I'd appreciate it if anyone could recommend any further reading on the subject.
I've never liked this corner of JS, and haven't kept up on ES6 or any of the modern dialects of JS, but it looks like `undefined` is still hanging around as a first-class thing?<p><pre><code> const length = ([first, ...rest]) =>
first === undefined
? 0
: 1 + length(rest);
</code></pre>
Having worked in languages that support multiple (destructuring or not) function definitions, this doesn't look quite right.<p>Here's something I typed into chrome's JS console:<p><pre><code> > [1,2,3].length
3
> [undefined, 2, 3].length
3
</code></pre>
Wouldn't the above-defined ES6 `length` function return 0 for the latter array?<p>To mock up a similar syntax that would handle this more gracefully (and more sensically):<p><pre><code> const length = case
([]) => 0,
([first, ...rest]) => 1 + length(rest);
</code></pre>
Wouldn't it be better in general to be able to destructure arguments using syntax? If you can't use a case-like syntax for this, what do you do to be able to handle different structures?
I've been pondering a few style questions recently:<p><i>1. When to use 'function' vs '=>'?</i><p>Leaving aside hoisting and handling of 'this', 'function' and '=>' are usually interchangeable:<p><pre><code> function foo(x) {
// do something
}
let foo = x => {
// do something
}
</code></pre>
I prefer to keep using 'function' because it's immediately obvious to the reader that we are creating a function. With '=>', the reader doesn't know if foo is a function or not until reaching '=>', which is located after the argument list. There's also almost no terseness gain. A potential win for '=>' though would be the ability to declare the function as 'const'.<p>With closures, '=>' wins because the reader already expects a function, and the terseness gain is significant:<p><pre><code> somearray.map(function(x) {
// do something
});
somearray.map(x => {
// do something
});
</code></pre>
<i>2. When to use {} around the function body?</i><p><pre><code> somearray.forEach(x => /* a single statement */);
somearray.forEach(x => {/* a single statement */});
</code></pre>
{} around the function body are optional if there's only a single statement. However, for clarity, I still use {} when I want to make it clear that we are not using the return value. I think that might be overkill though: the reader should aready expect that 'map', 'filter' and friends will use the return value, while 'forEach' will not.<p><i>3. 'let' or 'const'?</i><p>This one is already mentioned in a sibling comment, so let's keep the discussion there.<p>I realize that these are tiny style decisions that will probably incite endless bikeshedding, but I'm still interested in hearing opinions from fellow HNers. :)
<p><pre><code> const description = (nameAndOccupation) => {
const [[first, last], occupation] = nameAndOccupation;
return `${first} is a ${occupation}`;
}
description([["Reginald", "Braithwaite"], "programmer"])
//=> "Reginald is a programmer"
</code></pre>
This is going to make code a <i>lot</i> more readable. I'm excited!
obligatory mention that 6to5[0] lets you use all this stuff, and more, today. I've been using it for 3 months now and it has totally transformed the way I write JS applications, it's awesome.<p>[0] <a href="https://6to5.org/" rel="nofollow">https://6to5.org/</a>
Also coming to ES6 is destructuring objects:<p><pre><code> function doSomething(aObj) {
let { x, y } = aObj;
}
doSomething({ x: 1, y: 4 })</code></pre>
So basically pattern matching, shorter syntax for lambdas, string manipulation à la Ruby (but with backquotes, why?) and… confusing list with array EVERYWHERE in the language?
No TCO? A `map` (sorry, `mapWith`) that creates then concatenates lists?<p>2015 sounds <i>amazing!</i>
Completely unrelated, but even assuming the author of the article posts here, are you from Columbus OH? I've gone to One-Line Coffee (the source of the first pic) myself a number of times!
Don't want to come off overly bitter, it's certainly interesting, but I'd like to see some practical uses of this, besides reimplementation of map() and other "low-level" functions...