Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Mostly functional” programming does not work

queue.acm.org

Post reply on HN
Print view View original

21–30 of 205 posts

Re: “Mostly functional” programming does not work

#21

Post by lomnakkus »

Amadiro wrote: post #18
PaulAJ wrote: post #5

The software engineering world is in danger of repeating the mistake it made with objects two decades ago. Back then there were legacy "structured" languages like C and Ada, and new exciting "object oriented" languages like Smalltalk and Eiffel. C++ was promoted as a "middle way" that let you "choose the best tool for the job". This made the pure OO languages look extremist. So, it was argued, if you had a problem be…

And just what makes you think making a purely functional language 'lambdacious' will not a few years later result in a book 'Industrial strength lambdacious'? You're falling for the trap of thinking that pursuing a theoretically pure discipline will result in a language with less flaws; in reality, even theoretically pure concepts have issues and can be superior and inferior to other theoretical concepts/constructs […

The problem with Erlang is that it solves the wrong problem, so to speak. Reasoning about state locally (inside a procedure/function) isn't all that hard -- which is why intra-procedure/function immutability doesn't actually get you very far. The trick in, e.g. Haskell, is that you can enforce inter-function immutability. In the end all actor-based systems end up being a huge mess of distributed/shared mutable state -- which is what we're trying to get away from. (I'm well aware that there are formalisms that can help you deal with some of this complexity, but they are a) not part of the language, and b) not practiced very widely in my experience.)

Re: “Mostly functional” programming does not work

#22

Post by Someone »

PaulAJ wrote: post #5

The software engineering world is in danger of repeating the mistake it made with objects two decades ago. Back then there were legacy "structured" languages like C and Ada, and new exciting "object oriented" languages like Smalltalk and Eiffel. C++ was promoted as a "middle way" that let you "choose the best tool for the job". This made the pure OO languages look extremist. So, it was argued, if you had a problem be…

"And its going to fail for the same reasons that C++ failed"

If only my successes were as successful as that failure. Back then, if you had a code base in C, migrating to C++ was easier than migrating to Smalltalk or Eiffel.

Similarly, today, migrating a C code base to C++ or and using its functional 'extensions' or starting to use those features in a C++ code base is easier than migrating it to Haskell or Scheme.

C++ is far from perfect, but it beat other contenders because of that feature.

And yes, if, as I expect, C++ remains popular, we will have books describing the pitfalls of functional-style programming (Stroustrup: "There are only two kinds of languages: the ones people complain about and the ones nobody uses"). For example, we will see blog posts lamenting the heavy nesting of map/apply/select chains because the resulting code, in some cases, will run out of instruction cache space, degrading performance.

Re: “Mostly functional” programming does not work

#23

Post by brudgers »

PaulAJ wrote: post #5

The software engineering world is in danger of repeating the mistake it made with objects two decades ago. Back then there were legacy "structured" languages like C and Ada, and new exciting "object oriented" languages like Smalltalk and Eiffel. C++ was promoted as a "middle way" that let you "choose the best tool for the job". This made the pure OO languages look extremist. So, it was argued, if you had a problem be…

Scheme like other Lisps is conducive to programming in a functional style but is not pure functional in the sense of Haskell.

Re: “Mostly functional” programming does not work

#24

Post by userbinator »

PaulAJ wrote: post #5

The software engineering world is in danger of repeating the mistake it made with objects two decades ago. Back then there were legacy "structured" languages like C and Ada, and new exciting "object oriented" languages like Smalltalk and Eiffel. C++ was promoted as a "middle way" that let you "choose the best tool for the job". This made the pure OO languages look extremist. So, it was argued, if you had a problem be…

> And its going to fail for the same reasons that C++ failed

C++ "failed"?

> the OO and functional features don't interact well

How don't they? Before C++ had lambdas, programmers would define a class with overloaded operator() and use that instead, every time. Now the language provides a way to easily generate the class with its members and constructor and operator() automatically - which is basically what functional languages turn lambdas into. You could make the same argument that "procedural and OO features don't interact well", but C programmers were (and still are) using structures and function pointers to accomplish much the same effects.

Re: “Mostly functional” programming does not work

#25

Post by mixedbit »

lomnakkus wrote: post #21
Amadiro wrote: post #18

Earlier quoted context omitted.

And just what makes you think making a purely functional language 'lambdacious' will not a few years later result in a book 'Industrial strength lambdacious'? You're falling for the trap of thinking that pursuing a theoretically pure discipline will result in a language with less flaws; in reality, even theoretically pure concepts have issues and can be superior and inferior to other theoretical concepts/constructs […

The problem with Erlang is that it solves the wrong problem, so to speak. Reasoning about state locally (inside a procedure/function) isn't all that hard -- which is why intra-procedure/function immutability doesn't actually get you very far. The trick in, e.g. Haskell, is that you can enforce inter -function immutability. In the end all actor-based systems end up being a huge mess of distributed/shared mutable state…

Haskel doesn't address problems of distributed computing at the language level. For distributed computing you need message passing, you need to handle failures. If you do distributed computing in Haskel, you also need to build and use actor-based abstractions. It is not possible to hide distributed computation behind an immutable function call abstraction (RPC systems tried to do it and failed).

Re: “Mostly functional” programming does not work

#26

Post by chongli »

cynicalkane wrote: post #7
PaulAJ wrote: post #5

The software engineering world is in danger of repeating the mistake it made with objects two decades ago. Back then there were legacy "structured" languages like C and Ada, and new exciting "object oriented" languages like Smalltalk and Eiffel. C++ was promoted as a "middle way" that let you "choose the best tool for the job". This made the pure OO languages look extremist. So, it was argued, if you had a problem be…

How about Clojure, which is a Lisp-like language with objects? Explicitly, you have protocols and multimethods; implicitly, almost everything under the hood is done with Java interfaces (and you can make new first-class datatypes by implementing the interfaces, though this is mildly discouraged). I cannot recall anyone complaining about the OO clashing with the functional patterns. There's also O'Haskell, and in regu…

and in regular Haskell you can get something like polymorphism (implemented under the hood with actual polymorphism) with forall-qualified datatypes.

Huh? Haskell's polymorphism capabilities are more expressive and more expansive than most other languages'. Higher-kinded polymorphism, a mainstay in Haskell, is pretty rare to find almost anywhere else.

Re: “Mostly functional” programming does not work

#27

Post by nextos »

coolsunglasses wrote: post #19
cynicalkane wrote: post #7

Earlier quoted context omitted.

How about Clojure, which is a Lisp-like language with objects? Explicitly, you have protocols and multimethods; implicitly, almost everything under the hood is done with Java interfaces (and you can make new first-class datatypes by implementing the interfaces, though this is mildly discouraged). I cannot recall anyone complaining about the OO clashing with the functional patterns. There's also O'Haskell, and in regu…

I'm an experienced Clojure user with work done on the job and in open source. If you're a Clojure user, it's very likely you've used a library I've worked on or made. Don't bother. Go straight to Haskell and just Haskell. No excuses, no compromises, no mental backflips to justify not learning something new. Learn Haskell properly and then see for yourself why "hybrids" are a waste of time. Hybridized approaches are l…

While I agree hybrids are in general a bad idea, some good hybrids exist. But they are extremely hard to get right. For example, Oz/Mozart:

http://www.sm.luth.se/csee/courses/timber/reading/VanRoy.pdf

http://www.epsa.org/forms/uploadFiles/3B6300000000.filename....

Re: “Mostly functional” programming does not work

#28

Post by eternalban »

seanmcdirmid wrote: post #3

Debugging a functional program is so difficult (data flow debuggers don't really exist) that equational reasoning is necessary because you want be able to fix your code otherwise. But really, mixing list comprehensions with effects is really a bad idea, and we C# programmers have no trouble avoiding it. There are ways to tame side effects without going monads, which don't really fix the complexity problem anyways (it…

This is the first time I see this Sean (did you post to LtU?) and it's good to see -- based on a cursory glance just now -- one's private research validated by academia! :)

I'm taking a cognitive processing model approach [with primitives of] data ("facts") and references ("values") and the memory model to handle and relate them takes the primary stage. This would allow for existing languages to take advantage of the temporal memory model (which is content addressable, btw) and also permit a native language with first class support for 'POV' semantics to also use it.

I'm calling this approach to building information systems "Optimistic Realism".

Re: “Mostly functional” programming does not work

#29

Post by 6cxs2hd6 »

_random_ wrote: post #2

I am not sure what I am doing wrong, but using functional techniques improved my C# quite a lot.

There's an old saying, "perfect is the enemy of good".

Here OP plays the role of Perfect. You are Good.

(Opinions vary about the wisdom of this old saying. See: perfect vs. good.)

Re: “Mostly functional” programming does not work

#30

Post by neverminder »

PaulAJ wrote: post #5

The software engineering world is in danger of repeating the mistake it made with objects two decades ago. Back then there were legacy "structured" languages like C and Ada, and new exciting "object oriented" languages like Smalltalk and Eiffel. C++ was promoted as a "middle way" that let you "choose the best tool for the job". This made the pure OO languages look extremist. So, it was argued, if you had a problem be…

I don't know, but something tells me that it may take quite a while for Scala to fail in any noticeable way, at least according to google trends it's still the most popular functional language - http://www.google.com/trends/explore#q=%2Fm%2F03j_q%2C%20%2F...
Post reply on HN