Functional JavaScript

>Functional JavaScript
what did he mean by this?

Attached: flat,800x800,075,f.jpg (800x800, 19K)

Other urls found in this thread:

groups.google.com/forum/#!topic/comp.lang.lisp/QdqnoZUEtXA
news.ycombinator.com/item?id=3965897
quora.com/Why-is-Common-Lisp-not-really-a-functional-language-but-Clojure-is-one
twitter.com/NSFWRedditGif

I think he means just reducing JS bloat, not implementing spyware and using scripts only when ABSOLUTELY necessary. Thus making JS a more functional language (in a literal sense, not in the sense of the programming paradigm called "functional programming").

It's nice being this deluded.

Before Javascript was even called Javascript, Brendan Eich had created a quick and dirty dialect of Scheme. It was meant to have proper lexical scoping (somehow this got broken or abandoned, turning into nigger-tier function scoping), has first class functions, and has closures. All of these came from it's background as a dialect of Scheme.

So yes, javascript is related to functional programming. Don't let it's "C-like" syntax deceive you.

>I think he
Who?

Only people who have never touched an actual FPL think that JavaScript is a functional language.

Whether Common Lisp qualifies as a functional programming language is controversial because Common Lisp allows and perhaps even encourages mutation and side effects. Haskell enthusiasts will tell you Common Lisp is not a functional programming language because of this. Lisp enthusiasts will wave their hand and say that just because mutation and side effects are permitted, doesn't mean you can't use the language for functional programming. Some C programmers will claim their language technically allows for functional programming too, but Lisp programmers will counter that C make it a path of low resistance to the programmer.

Thus we have three related concepts.
>Is the language a functional programming language?
>Does the language allow functional programming?
>Does the language make it easy to use functional programming?
One is not necessarily the other.

By the above standard, Javascript is not a functional programming language but it does allow functional programming and arguably makes it easy. The last point is marginal with Javascript, but since lexical scoped variables were added to the language the situation improved.

Attached: 1503641347234.jpg (593x640, 97K)

>but Lisp programmers will counter that C _DOES NOT_ make it a path of low resistance to the programmer.

>Haskell enthusiasts will tell you Common Lisp is not a functional programming language because of this.
No they don't, impure functional programming is still functional programming.
>it does allow functional programming
No TCO in practice so it doesn't.
>and arguably makes it easy
It makes it much harder than imperative programming.

>but it does allow functional programming and arguably makes it easy.

No it fucking doesn't, only people that don't know proper pure functional languages think that.

This is the list of things that are "easy" to do in an FP way in javascript:

>Lists

That's basically it, just Lists (Arrays), Arrays in javascript are really powerful and their use in idiomatic javascript is pretty much functional, you have neat things built in like array.map, array.reduce and you can combine arrays easily two with +.

However, there are also things that Javascript doesn't allow you to do easily on a functional programming style:

>Error Handling I/O (and we've failed TWICE at fixing this).

>Everything that requires proper type conditions.

>Every data structure that is not a list.

Of course we could do all of those things on Javascript on a functional style, but it wouldn't be really idiomatic.

>combine arrays easily two with +.
what the fuck am I reading

How would one even do closures in C? I know GCC and Clang have this blocks extension that allows it, but how else do you pass some additional information along with the function pointer?
It's not like you can make a struct callable like in C++.

Notice the conflict between these two statements:
>No they don't, impure functional programming is still functional programming.
>[it doesn't make functional programming easy] only people that don't know proper pure functional languages think that.

A fundamental disagreement on the importance of functional purity. One insists that functional purity is important, the other claims it isn't. Obviously neither Javascript nor Common Lisp have functional purity, we all know that, but people disagree on whether or not functional purity is a necessary prerequisite to say the language permits functional programming.

>>it does allow functional programming
>No TCO in practice so it doesn't.

Are you aware that the Common Lisp standard does not require tail call optimization? (The scheme standard does require TCO, but the CL standard does not.) Many implementations of CL support TCO, but it's not required by the standard. This is one of the reasons I chose to mention Common Lisp.

>How would one even do closures in C?
Not easily.. you have to explicitly bundle up the state you want to pass with the function pointer. The language doesn't do it for you. Regardless, closures aren't a necessary prerequisite for functional programming... but just a fucking stupid language if it's not supported. It took many years for lexical scoping to catch on, before lexical scoping was popular dynamic scoping common. Dynamic scoping and closures do not mix, to put it gently.

I assume he means something like (map + '(1 2 3))

err, (apply + '(1 2 3))

He was talking about JS tho. Operator overloading is also just in a proposal draft stage afaik

Again, no one claims that impure FP is not true FP. Most functioanl languages are actually impure, I've never seen a Haskell programmer saying that Haskell is the only real FPL among the well known ones.

>I've never seen a Haskell programmer saying that Haskell is the only real FPL among the well known ones.
It's not hard to find Haskell programmers willing to stir up shit by claiming Lisp, particularly Common Lisp, is not a functional programming language (because it isn't pure):

groups.google.com/forum/#!topic/comp.lang.lisp/QdqnoZUEtXA
news.ycombinator.com/item?id=3965897

Clojure-tards do it too: quora.com/Why-is-Common-Lisp-not-really-a-functional-language-but-Clojure-is-one

Work with enough haskell or clojure developers and you'll run into more than a few of these turbo-autists.

I find it quite fascinating how so much people can be wrong about what Functional Programming actually is. I don't thing anybody cares, but I'll try to explain the true meaning of FP.

If you search for any introduction to FP material, they all sum up FP as:

>Program only using immutable data structures.
>Use only pure functions (that is, functions with no side effects).

Both of those statements are bullshit. And you shouldn't take seriously anybody that uses them.

Functional Programming is the use of Mathematical Constructions to represent computations. That's it.

To understand what that definition means you need to understand what a mathematical construction is, what is representation and what is a computation. But in general you can think about this as:

Mathematical constructions are algebraic objects: Groups, Rings, Limits, Monads, Topos... Etc.
Representations are ways to translate stuff, in this case the math stuff to stuff the computer can understand.
Computations are like in the things a Turing Machine can do.

In languages like Haskell we only write stuff with input and output and nothing in between, but the semantics beyond that goes way beyond functions in the mathematical sense. Those semantics have ways to deal with mutability (for example with dependent types) and side effects (for example with the semantics of monads).

Attached: b4184da4ccc1fc1d858c1195d4cbdaa6.jpg (564x765, 52K)

>limits are an algebraic object

He probably got confused and thought an imperative language without OO makes it a functional language?

I'm not talking about limits like in calculus.

I'm talking about the abstract notion of limit, pic related is from wikipedia. (And yes they coincide in the case of the real numbers with the standard topology).

Limits are insanely important in FP, there are people right now developing new concurrency models based in colimits for example.

Attached: limits.png (1089x451, 37K)

goddamn category theorists appropriating beautiful analysis again!

you are explaining what idiomatic fp is, not what fp is

That's a very breathy way of adding nothing new to the conversation.

that's just the half life logo if you make it all square and sharp edges

Nobody thinks javascript is a functional language.

But you can do functional programming in javascript if you want.
Javascript does treat functions as first class citizens.

In all honesty user, FP conveys a lot of ideas. I just wanted to illustrate how everybody has an opinion about FP without understanding it properly, like . I worked in my undergrad on Functional Programming and struggle a lot trying to respond the question "FP is", because of the tons of bullshit around the concept. So sorry if my explanation was insufficient.

I've read books made by language designers that didn't understood jack shit about what they where talking about.

This is something particularly evident in the JS community, they think that because the have first class functions they can do FP, when the semantics of the language are so insanely limited and poor.

They even make books and big libraries around it, they praise bullshit libraries like React and act like Node is the second coming of Jesus, they jerk off to "modern features" like Promises and async-await blocks that are nothing more than poorly implemented monads. How the fuck the designers of one of the most important languages in the world miss those flaws?

Javascript's support for the functional language paradigm is insanely poor. JS is a little dynamic language that works okay for small event driven applications, you have fucking event loop and its stack to worry about, and you do just that on an imperative manner, by design.

TCO hardly is required for a language be considered functional

This is just idiocy. JS has closures, lambdas, first class functions and declarative built-in data structures. It's as functional as languages come, just not pure.

>closures
This has nothing to do with FP, if you think so, you don't understand what FP is.
>lambdas
This has nothing to do with FP, if you think so, you don't understand what FP is.
>first class functions
This is nice.
>declarative built-in data structures
This is a lie.

Used the right way, javascript can be used in a no less functional style than Scheme. That doesn't mean it's a good language. That doesn't mean the language encourages it. That doesn't mean you should use it. But it's an uncontroversial fact that you can use javascript in a functional manner. Nothing you've said comes even close to refuting that.

The problem is too many retards on Jow Forums think that saying javascript can be used in this manner constitutes a defense of javascript (it isn't) and that gets them hot under the collar.

All you seem to be good at is throwing around baseless hyperboles. What makes JS "insanely poor" as a FPL when it has all the ingredients to support painless execution of lambda calculus?

It boils down to this:
>he likes FP
>he dislikes Javascript
>he thinks that associating the two is offensive because he likes one and dislikes the other

>lambda functions have nothing to do with FP
Opinion fucking discarded

lambda calculus is only tangentially related to FP user, they share their declarative nature and the principle of referential transparency, but that's about it.

Well, considering it can be made to work very much like Scheme with a few helper functions, I'd say it's become a pretty good language. Gets the job done with minimal code noise, still managing to be performant enough for most things. We could be stuck with a much worse language.

Then what actually is FP in your opinion? Do give us an exact description instead of handwaving.

In reality Haskell is the only well known FP language that is truly based on lambda calculus and imposes referential transparency

>I'd say it's become a pretty good language.
It has a shitty syntax (Anybody designing a language that doesn't use s-expressions is just being foolish), functional scoping is asinine (thankfully it has optional lexical scoping now) and equality is all fucked up.

It's a bad language. Being close to scheme in other regards doesn't save it.

Attached: 1507594231979.png (590x590, 23K)

Ever heard of S-expressions?

It has a succinct amd completely inoffensive syntax, what exactly are you whining about here?
It has had lexical scoping for years, that's all people are using now
It has the === operator that works just dine logically, your own fault if you compare things that make no sense to be compared and refuse to type the extra = character

>buh buh it's bad because it's not Lisp
You're retarded.

It's the year two thousand and eighteen now. Look at the language again.

You said
>it can be made to work very much like Scheme with a few helper functions
This is blatantly false

The syntax is shit, designed to superficially look like Java, which itself has a shit syntax designed to superficially look like C, which itself has a shit syntax designed to superficially look like B.

This syntax class has no technical merit, it doesn't give the language more capabilities or facilitate advanced editor features (s-expressions does both of these things.) The only reason it's still used in languages today is decades of cargo culting.

None of what I've criticized javascript for has changed. Equality is still a clusterfuck. Function scoping still exists (even if lexical scoping is now an option) and it still has it's shitty java-inspired/c-inspired/b-inspired syntax.

Well, aside from function application syntax, which is a pointless thing to whine about, what about it was "blatantly false"?

Not him, but it's very easy to write scheme code that transforms code into javascript, and it's easy to add cons cell support to javascript. The real problem is javascript isn't already using s-expressions as it's standard syntax.

S-expressions is about a lot more than just function application syntax...

No wonder you don't see the value, you've plainly never learned it.

You must yourself know you're not being reasonable when you call every language shit for not being Lisp.

This is as much as I'm willing to write right now:
Perhaps a better name for FP would be "Algebraic-Functional Programming" or "Categorical Programming", but the name is the name for historical reasons.

You won't find definitions like mine on most programming books, not even most Haskell books. This idea is pretty new, for instance the idea of using Monads to give FP the ability to talk about side-effects came in the 90s, and there are still things that are pretty weird to talk about in FP terms (like memory managment).

I just wanted to give a little bit of light on the madness surrounding FP, it seems I failed but whatever.

Using s-expressions and being lisp are two separate issues. The problem isn't that the language isn't a lisp dialect, the problem is that the language uses an objectively technically inferior syntax.

If you think I'm wrong, explain why I'm wrong. What technical advantages does a bastard-C syntax like javascript's or java's have over s-expressions?

>functional programming actually has this specific esoteric definition that I discovered and you won't find anybody else writing about this because nobody else agrees with me, but trust me I'm right about this.
Thank you for your valuable contributions to this discussion.

ML-style type systems certainly aren't a requirement anybody uses for the term FP, and JS can adopt the types easily, just see fantasyland.

What advantages would s-expressions offer?

It makes it trivial to correctly parse code without any edge-cases using very little code, which makes programs that transform code trivial to implement. Programs that transform code could be macros, but also editors. S-expressions make it easy for the individual developer to implement such code-transforming programs himself on the fly, instead of relying on code transformations built into his IDE.

S-expressions used for code is basically a thin veneer on an AST. Instead of editing code as a dumb array of characters, you now edit code as a tree.

But what are the practical advantages of this? I've never really thought "gee, I wish I could edit my code programmatically", search&replace and IDE functionality for border cases have been more than enough. And we don't have fancy editors that show us code trees instead of text, clearly if it was super useful it would be a thing already.

s-expressions also facilitate language-oriented programming where-in you solve problems by implementing domain-specific languages.

you can of course implement DSLs to have any syntax, using a language with any syntax. but because s-expressions are trivial to parse and transform creating DSLs with s-expressions as syntax from a host language that uses s-expressions makes everything much easier which increases the viability of language-oriented programming.

>And we don't have fancy editors that show us code trees instead of text, clearly if it was super useful it would be a thing already.
We do. Emacs does, and Vim with the right extensions do. Other editors probably have support for this as well with the right extensions.

Instead of copying a line, you can copy an expression. Instead of deleting a line, you can delete an expression. Lines and characters, the traditional way text editing is oriented, only have a loose mapping to the syntax of most languages. When you use s-expressions your editor becomes aware of what an expression is, not just a line or a character.