GeZe

FYI, it would not be accurate to say that "The Flow people moved on to ReScript".

Another example would be the difference between their enum features: https://medium.com/flow-type/typescript-enums-vs-flow-enums-... "TypeScript Enums vs. Flow Enums"

Flow also supports "discriminated unions" [0], and did so before TypeScript (Flow's announcement in July 2015: https://flow.org/blog/2015/07/03/Disjoint-Unions/, TypeScript's announcement in August 2016: https://devblogs.microsoft.com/typescript/announcing-typescr...), though it doesn't yet support destructuring the "kind" field as was just added to TypeScript.

[0] https://flow.org/try/#0C4TwDgpgBAggxsAlgewHZQLwCgq6gHygG8oBr...

Here are the docs for exporting/importing enums: https://flow.org/en/docs/enums/using-enums/#toc-exporting-en... - works fine with the new export/import syntax.

Docs for enums compilation/runtime are here: https://flow.org/en/docs/enums/defining-enums/#toc-enums-at-...

You can similarly search/replace JS code, but using pattern matching and CSS style selectors instead of writing code, with Grasp. It's usable from the command line like sed.

http://www.graspjs.com/

For instance changing all calls to "calc" from taking two arguments to taking one object literal instead (eg. `calc(1, 2)` to `calc({from: 1, to: 2})`, is as easy as:

    $ grasp -r -e 'calc($a, $b)' -R 'calc({from: {{a}}, to: {{b}}})' file.js

(Where the two arguments to "calc" could be any arbitrary nested expressions, which could not be safely handled by a regular expression)

For a tool dedicated to searching and replacing JS in this way (AST aware), check out http://graspjs.com

You can use both CSS style selectors, and pattern matching, to both search and replace your code.

Self was one of the inspirations behind JavaScript, particularly its prototype system.

http://en.wikipedia.org/wiki/Self_(programming_language)

Looks like someone has started one: https://github.com/joneshf/sublime-grasp

Cool project! As monjaro mentions, the two examples are not equivalent however - the grasp example replaces every binary expression (alias: bi) with an addition operation with the right and left hand sides switched. This is a very trivial example, but hints at the great power available.

Grasp has two different query types, the default, squery - selector query, CSS style selectors, and equery (-e, --equery) - example query, JS code examples with wildcards.

In the grasp example above, we are using squery. jsgrep is similar to equery. You could do the following search in equery, and it would be more equivalent to the example you posted:

    f(__ < __, __ == __)

The only thing missing is the named wildcards for easy replace - that's a good idea and a feature to add to grasp 0.2.0!

You can check out the docs on squery (http://graspjs.com/docs/squery/) and equery (http://graspjs.com/docs/equery/)

I plan to add support for both LiveScript and CoffeeScript to grasp in the future.

PS. If anyone has any questions about grasp please let me know!

If you are looking for a syntax closer to Haskell's, you can take a look at LiveScript (http://livescript.net/)

eg.

    getUserFriends = (userName) ->
      user <- findUser userName
      friends <- findFriends user
      ...

Specifically, the section on "backcalls": http://livescript.net/#backcalls

More specifically, this has to do with the Big Mac Index by The Economist.

http://en.wikipedia.org/wiki/Big_Mac_Index

http://www.economist.com/content/big-mac-index

LiveScript allows partially applied operators, including property access. You can do:

    totals = map (.total), orders

http://livescript.net/

For those who don't want to wait for the book, I've written a brief article covering some concepts of functional programming in JavaScript: http://livescript.net/blog/functional-programming-in-javascr...

It covers first class and higher order functions, currying, partial application, composing functions, using operators as functions, comprehensions, and immutability.

This syntax already exists in LiveScript (http://livescript.net/#backcalls) which compiles to straightforward JS.

    a <- doFirstThing()
    b, c <- doSecondThing(a)
    doFinalThing(b + c)

The name is a joke, the project is not. "LiveScript was one of the original names for JavaScript, so it seemed fitting. It's an inside joke for those who know JavaScript well." (from the site)

LiveScript hasn't been used as a name for JavaScript in almost two decades.

Try learning Haskell. The concepts I discovered while learning it were very influential in my approach to other languages, even if I don't use Haskell itself all the time.

I would suggest http://learnyouahaskell.com/

LiveScript compiles almost 1 to 1 to JavaScript and has no runtime, making it easier to debug and comprehend for JavaScript programmers. You can access and use any JavaScript library without having to resort to a special syntax. For JavaScript programmers, it may be easier to use LiveScript. For Haskell programmers, it may be easier to use Fay.

I think many JavaScript programmers are looking for JavaScript (CoffeeScript) + functional programming rather than something purely functional as it allows them to use all that they've learned and mastered from JavaScript (often in an enhanced way) while using functional concepts as they learn them.

For those interested in functional programming, but with a desire for something a bit more pragmatic (and highly compatabile with CoffeeScript), you can check out LiveScript http://livescript.net

Functional Programming in JavaScript using LiveScript and prelude.ls: http://livescript.net/blog/functional-programming-in-javascr...

60 character solution in LiveScript[0], without using 'if's, also easily extensible!

[1 to 100]map(->[s for s,n of{Fizz:3,Buzz:5}|it%n<1]*''||it)

[0]http://gkz.github.com/LiveScript/

If they like Python, maybe they should have tried LiveScript (http://gkz.github.com/LiveScript/) - a descendent of CoffeeScript.

Unlike CoffeeScript, but like Python, it has proper list comprehensions `["#x#y" for x in [\a \b] for y in [1 2]]` which I think is very important to any Python fan, dict comprehensions, and (more minor) you can use `is not`, like in Python, instead of `isnt`. (Along with many other features.)

LiveScript has many features over CoffeeScript that may not exactly be as in Haskell, but are inspired by it. You can define curried functions, use partially applied operators (addTwo = (+ 2)), use operators as functions (sum = fold1 (+)), use infix functions, ("hi" `startsWith` 'h'), compose functions (h = f . g), have proper list comprehensions, and its standard library, prelude.ls, is based off of Haskell's Prelude module (inclusion is optional though if you want to use underscore.js or something else). For more information check out http://gkz.github.com/LiveScript/blog/functional-programming...

Part 1: http://gkz.github.com/LiveScript/blog/functional-programming...

Part 1 discussion on HN: http://news.ycombinator.com/item?id=4135616

If you are interested in this you might want to check out http://gkz.github.com/prelude-ls/ - it has almost all the functions included in Udon as well as about 60 more based off of Haskell's Prelude module.

This is an interesting idea - I will look into it. It does not seem to conflict with the current syntax. Thanks for the suggestion!

Hi Brian, thanks for creating Roy, it's very cool! I've underlined LiveScript functional features in this blog post, but like JavaScript, LiveScript also supports imperative and object-oriented programming. One could port a JavaScript program to LiveScript with relative ease, as it's just syntax changes (with features added on top). I do not think that would be possible in Roy. For some people that's fine, but for my own projects I would prefer using something that maps more closely to JavaScript.

Coco is amazing. To avoid becoming a "ghost town", I have made LiveScript much more compatible with CoffeeScript, easing transitions. I have invested time into making a decent website, and have now composed a couple of blog posts promoting LiveScript. Already several people have written projects in LiveScript: https://github.com/gkz/LiveScript/wiki/Projects-using-LiveSc... I hope with my continued efforts that the scenario you describe can be avoided.

Yes, I am aware - it is an interesting project. However, it's a couple of steps farther away from JavaScript than I would want to work with.

Yes, it's an inside joke for those who know JavaScript well.

For those who don't want to wait, most of the public-facing changes listed there are already in LiveScript (http://gkz.github.com/LiveScript/) - though with a few more (in my opinion well justified) incompatibilities.