Hacker News Reader

Comment by gaius | Hacker News Reader

The answer is "not if you don't have first-class functions" in your language.

Like the article said, "functional programming" doesn't mean using maps and folds. Functional programming is meant to make you reason about state by always handling it very explicitly e.g. by using functions that take a state and produce a new one, so that your program is constructed by piping the result of a function into another's input, instead of implicitly.

That would appear to be a definition of functional programming that says nothing about functions themselves, which seems odd. Because you can't make any guarantees about state in a language that wasn't intended for FP because how do you know what side effects the built-in functions are having?

Well, clearly in a language that doesn't make a distinction between functions that have side effects and functions that don't you'll just have to pinky swear you won't put any in your functions, and maybe try to wrap the side effects the built-in functions do have (like errno in C) with your own functions.

But that's not the point; a functional style can be achieved in any language as long as it has functions.

You can't even make that guarantee for functional languages. How do I know the built in operators for scala aren't producing side effects without reading the code of the compiler itself?

Additionally you should know that functional programming is a lie. Your computer is an imperative machine with no understanding of functional programming. The compiler transforms your functional program into an imperative one.

Additionally you should know that functional programming is a lie. Your computer is an imperative machine with no understanding of functional programming

Yet you program a register machine as if it were a stack machine all the time without batting an eyelid!

>Because you can't make any guarantees about state in a language that wasn't intended for FP because how do you know what side effects the built-in functions are having

This is your original argument. I said that FP programs offer none of the said guarantees because they are at it's core compiled into imperative programs... You responded with a statement about a stack machine being an abstraction over a "register machine." How does the stack machine statement move your original argument forward...? We're getting side tracked here...

You don't. It's entirely possible to write not-at-all-functional code in Scala. One of the many reasons I dislike it.

ah never knew that. My mistake. I just chose a random "functional" language as an example.

This is not true at all. The only technical requirement for you to follow the functional paradigm is immutability.

Keep in mind that passing a first class function into another function as a parameter is not that far off from passing the result of that function as a parameter.

How do you figure? map() for example, is similar to but not identical to for... next.

You can still use recursion to loop. First class functions are a convenience to functional programming not a requirement. Map and reduce and other higher order functions are also not a strict requirement for fp.

Without first class functions an immutable program can still be turing complete. I would say that if a language only supports recursion and is immuteable, then that is all you need for the language to be part of the fp paradigm.

Where did you get this definition?

Intuition and experience. The definition naturally occurs to you over time, I've never seen the isomorphism between immutability and functional expressions illustrated though. However, it is explicit that every functional language is immutable as a requirement.

I'm sorry to say that if you don't understand this, you haven't really understood what functional programming is... You're just a guy who understands higher order functions.

> Intuition and experience.

...

> I'm sorry to say that if you don't understand this, you haven't really understood what functional programming is...

you can't be serious can you ?

I am dead serious. If you don't understand this:

>The only technical requirement for you to follow the functional paradigm is immutability.

Then you don't understand functional programming. I can't take you seriously if you claim otherwise.

Obviously, you highly disagree with me. Feel free to elaborate rather than waste my time with obviously rhetorical questions.

> The only technical requirement for you to follow the functional paradigm is immutability.

So are you saying that for instance both CaML and LISP aren't FP ? Because both are certainly not about immutability and you can write mutable messes in either.

https://www.wikiwand.com/en/Functional_programming

Read the first line:

"In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions[1] or declarations[2] instead of statements."

Key phrase: "avoids changing-state and mutable data."

You can use C++ as if it was a functional language just like you can use LISP and CaML as if variables were mutable. However in both cases you are bending the language to follow a paradigm that is NOT functional.

"passing a first class function into another function as a parameter is not that far off from passing the result of that function as a parameter"

Not that far off unless you want to do partial application, currying, lazy evaluation, analyze, or change the code of the function before actually using it.

Reply on news.ycombinator.com