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

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

#91

Post by voodootrucker » Sat, Oct 24, 2020, 6:33 PM UTC

Twisol wrote: post #80

IshKebab wrote: post #77

Earlier quoted context omitted.

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 re…

Thanks, your comment caused me to learn what a lense is.

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

#92

Post by pyrale » Sat, Oct 24, 2020, 6:38 PM UTC

adwn wrote: post #90

dsabanin wrote: post #21

Earlier quoted context omitted.

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

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

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

#93

Post by Izkata » Sat, Oct 24, 2020, 6:38 PM UTC

mannykannot wrote: post #28

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…

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…

There's kind-of a name for it too, it's a variation on blackboard programming, just not specifically for AI: https://en.wikipedia.org/wiki/Blackboard_system

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

#94

Post by m463 » Sat, Oct 24, 2020, 6:39 PM UTC

jcelerier wrote: post #71

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…

> 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

That is interactivity. It thinks along with you.

I really dislike having to use microsoft stuff. No, I don't want to install the app. no I don't want to enable what you think I should enable. No I don't want cortana reading my email messages. No I don't want to use your OTHER product too.

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

#95

Post by Izkata » Sat, Oct 24, 2020, 6:39 PM UTC

imtringued wrote: post #87

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 article didn't talk about global mutable state. Nobody likes global mutable state. Nobody, not even C programmers. If possible mutable state should always be local to a function.

Scroll down to where it talks about the game "Bumbler" - the game environment is global mutable state.

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

#96

Post by elbear » Sat, Oct 24, 2020, 6:40 PM UTC

ImprobableTruth wrote: post #60

cmrdsprklpny wrote: post #15

Earlier quoted context omitted.

My understanding (which there's a good chance is incorrect) is that all code written in Elm has to be in a functional style because the language strictly enforces it; but this enforcement doesn't exist in Lisp and OCaml, so they can be used to write imperative or object-oriented code, as happened in the cases described.

Haskell enforces purity, but you can still write pretty imperative looking code by using monads (e.g. some state monad). I don't think there is any philosophical difference between say int x = foo(); bar(); char y = baz(x); and do x I'd say the true difference is more related to how you describe state change. Imperative is about having a sequential list of instructions that all can mutate global state in some way, wh…

How would you handle state other than passing it around?

The fundamental thing that Haskell and Elm do is that they don't have mutable values. They create a new value from the old one. You never mutate a record the way you mutate a JS object or a Python dict.

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

#97

Post by pyrale » Sat, Oct 24, 2020, 6:42 PM UTC

acdha wrote: post #72

pyrale wrote: post #59

Earlier quoted context omitted.

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.

I have made another comment in this thread where I make a distinction between what people _try_ to achieve, and what tradeoffs they make on the way.

You are right that most functional languages do not have pure and total functions. However, the inspiration they take from is usually the pure/total functions as described above.

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

#98

Post by nerdtime » Sat, Oct 24, 2020, 6:42 PM UTC

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…

The other phenomenon here is that an imperative program with immutable state is isomorphic (exactly the same) as a functional program.

Literally the same thing.

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

#99

Post by dddbbb » Sat, Oct 24, 2020, 6:43 PM UTC

ImprobableTruth wrote: post #60

cmrdsprklpny wrote: post #15

Earlier quoted context omitted.

My understanding (which there's a good chance is incorrect) is that all code written in Elm has to be in a functional style because the language strictly enforces it; but this enforcement doesn't exist in Lisp and OCaml, so they can be used to write imperative or object-oriented code, as happened in the cases described.

Haskell enforces purity, but you can still write pretty imperative looking code by using monads (e.g. some state monad). I don't think there is any philosophical difference between say int x = foo(); bar(); char y = baz(x); and do x I'd say the true difference is more related to how you describe state change. Imperative is about having a sequential list of instructions that all can mutate global state in some way, wh…

I'd say there is quite an important conceptual difference in that the state monad example exactly desugars to pure functional code. Monads give us a good syntax for sequential computation, but this sequentiality is built out of purely functional components.

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

#100

Post by imtringued » Sat, Oct 24, 2020, 6:47 PM UTC

tome wrote: post #48

Can someone with experience of entity component systems (ECS) please chime in? My understanding is that games are not written in the manner that the author says is so easy, rather they are written as pure functions operating on a big table of world state. The world state happens to be mutable for efficiency, but that's an implementation detail. Then again I've never worked with ECS so perhaps this my misconception.

>pure functions operating on a big table of world state

Who told you that? Sure you can simplify it as a function that is operating on a big table but there is no requirement for it to be pure. An attacking Entity A can mutate the HP values in entity B directly.