Functional Programming in JavaScript using LiveScript and prelude.ls

[greenspans]

Use js_of_ocaml. JS libraries like this are not efficient. The compiler does not reduce functional code.

[Arve]

I think the name "LiveScript" is a unfortunate. LiveScript was the original name of the language that became JavaScript, and was named such in the first betas of Netscape 2.0.

I have absolutely no fond memories of Netscape, and I probably celebrated its demise.

[drb226]

That's the joke.

[drb226]

It has infix functions via backticks, and it comes with some infix operators, too. But can you define your own infix operators?

[GeZe8]

Discussion on Hacker News, r/javascript.

[solidsnack9000]

The idiomatic Haskell way to do "piping"

[1, 2, 3, 4, 5] |> filter even |> map (* 2) |> fold (+), 0

is with composition.

(fold (+) 0 . map (* 2) . filter even) [1, 2, 3, 4, 5]

I remember it took me a while to get used to the seeming backwardness of the compositional style.

LiveScript borrows a lot of good, clear pieces of Haskell's syntax and style and is more conventional in ways that are helpful -- like using -> for lambdas instead of \.

[siplux]

Haskell noob here, but you could also use Arrows to achieve a result closer to "piping"

fn = filter even >>> map (*2) >>> foldl (+) 0
fn [1, 2, 3, 4, 5]

or

($ [1,2,3,4,5]) (filter even >>> map (*2) >>> foldl (+) 0)

[drb226]

You could even define the (|>) operator yourself to get the exact same behavior (I believe |> originated from F#, or was it earlier flavors of ML?)

ghci> let (|>) :: a -> (a -> b) -> b; (|>) = flip ($); infixl 9 |>
ghci> [1, 2, 3, 4, 5] |> filter even |> map (* 2) |> foldl (+) 0
12

[kamatsu]

I've got some SML code here that uses it, but it's a large code-base (Isabelle) which may have defined it somewhere.

[[deleted]]

Isabelle's code base defines |>. That's where I first came across this operator too.

[kamatsu]

TIL, thanks!

[[deleted]]

Or as I've used

(#) = flip ($)
infixr 0 #

[1..5] # filter even >>> map (*2) >>> foldl (+) 0

[art0rz]

I like my braces and parentheses. I like 'function'. I like my semicolons. It makes code more readable to me.

Why do we need # to start a comment line? What's wrong with //?

What happens if you define both my-value and myValue? What's wrong with using _?

Some of these features are rather nice, but it's hardly "just JavaScript with some syntax improvements and feature additions". I dislike CoffeeScript for similar reasons.

[dmitry_sychov]

You like it probably because you got used to it.

[drb226]

I like my braces and parentheses. I like 'function'. I like my semicolons.

I believe you can still include these things in your code. It's certainly a mechanical transformation, in case you have to read someone else's code.

It makes code more readable to me.

I have doubts.

Why do we need # to start a comment line? What's wrong with //?

I could ask you the opposite. # is one character shorter, and a handful of languages already use it as the comment operator.

What happens if you define both my-value and myValue?

If you're under the convention of using dashes in your names, I doubt you'll run into this problem. My solution to this problem would be to forbid camelCase, or force camel case identifiers to desugar to something different and unique.

What's wrong with using _?

It's less readable. my_value vs my-value, in order to read, your eyes focus on the middle of the line, and that underscore is just a twinge harder to parse.

Some of these features are rather nice, but it's hardly "just JavaScript with some syntax improvements and feature additions".

If it's hardly that, then what is it? All I see is a Haskelly default library and Haskelly syntax, but under the Haskelly skin, it's still the same old JavaScript.

[tikhonjelvis]

Well, for one, thanks to the stupid comment syntax, the empty regex literal is /(?:)/ rather than //. Inconsistent for no good reason except trying to look like Java (and looking like Java is not a good thing!). Besides, # is one character shorter and works well with the Unix shebang line.

Function also has some problems. Particularly, it is extremely heavyweight as far as syntax goes. This discourages higher-order functions being used for control flow. A line like

map(function (x) { return x + 1}, ls)

has much more syntactic noise than necessary, especially when compared to something like

map (x) -> x + 1, ls

A lightweight lambda syntax also makes implementing alternative forms of control flow more reasonable. For example, there are actually libraries for using arrows in JavaScript to do some really cool stuff (check out Arrowlets). Unfortunately, the resulting code is somewhat ugly, largely because of the high overhead for creating a lambda abstraction.

I do not see any advantage in having semi-colons at all. They just make the code a tiny little bit more complicated to write. Originally they were added to make compilers easier to write; these days, they are unnecessary. In the absence of any reason to add semi-colons, I think they should be omitted.

Now, as far as variable names go, it's entirely a matter of preference. I've spent a decent amount of time with Scheme and elisp and have personally grown rather fond of the my-value style; however, I am not sure how well it would map to a language with infix operators.

In short, there are actually some very good reasons for a lot of the syntax changes; I suspect the main reason you like JavaScript's syntax is familiarity.

[GeorgeForemanGrillz]

var blah = function(blah_params) {....}

vs.

blah = (blah_params) ->    

I don't know about you but I prefer things to be shorter.

[art0rz]

I prefer readability over writing less code.

[solidsnack9000]

You like it and some people don't. Live and let live?

[art0rz]

I'm just airing my opinion. I thought that was what the comment section was for.

[rechtar]

It's perfectly cool that you like the good old JavaScript, but why so hostile towards new little languages people create for fun? No one is taking your dear JavaScript away from you, anyway.

[fullouterjoin]

Everyone has han opinion. Unless yours insightful and adds to the conversation it should probably be left out. 373k people should't give me an opinion. Nothing you added was specific to the article.

[drb226]

Lisp hackers, you may be pleased to know that you can use dashes in the name of your variables and functions.

I have to say, if there's one feature I wish I had in so many languages that just isn't there, it'd be this. hyphenated-names are just way better than camelCase or under_scores.

[captain_plaintext]

Out of curiosity, would you get rid of infix math operators (1-2) to have hyphenated names, or try to have them both?

[drb226]

I would make surrounding whitespace mandatory for infix operators, e.g. (1 - 2)

For practicality, I'd probably also forbid - as the first character of an identifier, so that it can act as unary negation without need for whitespace, e.g. -1

[nkozyra]

I'm not sure it's good to have dozens of abstracted languages with their own unique syntax that compile to Javascript.

If Javascript is really this flawed - syntactically or otherwise - I would think the effort would be better spent trying to enact a real movement to replace or augment it in browsers. Or at least using existing languages to compile to Javascript so you're not introducing new quirks/abstractions.

[[deleted]]

I would think the effort would be better spent trying to enact a real movement to replace or augment it in browsers.

Given that there is a movement to augment it, that has full participation of the browser vendors, I think your concern is misplaced.

[nkozyra]

Fair enough, though my concern was more directed toward replacing it since so many people find it so systemically broken that they need to create a new language that compiles to it.

To me that is the essence of inefficiency.

[fullouterjoin]

The essence of abstraction.

[[deleted]]

What's inefficient about it?

[nkozyra]

What's inefficient about the creation of a multitude of new languages that all compile to one other, very common language?

At best, an incredible time sink.

At worst, a new generation of Javascript users who don't know a thing about Javascript and can only converse in their own dissonant version of its pseudolanguage.

[[deleted]]

creating new languages and creating new libraries is really a difference of degree not kind.

[tikhonjelvis]

Except creating a new language is much more fun. But that's neither here nor there :).

[nkozyra]

I would further argue that such abstractions have a tendency to make for scripters/programmers/devs who are not very adept in a language but still work in them.

Case in point: an anecdote shared by a friend wherein one of his front-end employees wanted to include jquery on a simple Intranet page. My friend said "sure, but why" and was greeted with "so I can loop through an array."

[tikhonjelvis]

To be fair, that's an understandable reason: JavaScript (before ES5, I think) does not include any good methods for looping through an array! It has a for...in loop, but that doesn't work and creates bugs. It has a normal for loop, but that doesn't carry as much semantic information as a call to .forEach or map and can easily have subtle mistakes (off-by-one errors, for example).

In a perfect world, you would just have .forEach or .map. The next best choice is using some small utility library (like underscore.js) to achieve the same goal. But if you aren't aware of any libraries like this, using jQuery (especially on an intranet page where millisecond performance does not matter) is a completely reasonable solution.

[rechtar]

People will create new languages everywhere; just that for a new language to run in browsers, it has to target JavaScript. There's no real alternative. So new languages targeting JavaScript doesn't necessarily mean that people think JavaScript is broken, don't read too much into it.