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

Admitting That Functional Programming Can Be Awkward (2007)

prog21.dadgum.com

Post reply on HN
Print view View original

101–110 of 148 posts

Re: Admitting That Functional Programming Can Be Awkward (2007)

#101

Post by pyrale »

kibwen wrote: post #67
pyrale wrote: post #50

Earlier quoted context omitted.

> there is no other first-class language feature common to all the self-described "functional" languages. This line of speech usually serves to corner FP in a self-contradicting definition that can be wrestled with, and it is really aggravating. Functional programming as a concept is well defined, and it's not merely "first-order functions". The reason why many functional languages don't have the same feature set is…

> Functional programming as a concept is well defined, and it's not merely "first-order functions". Then, sincerely, what is the definition? Does that definition succeed in excluding languages that are not considered functional, e.g. C++, Java, Python, Go? And if it doesn't, and the definition is so broad as to encompass every language, then what is the useful purpose of going out of one's way to label a language as…

This quote elsewhere in the thread lines up with my knowledge:

> Functional programming was never about first-class functions. It was always about programming with pure and total functions in their mathematical version.

Other people have correctly pointed out that this is an extremely ambitious idea, since, as they have noted, you can't build a turing-complete language with pure and total functions.

This very high bar explains why there has been so many different design decisions in languages, and why most fp languages make tradeoffs in order to reach a compromise between what they believe is important in that concept, and what they can pull in terms of usable software.

As I noted as a response to that thread, we have seen in the recent years languages that achieve pure/total functions, but this was only possible because so many forebearers had tried different designs, and comprmised to produce usable software they could iterate from.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#102

Post by adwn »

pyrale wrote: post #92
adwn wrote: post #90

Earlier quoted context omitted.

> It was always about programming with pure and total functions in their mathematical version. Are you sure about this? A total function is defined for all of its possible inputs, i.e., it must always terminate. A functional programming language with only total functions isn't Turing complete.

Several recent languages that came from the FP community recently tend to achieve this. This is the case of Agda, for instance, and I believe Idris also has totality checking.

Maybe you mean optional totality? As in, a function can be declared to be total and the compiler tries to prove it?

A language cannot be Turing-complete if it completely forbids non-termination, there is no way around this. Or stated differently: If a language is Turing-complete, then there are programs that don't terminate. If a Turing-complete language only has functions which are total (i.e., which always terminate), then it has another mechanism which allows non-termination, e.g. unbounded loops and mutable state.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#103

Post by nerdtime »

Functional programs tend to be more modular than imperative or OOP counter parts but nobody really knows why nor do they understand the cases where FP becomes less modular.

FP is only modular when you use combinators. If you use closures then it's no longer modular.

   f x y = x + y
   g y = y * 2
   w x = (f x) . g
g and f are combinators and modular and w is the composition of both of those combinators.

   w = \x -> (\y -> (x + y) * 2)
In this case the above is not modular because it doesn't use combinators. The above style is actually kind of promoted by haskell when you need to do things with side effects. It actually makes FP more complex than it needs to be without improving modularity.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#104

Post by chowells »

I would much rather write the logic the author describes in Haskell than C. The C code will have to be carefully managed during development and maintenance to make sure the side effects are happening in the expected order and that no changes ever introduce unexpected interleaving of mutation. The Haskell version will prevent that trivially. You can't even express doing it the wrong way, because you can't mutate anything.

Accidentally interleaved mutation is not a theoretical or academic problem. It's probably the number three source of production bugs in my dayjob's various products, behind misunderstood requirements and web browsers constantly changing the rules. It turns out that everyone, even people like me who know better and have been burned several times, will sometimes take the convenient shortcut. It's so tempting to get something done immediately by quietly mixing some mutation in an unexpected place, and it usually doesn't bite you. Then it gets ossified that way, and a year later starts biting you. This really does happen in code maintained by multiple developers over multiple years.

To be fair to the original post, though, Haskell has come a long way in making that kind of coding easy since 2007. The lens library didn't exist back then, and it's a big part of why data transformation programs are so much more pleasant in Haskell than most languages. It lets you express data access at the right level of abstraction. You get laws to enable algebraic reasoning and a broad range of utilities for composing small pieces together to solve complex problems.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#105

Post by fanf2 »

gnulinux wrote: post #24
Avshalom wrote: post #13

Earlier quoted context omitted.

It's a bit more subtle but the lack of statements that is, everything returns a value, is an important feature/quality.

Functional languages do have statements. a : Int -> Int a x = x + 2 both `:` and `=` are statements, not expressions.

They are usually called declarations rather than statements, I think.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#106

Post by dnautics »

ramchip wrote: post #33
dnautics wrote: post #14

I'm confused by this article. The author says he's in erlang (which, btw, is not pure functional). And then goes on to describe a system which sounds like an object oriented system. But a game programmer would probably actually implement it not as object per se, but maybe backed by an entity component system. But it seems like BEAM languages would be actually quite good at expressing entity systems, which, correct me…

I think it’s a common trap for Erlang beginners to try to represent all entities (player, monster, room, etc.) as processes sending messages to each other, the way you’d use classes in OOP. It’s one way to learn the concepts, but in real apps it leads to messy, brittle code. Erlang processes really shine when they’re used as units of fault tolerance, not a code organization tool. For an entity system ETS could be int…

Sure. You wouldn't use pure erlang for a game where perf is critical, but not every game is like that.

I bet you could even write a fantastic AAA game by carefully dropping into NIFs as necessary.

I think though my argument is that you also wouldn't use objects for that sort of thing either. The brittleness of the code has nothing to do with the underlying vm, or its performance, or even it's concurrency, and everything to do with the code architecture and data organization, which is isomorphic between genservers and objects.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#107

Post by dnautics »

MauranKilom wrote: post #46
ramchip wrote: post #33

Earlier quoted context omitted.

I think it’s a common trap for Erlang beginners to try to represent all entities (player, monster, room, etc.) as processes sending messages to each other, the way you’d use classes in OOP. It’s one way to learn the concepts, but in real apps it leads to messy, brittle code. Erlang processes really shine when they’re used as units of fault tolerance, not a code organization tool. For an entity system ETS could be int…

What do you use for code organizational purposes then?

Modules. Basically something between a namespace and a shared object (.so)

Re: Admitting That Functional Programming Can Be Awkward (2007)

#108

Post by lifthrasiir »

pyrale wrote: post #50
kibwen wrote: post #6

I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages. IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state…

> there is no other first-class language feature common to all the self-described "functional" languages. This line of speech usually serves to corner FP in a self-contradicting definition that can be wrestled with, and it is really aggravating. Functional programming as a concept is well defined, and it's not merely "first-order functions". The reason why many functional languages don't have the same feature set is…

> It is really a pity that so many people can't or don't want to acknowledge the nature of engineering work, and hold imperfections against the creators, or the concepts they try to implement.

This would be a great stretch if it was meant to be a reply rather than a generic statement. To me the increasing irrelevance of a term "functional" is in fact the biggest success of the FP: it is entering the realm shared by, say, the term "structural programming" which is so universal that it became meaningless. It is an amazing feat given that no other terms for programming paradigms ever have been close this much!

Given any standard about the FP, there is a definite disparity between languages that should be called functional and languages that are actually called functional. I think the increasing universality of functional paradigm explains this, and kibwen is merely proposing another term describing the latter.

Re: Admitting That Functional Programming Can Be Awkward (2007)

#109

Post by pizza234 »

jamil7 wrote: post #76
qsort wrote: post #47

Earlier quoted context omitted.

I'm all for the 'right tool for the job' mindset, but why would it be bad in principle to write an application in JS? Leaving aside the fact that modern JS is ~3x slower than C++, i.e. slightly slower than C# and Go but in the same league as Java/Haskell, not in the same league as Ruby and Python, programs like VSCode are written in JS and they have no performance issues. It's true that performance is often ignored f…

> VSCode are written in JS and they have no performance issues VSCode is not performant, especially on startup and especially when compared to editors like vim or sublime text. I agree that the reason likely isn't language choice though it's the use of electron. I don't agree with you about software not needing to be performant either, I believe developers should strive to make their software run as efficiently as th…

> I believe developers should strive to make their software run as efficiently as they can.

This is not realistic. Performance doesn't just happen. Within limited constraints, focusing on performance will necessarily imply less feature.

Ultimately, it's about balance. Personally I find VSC's performance to be good, and at lot of other devs find it at least good enough (it's a widespread editor). I've actually switched away from ST3 because the development of their current version stagnated, and there are unresolved bugs and limitations that affected my everyday usage.

In other words, the performance/features (and let's throw flexibility) balance of VSC is, for me, better than ST's (others may have have different requirements and different balances, of course).

Ultimately, VSC is a bad example of tradeoff performance/ease of (internal) development. If people wants to find an example, Slack is by far the best (worst).

Re: Admitting That Functional Programming Can Be Awkward (2007)

#110

Post by dnautics »

dsabanin wrote: post #21
kibwen wrote: post #6

I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages. IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state…

Functional programming was never about first-class functions. It was always about programming with pure and total functions in their mathematical version.

That's not really true. Op is programming in erlang, which has never in it's history been pure functional, and specifically picked the functional paradigm for pragmatic reasons (function-internal immutability and limited global state gives the programmer guardrails), not for pure mathematical reasons.
Post reply on HN