Admitting That Functional Programming Can Be Awkward (2007) • Hacker News Board

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

#71

Post by jcelerier » Sat, Oct 24, 2020, 5:55 PM UTC

qsort wrote: post #47

shaan7 wrote: post #30

Earlier quoted context omitted.

> how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That is a double-edged sword. On one hand it makes sense because it allows teams to be more productive. Otoh, it leads to this decade where it has become okay to create a desktop application using HTML/JS (while more performant tooling exist) simply because a lot of people happen to know HT…

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…

> programs like VSCode are written in JS and they have no performance issues.

here it is compared to qtcreator. it is so damn frustrating when you are used to computers responding near-instantly to have something that... takes its time or stutter to say the least

https://vimeo.com/410735827

https://vimeo.com/410739729

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

#72

Post by acdha » Sat, Oct 24, 2020, 6:01 PM UTC

pyrale wrote: post #59

acdha wrote: post #43

Earlier quoted context omitted.

This may be true in your personal experience but that’s certainly not universal. A key distinction is when you learned this: 2-3 decades ago when most people were using languages without first-class functions, this was very commonly the most important feature mentioned because it was the most pronounced difference. That’s no longer emphasized as much now that this feature and related techniques has become mainstream.

I believe the statement GP made has been true since the days of Church. It is not surprising that "what's the difference between your language and mine" will yield an answer that is different than what you'll get if you ask "what is that concept you're trying to build a language after?"

That might be pointing out an important distinction: did you learn this formally from that academic community or elsewhere? As a global assertion it’s wrong but it could be accurately representative if you’re only talking about subcommunities in the former case.

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

#73

Post by toast0 » Sat, Oct 24, 2020, 6:03 PM UTC

stutonk wrote: post #42

gnulinux wrote: post #27

Earlier quoted context omitted.

Eh, syntactically it hides the state as in `f x` has the same value every time, but calling functional programming stateless is a stretch, I consider it a half-truth told the newcomers to understand the concept. Functional languages still have state but they're abstracted out to function call. E.g. if you have a recursive descent parser written in Haskell, your program will still have state, not every time you're in…

In addition, every closure is also a 'state container,' as it were. This is how some functional languages e.g. Erlang emulate mutation. A function holds the desired state in a closure and evaluates to a new function closure with updated state. It's also how a stateful object system can be trivially implemented in Scheme. A few of pieces of the Erlang OTP infrastructure are actually just an elaborate mechanism to rein…

You can use closures to store state in Erlang, but generally state is kept by passing it through to further function calls.

I would say this makes Erlang mostly have explicit state, rather than saying Erlang is stateless.

Ets is implemented in C as global mutable state, but you could implement it in Erlang as a process per table (and a process to hold the list of tables) with no loss of functionality. You would send messages to fetch data or update data, etc. It's a performance and memory efficiency optimization to do it with C, of course.

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

#74

Post by benrbray » Sat, Oct 24, 2020, 6:06 PM UTC

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…

Functional programming languages, more often than not, distinguish themselves with some combination of the following features:

* First-order functions

* Partial function application / currying

* Type inference

* Algebraic data types

* Typeclasses

* An emphasis on pure functions (side effects must be explicitly annotated), opening up more possibilities for static analysis

* Lazy evaluation

This is not to say that the above features cannot be emulated by other languages. For instance, Rust has traits, which serve more or less the same practical purpose as Haskell typeclasses.

However, FP is designed to prioritize the above features, whereas other languages may not be.

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

#75

Post by yowlingcat » Sat, Oct 24, 2020, 6:07 PM UTC

mattgreenrocks wrote: post #63

scarmig wrote: post #49

Earlier quoted context omitted.

Even if it's suboptimal from a technical standpoint, a company that went all in on an HTML/JS Frankenstein is likely to have seen more success than one that went all in on a more appropriate native desktop client. There's a reason we see a lot of the former and not much of the latter.

How do you argue that based on technical choices alone? Seems quite reductive.

It's lowest common denominator thinking, which isn't necessarily wrong. If the majority of cross-platform UI code is done in HTML/JS and the toolchain is mature, that becomes the default choice and you would need a compelling reason to not use it. And that has generally been my anecdotal experience.

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

#76

Post by jamil7 » Sat, Oct 24, 2020, 6:08 PM UTC

qsort wrote: post #47

shaan7 wrote: post #30

Earlier quoted context omitted.

> how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That is a double-edged sword. On one hand it makes sense because it allows teams to be more productive. Otoh, it leads to this decade where it has become okay to create a desktop application using HTML/JS (while more performant tooling exist) simply because a lot of people happen to know HT…

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 they can.

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

#77

Post by IshKebab » Sat, Oct 24, 2020, 6:09 PM UTC

andi999 wrote: post #55

eyelidlessness wrote: post #45

Honestly I think this conclusion comes more from lack of familiarity with how people solve similar problems with FP than anything. For example, in the author’s followup post: All you have to do is pass the world state to each function and return a new state. True, yes, but...yuck. It can be clunky in a language with single-assignment. And what is this really gaining you over C? I mean, if you stop there, sure that’s…

I dont understand this. This has the same disadvantages as global variables: every function (that has the state) can change it.

Right but global variables are implicit. Function inputs/outputs are explicit. Another advantage is testing.

That said, I still think passing the world in and out of every function is too onerous for most real world programs, and functional programming definitely takes a too-extreme stance to be pleasant.

I think a better approach is a traditional language but with a functional subsystem where you can mark functions as pure.

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

#78

Post by kazagistar » Sat, Oct 24, 2020, 6:15 PM UTC

stutonk wrote: post #42

gnulinux wrote: post #27

Earlier quoted context omitted.

Eh, syntactically it hides the state as in `f x` has the same value every time, but calling functional programming stateless is a stretch, I consider it a half-truth told the newcomers to understand the concept. Functional languages still have state but they're abstracted out to function call. E.g. if you have a recursive descent parser written in Haskell, your program will still have state, not every time you're in…

In addition, every closure is also a 'state container,' as it were. This is how some functional languages e.g. Erlang emulate mutation. A function holds the desired state in a closure and evaluates to a new function closure with updated state. It's also how a stateful object system can be trivially implemented in Scheme. A few of pieces of the Erlang OTP infrastructure are actually just an elaborate mechanism to rein…

Pure functional languages, aka Haskell or Idris or whatever, don't have this property. A closure closes over values, and thus is a value, no state mutation involved.

Of course, your point about complex mechanisms to reintroduce mutation into specific contexts stands (usually via monads) but those are a very different Kind of object then the functions.

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

#79

Post by kazagistar » Sat, Oct 24, 2020, 6:19 PM UTC

lacker wrote: post #41

mannykannot wrote: post #28

Earlier quoted context omitted.

Before reading this article and its follow-on, I would have completely endorsed the view that global mutable state is the worst, but for the sorts of issues the author is writing about, it seems that global mutable state is precisely the thing that makes procedural solutions more straightforward. In this case, it seems to be an intuitive and straightforward model for how both the programmer and player view the proble…

The only thing worse than global mutable state is a complicated and buggy structure that does the exact same thing that global mutable state does

It makes the most sense to me to default to immutable, but swap to mutable when appropriate.

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

#80

Post by Twisol » Sat, Oct 24, 2020, 6:19 PM UTC

IshKebab wrote: post #77

andi999 wrote: post #55

Earlier quoted context omitted.

I dont understand this. This has the same disadvantages as global variables: every function (that has the state) can change it.

Right but global variables are implicit. Function inputs/outputs are explicit. Another advantage is testing. That said, I still think passing the world in and out of every function is too onerous for most real world programs, and functional programming definitely takes a too-extreme stance to be pleasant. I think a better approach is a traditional language but with a functional subsystem where you can mark functions…

> That said, I still think passing the world in and out of every function is too onerous for most real world programs [...]

This is a bit of a strawman. At least in my limited experience, functional programmers think so too. Part of what monads let you do is a kind of inversion of control: instead of changing the world directly (as you would if you were seriously threading the world through your domain logic), you return a description of what you're doing, and let the runtime (in the case of IO) or the interpreter for the monad (in other cases) actually perform the changes.

Similarly, lenses allow you to describe local mutations and lift them to the level of a whole structure.

Explicitly threading your state is the first refactoring, not the final destination. If you have a code smell, the first thing to do is draw it out into the open so you can wrangle it. In languages that don't conveniently support functional strategies like monads or lenses, it's tempting to stop there. But that doesn't mean FP is about stopping there.