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

141–148 of 148 posts

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

#141

Post by yoyonamite »

chowells wrote: post #131
kkdaemas wrote: post #124

Earlier quoted context omitted.

Order of execution bugs rarely come up in game programming to be honest.

If that's true, why is it an issue John Carmack discusses as affecting difficulty of writing games that work correctly in modern environments? > When you start thinking about running, say, all the characters in a game world in parallel, it starts sinking in that the object-oriented approach of updating objects has some deep difficulties in parallel environments. Maybe if all of the object just referenced a read only…

Games usually don't run the characters in parallel for the reasons Carmack stated. I believe he's arguing a hypothetical: if we want to maximize parallelization, what else can be parallelized? What patterns would or would not work in that case?

There was a talk by Carmack where he brings up another challenge with parallelizing characters where two characters want to move to the same location.

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

#142

Post by chriswarbo »

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" is a useful description for techniques/approaches. The unifying principle tends to be (a) semantics based on definition and substitution of values/expressions (e.g. no ambient state/context) and (b) 'direct' evaluation strategy for expressions (e.g. no search, like in logic programming).

"Functional language" is less concrete; it's just an informal way to imply how easy or awkward it is to use these techniques in a particular language (e.g. bash is "less functional" than ML).

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

#143

Post by dvfjsdhgfv »

pizza234 wrote: post #109
jamil7 wrote: post #76

Earlier quoted context omitted.

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

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

That's a part of the problem. We're so used to web apps that many of us just learned to live with constant delays and simply treat it as a part of our lives.

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

#144

Post by chowells »

yoyonamite wrote: post #141
chowells wrote: post #131

Earlier quoted context omitted.

If that's true, why is it an issue John Carmack discusses as affecting difficulty of writing games that work correctly in modern environments? > When you start thinking about running, say, all the characters in a game world in parallel, it starts sinking in that the object-oriented approach of updating objects has some deep difficulties in parallel environments. Maybe if all of the object just referenced a read only…

Games usually don't run the characters in parallel for the reasons Carmack stated. I believe he's arguing a hypothetical: if we want to maximize parallelization, what else can be parallelized? What patterns would or would not work in that case? There was a talk by Carmack where he brings up another challenge with parallelizing characters where two characters want to move to the same location.

So... Most games ignore modern hardware capabilities in order to support a fragile programming model? That doesn't sound like an argument against my point. My point was that mutation makes it harder to get code correct. If the only way you can do it is by refusing to use more than one thread of execution for calculating game state updates, that's not evidence that there's no problem with that approach.

Of course, this does vary heavily by game. There certainly are games that run their world simulation across multiple threads. https://twitter.com/axelgneiting/status/1241487918046347264 is a pretty awesome note about that in the Doom Eternal engine, for instance. But I'm certain getting that to work required very carefully controlling when and how mutation happens.

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

#145

Post by jamil7 »

dvfjsdhgfv wrote: post #143
pizza234 wrote: post #109

Earlier quoted context omitted.

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

> 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). That's a part of the problem. We're so used to web apps that many of us just learned to live with constant delays and simply treat it as a part of our lives.

Thing is, I'm not advocating for performance over functionality or premature optimisation. We're talking about text editors here, as an industry we've done this before, we can write a fast cross-platform text editor, it feels like we've either forgotten this or don't care.

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

#146

Post by IshKebab »

Twisol wrote: post #140
IshKebab wrote: post #139

Earlier quoted context omitted.

You still have to pass your logging code to every function that does logging right? And if you add logging to a function deep in your call stack you have to go all the way up the stack adding it as a parameter everywhere. It's rigorously correct, but I feel like it's a step too far for most programs.

> You still have to pass your logging code to every function that does logging right? Yes, but no. Again, there are functional patterns you can apply. First, functional programs tend to be more horizontally composed than vertically. Side effects usually happen at the same "level" of the application, rather than occuring at multiple depths. So the need to thread logging apparati is already reduced, simply because logg…

> because logging only happens higher up in the application.

But... what if I don't want it to? You can't have logging higher up in the stack if you want to log stuff low down in the stack.

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

#147

Post by Twisol »

IshKebab wrote: post #146
Twisol wrote: post #140

Earlier quoted context omitted.

> You still have to pass your logging code to every function that does logging right? Yes, but no. Again, there are functional patterns you can apply. First, functional programs tend to be more horizontally composed than vertically. Side effects usually happen at the same "level" of the application, rather than occuring at multiple depths. So the need to thread logging apparati is already reduced, simply because logg…

> because logging only happens higher up in the application. But... what if I don't want it to? You can't have logging higher up in the stack if you want to log stuff low down in the stack.

I'm having a hard time reading your question as anything other than "But what if I want to not do functional programming?" As stated, functional programs tend to be shallower. There's less "higher" and "lower" to begin with.

I've written plenty -- I'm not interested in responding to potshots every time.

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

#148

Post by shaan7 »

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

Thank you for recording these <3
Post reply on HN