Hacker News Reader

Comment by louthy | Hacker News Reader

Most OO languages can do this now, and they wouldn't be classed as functional languages. I know this is always a sticky subject, but for me I prefer to think of functional languages as 'expression oriented' rather than 'statement oriented'.

View on HN

F# is a functional first language, yes, C# with Func<> can do many things, but functional code in F# is just smooth and easy, unlike C#, where you have to put up with lot of noise.

I haven't mentioned or was making any points about F# or C#; I was commenting on what appears to be your definition of a functional language, that is "Functional programming is a broad term that at its core describes languages that allow you to pass functions around as values to other functions".

Even if that meant something in the past, it really isn't a useful definition any more, because pretty much all languages do this. That's why I offered my alternative description. Even if it too has flaws, I think it's a more meaningful description.

Pure functions, i.e. that are 1) idempotent 2) have all their arguments passed in 3) cause no side effects as a by product of evaluating the function are fundamental to functional programming.

But not fundamental to the definition of a functional language. F# isn't pure, but most would call it a functional language - so purity is surely not 'fundamental' - in fact most functional languages aren't pure.

That's why I prefer to stick to the 'expression oriented' concept, it seems to be the thing that captures most, if not all, functional languages. But I guess just like there are plenty of people that wouldn't call Java OO (and would prefer the Alan Kay definition), there are plenty that will disagree with any definition of 'functional'

(preparing for the inevitable 'functional first' comment).

Yeah, I could go along with that.

Are there any terms/concepts in math/CS that are related to or similar to "idempotence"?

I think in this case, referential transparency means the same thing. That is, produce the same output given the same input, every time.

Got it, thanks.

> "I haven't mentioned or was making any points about F# or C#; I was commenting on what appears to be your definition of a functional language"

sremani != ZenoArrow (though if you read this sremani, thank you for attempting to clarify).

There are many 'multi-paradigm' languages, and C# is one of them. From the C# Wikipedia page...

https://en.wikipedia.org/wiki/C_Sharp_(programming_language)

"C# (pronounced as see sharp) is a multi-paradigm programming language encompassing strong typing, imperative, declarative, functional, generic, object-oriented (class-based), and component-oriented programming disciplines."

What makes a language 'functional' is first-class functions (i.e. functions that can be treated as values, which is what I was referring to in my earlier post).

As sremani said, F# is 'functional first', in the sense that the language is designed to make functional algorithms straightforward to express. You can write C# in a functional way too, but there's less syntactic sugar for this style of programming.

Hope that clears it up.

> sremani != ZenoArrow

Apologies, my mistake.

> Hope that clears it up.

First paragraph on the Wikipedia page for Functional Programming [1]:

"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."

I'll stick with my definition.

Hope that clears it up.

[1] https://en.wikipedia.org/wiki/Functional_programming

With your definition, is Lisp a functional language? Is it expression-oriented or statement-oriented?

I'm not an expert on this subject (have only dabbled in a few FP languages over the years), but what I've read in various sources leads me to think that the term "functional programming" itself is not very well-defined, or, to put it another way, different people may have different definitions of it, each including and excluding various language features or capabilities. Is that right? Any experts care to comment?

Yes, but you could say the same about "object-oriented programming" (is it about inheritance? message passing? N/A?) and even something as well-defined as "pass by reference" (many people apply this term to Java, many others think that is completely wrong).

Ultimately, we have to live in a world where words are kind of ambiguous, but I think we should try to avoid useless definitions. The definition where "a functional programming language is one that can pass functions around" is extremely useless, because it applies to every modern programming language including C and C++. Whatever you want the term to mean, it shouldn't be that, because that distinguishes nothing.

Agreed.

> "Whatever you want the term to mean, it shouldn't be that, because that distinguishes nothing."

It's not extremely useless when you consider most programming languages cover multiple PL paradigms.

Functional languages are a spectrum. On one end you have pure functional languages like Haskell where you're forced to use functional algorithms for all computation, but there are languages in the middle of that spectrum like C# which support a bunch of functional language constructs (take a look here for a selection: http://www.codeaddiction.net/articles/13/lambda-expressions-... ) even if they aren't purely functional.

My argument is, any definition of functional programming that ignores the mid part of the spectrum is useless, as it ignores that most languages do not strictly follow a single approach like Haskell but allow you to adapt to different styles (i.e. most programming languages are multi-paradigm). Even F# and Ocaml allow you to write in an imperative style if you so choose, and many people would class them as 'functional' languages.

> functional languages like Haskell where you're forced to use functional algorithms for all computation

No you're not. Haskell supports mutable, imperative, algorithms just fine.

https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-I...

https://hackage.haskell.org/package/base-4.9.0.0/docs/Contro...

https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control...

Thanks. If anything that backs up my main point that most programming languages are multi-paradigm.

Yes, but it doesn't bolster your argument as much as you think. The state monad in Haskell offers a more principled (some say annoying) way of dealing with mutation.

IORef's if I recall correctly offer the type of mutation similar to what is colloquially thought of as mutation.

These add to your argument a bit, but they're usually seen more of a last resort

Sort of. My very opinionated point of view would be that Haskell demonstrates that the functional paradigm is the correct setting for the imperative style.

Reply on news.ycombinator.com