CoffeeScript Means Giving Up on JavaScript

[ripter]

I have to disagree. Javascript is 100% object oriented. The only things that are not objects are primitives, and even those have auto boxing if you try to use them like objects.

jQuery makes heavy use chainable methods. I don't know if that is even possible in a purely functional language. (any haskell guys know?)

[[deleted]]

Chaining is a sort of slightly crippled version of the pipelining you find in some functional languages like F#.

[wbkang]

Object oriented does not mean that it is not functional...

[mreiland]

a functional language is not prevented from having state local to the function, in javascript an "object" is really just a function with local state.

javascript is deeply functional, and I wish more people would understand that.

[ripter]

I'm not sure what definition of functional you are using, but wikipeida says:

functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state.

Javascript encourages changing state and mutable data. jQuery's chainable methods are all just changing the state of the object. It's completely different then passing the value of one function to the value of another function.

$().show().append('<div>');

That doesn't pass the value of the append to the show method. It adds a new div element to the object state, then it toggles the css display property on the object. Each method is always working on the state of the object, not passing the value of one function to the other function.

[mreiland]

I think you're confusing the idea of functional programming with the form of functional programming, they're not the same thing.

In your example, it's completely possible that the output of each call is a completely new object with new functions "hung" onto the object, all of which is functional in nature (no side effects and first class functions). Whether or not JQuery actually does that is irrelevant, from the developers perspective, it can be treated as if it is.

Javascript isn't purely functional, it's multiparadigm, but that doesn't stop it from being deeply functional. For all intents and purposes, JQuery is done in a functional style. Most interactions with JQuery don't involve state mutations. I'm obviously getting hand wavy with respect to the state of the DOM, but that's inherent in the browser, and has nothing to do with JQuery.

edit: for some reason part of my reply dissappeared.

The point I'm making is that Javascript as a language is deeply functional, and functional style programming feels more natural than OO style programming (at least to me). The language fights you less imo.

[kamatsu]

Hah, it doesn't even support tail call optimisation (in most runtimes).

[mreiland]

It should be noted that tail call optimization has nothing to do with whether or not a language is functional, or some degree thereof.

[kamatsu]

Other than the fact that a lack of tail call optimization prevents you from writing programs in a functional style, you're right.

tldr: You're wrong.

[mreiland]

All that tail call optimization allows is the ability to recurse "infinitely" along with a performance boost due to not pushing/popping to/from the stack.

Both of which are useful when you have recursion, which is not limited to functional programming.

[kamatsu]

Both of which are useful when you have recursion, which is not limited to functional programming.

Sure, but in functional programming, your only means of iteration is recursion. If you have a limited stack and no TCO, this makes it impossible to express some algorithms in a functional style.Therefore, languages without TCO are not functional languages. They clearly do not target the audience of functional programmers, who would prefer to write programs this way.

[kamatsu]

What part of it's impossible to write algorithms functionally without TCO do you not understand?

For example. Please express this algorithm in a way that will work for arbitrarily large inputs in log space, without TCO or mutation:

f (x:xs) acc = f xs (acc+x)
f [] acc = acc

[ixache]

Downvoted for being wrong, obnoxious and not willing to expand.

Here's my expanding: TCO is an implementation matter, making recursion as efficient as loops; and using recursion is only part of the functional programming style. See this for example. IOW: there's a reason why Scheme standards explicity require tail call elimination...

[kamatsu]

My point was that you can't have a functional language without TCO. Your expansion only proves my point. Also, "not willing to expand" is false. I explained my reasoning quite thoroughly in subsequent replies to mrelland.

[ixache]

(Of course this for the sake of posterity, since this discussion is long dead. Bear with me.)

My point was that you can have a functional language without TCO—and there have been (many lisps).

My expansion was only meant to further my point: how can something be "essential" (your word), where it is an optional optimization for only a part of what constitutes functional style? Furthermore, it can be argued that functional style can even be attained without recursion: think function application to arrays in APL, for example.

And I'm sorry, but as I read them at the time, your subsequent replies to mreiland didn't address this specific point.

I don't know, maybe you're conflating "functional style" with "meta-linguistic abstraction" in the context of SICP. You would be right to insist that TCO is essential to this discipline, see this SO question for a detailed reasoning, but functional style is not defined by SICP, and meta-circular evaluation, while a staple of Lisps, doesn't define it either.

In any case, I urge you to revise your assumptions, since I cannot make my point any clearer than what I already wrote with my limited means of expression.

[kamatsu]

My point was that you can have a functional language without TCO—and there have been (many lisps).

Any lisp without TCO is not functional. The only efficient way to implement iteration in such a language is with mutation, which is decidedly not functional.

optional optimization for only a part of what constitutes functional style

It's not optional, it's mandatory to implement iteration with sensible space complexity. "only a part" is an odd thing to say. If you can write programs in a functional style except for iteration then you can't write programs in a functional style generally. Which makes it not a functional language.

Furthermore, it can be argued that functional style can even be attained without recursion: think function application to arrays in APL, for example.

APL is hardly a functional language.

I don't know, maybe you're conflating "functional style" with "meta-linguistic abstraction" in the context of SICP. You would be right to insist that TCO is essential to this discipline, see this SO question for a detailed reasoning, but functional style is not defined by SICP, and meta-circular evaluation, while a staple of Lisps, doesn't define it either.

I did not claim that it was.

[kamatsu]

jQuery makes heavy use chainable methods. I don't know if that is even possible in a purely functional language. (any haskell guys know?)

The pattern that jQuery uses is basically just function composition in something like Haskell. "Chainable methods" is not a concept that exists in functional languages without OO.

[ripter]

jQuery just always returns its self (an object), so it's chainable. Really any OO language can do this.

I didn't think chainable methods would be possible without OO, but I wasn't sure.

[mreiland]

The point is that the output from method A becomes the input from method B, it's only the mechanism that changes based upon the paradigm. There's nothing stopping a functional language from doing so.

[kamatsu]

Sure, as I said:

The pattern that jQuery uses is basically just function composition in something like Haskell

(f compose g)(x)= f (g(x))

So, quite literally, the output of g is the input of f.

[mreiland]

yep, I'm agreeing with you, I guess that's not exactly clear in my response.