4 ms·

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 fu

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. 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. 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]. 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. 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. 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... 1. http://ocaml.org/learn/tutorials/99problems.html http://ocaml.org/learn/tutorials/99problems.html 2. No, I don't actually believe that JS is a Scheme in disguise. 3. https://github.com/6to5/6to5 https://github.com/6to5/6to5

gsnedders 12y ago
> 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. Why we shouldn't? Because we (as in browser vendors) can't just break compatibility with all the websites that use strict mode today — that's a bad (/bad/) experience for our users, to have something they used every day in version x of our browser not work in version x+1. The "use strict" pragma won't ever be used for anything more than the ES5 strictness, and there's an increasing unwillingness to introduce further mode-switches. But never is a long time, and I think many of us would like to see something like TypeScript integrated into the language, and possibly introduce a strictly typed mode.
- eric_bullington 12y ago
  > Why we shouldn't? Because we (as in browser vendors) can't just break compatibility with all the websites that use strict mode today OK, fair enough. That was admittedly a glib comment on my part. However, if JS ever wants to be more than a compilation/transpilation target in the long run, it will need to face this challenge and come up with a solution. Static typing is a definite solution, but I'm skeptical that this will happen in ES7 (or perhaps I just don't want to get my hopes up).
  - gsnedders 12y ago
    Some form of gradual typing is almost certain to reach ES eventually. I don't think anyone is really against it. Whether that goes far enough to make everyone happy… well, it probably won't. But I'm somewhat hopeful about all the research being done around gradual typing, and around TypeScript by MSR in particular that we'll end up with something truly useful and that solves 99% of the use-cases.
djtriptych 12y ago
Any links to your work with arrow functions and d3?
- eric_bullington 12y ago
  I've only started using ES6 in anger over the past few weeks, so I don't have anything public at this time. However, if you're familiar with d3 at all, then you know this pattern well: someSelection .attr("r", function(d, i) { return i * 20; }) Well, with ES6, this becomes so much nicer to write: someSelection .attr('r', (d, i) => i * 20) Nothing earth-shattering, but when you're writing dozens of these accessor functions in each function, it makes d3 much easier to work with.
acjohnson55 12y ago
While I think the whole pattern matching + recursion thing is important to understand, once it's understood, I think it's usually better to move on to combinators like fold/reduce/map/flatmap and such. Plus Javascript still lacks the ability to branch on a pattern match.
- JadeNB 12y ago
  > While I think the whole pattern matching + recursion thing is important to understand, once it's understood, I think it's usually better to move on to combinators like fold Of course, `fold` is just another language for expressing pattern-matching and well founded recursion, right? (Maybe I've got my theory mixed up, but do notice that I snuck the word "well founded" in there.) Then, of course, the other combinators that you mention (`reduce` / `map` / `flatmap`) are all just folds. On the other hand, this shouldn't be taken as a refutation of your argument; recognising and making prettier / more lightweight / even just more visible a common pattern is valuable, even if it does not, strictly speaking, increase computational power.
  - acjohnson55 12y ago
    Yep, going from arbitrary recursion to `fold` to `reduce` to `flatMap` to `map`, you're actually discarding power and expressiveness. But the good news is that you're exchanging raw expressiveness for a tool that fits the job at hand more precisely.
- eric_bullington 12y ago
  I agree that they're not terribly practical ways to program (I wouldn't use them in production). Still fun to play with.

gsnedders 12y ago

> 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. Why we shouldn't? Because we (as in browser vendors) can't just break compatibility with all the websites that use strict mode today — that's a bad (/bad/) experience for our users, to have something they used every day in version x of our browser not work in version x+1. The "use strict" pragma won't ever be used for anything more than the ES5 strictness, and there's an increasing unwillingness to introduce further mode-switches. But never is a long time, and I think many of us would like to see something like TypeScript integrated into the language, and possibly introduce a strictly typed mode.

eric_bullington 12y ago
> Why we shouldn't? Because we (as in browser vendors) can't just break compatibility with all the websites that use strict mode today OK, fair enough. That was admittedly a glib comment on my part. However, if JS ever wants to be more than a compilation/transpilation target in the long run, it will need to face this challenge and come up with a solution. Static typing is a definite solution, but I'm skeptical that this will happen in ES7 (or perhaps I just don't want to get my hopes up).
- gsnedders 12y ago
  Some form of gradual typing is almost certain to reach ES eventually. I don't think anyone is really against it. Whether that goes far enough to make everyone happy… well, it probably won't. But I'm somewhat hopeful about all the research being done around gradual typing, and around TypeScript by MSR in particular that we'll end up with something truly useful and that solves 99% of the use-cases.

djtriptych 12y ago

Any links to your work with arrow functions and d3?

eric_bullington 12y ago
I've only started using ES6 in anger over the past few weeks, so I don't have anything public at this time. However, if you're familiar with d3 at all, then you know this pattern well: someSelection .attr("r", function(d, i) { return i * 20; }) Well, with ES6, this becomes so much nicer to write: someSelection .attr('r', (d, i) => i * 20) Nothing earth-shattering, but when you're writing dozens of these accessor functions in each function, it makes d3 much easier to work with.

acjohnson55 12y ago

While I think the whole pattern matching + recursion thing is important to understand, once it's understood, I think it's usually better to move on to combinators like fold/reduce/map/flatmap and such. Plus Javascript still lacks the ability to branch on a pattern match.

JadeNB 12y ago
> While I think the whole pattern matching + recursion thing is important to understand, once it's understood, I think it's usually better to move on to combinators like fold Of course, `fold` is just another language for expressing pattern-matching and well founded recursion, right? (Maybe I've got my theory mixed up, but do notice that I snuck the word "well founded" in there.) Then, of course, the other combinators that you mention (`reduce` / `map` / `flatmap`) are all just folds. On the other hand, this shouldn't be taken as a refutation of your argument; recognising and making prettier / more lightweight / even just more visible a common pattern is valuable, even if it does not, strictly speaking, increase computational power.
- acjohnson55 12y ago
  Yep, going from arbitrary recursion to `fold` to `reduce` to `flatMap` to `map`, you're actually discarding power and expressiveness. But the good news is that you're exchanging raw expressiveness for a tool that fits the job at hand more precisely.
eric_bullington 12y ago
I agree that they're not terribly practical ways to program (I wouldn't use them in production). Still fun to play with.