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

Why Isn't Functional Programming the Norm? [video]

youtube.com

Post reply on HN
Print view View original

201–210 of 417 posts

Re: Why Isn't Functional Programming the Norm? [video]

#201

Post by ansible »

grumpyprole wrote: post #192
Scarbutt wrote: post #181

Earlier quoted context omitted.

I would say "real time graphics" is one of the niches FP is not well suited for, most business software doesn't need to work at the level of the machine.

There is certainly prior art for complex games running smoothly in Haskell: https://wiki.haskell.org/Frag This particular solution used functional reactive programming, essentially a composition of signal/event processing functions/automatons.

Ten years ago, that was the only substantial game written in Haskell. That you're citing that same game now is a bit telling.

Note the upload date:

https://www.youtube.com/watch?v=0jYdu2u8gAU

Re: Why Isn't Functional Programming the Norm? [video]

#202

Post by tome »

Symmetry wrote: post #132
tom_mellior wrote: post #96

Earlier quoted context omitted.

The "oh no it's slow, and you can't reason about performance" FUD is mostly directed at Haskell's lazy evaluation, but people like to throw it vaguely in the direction of "FP" in general. Most of the performance problems you have in Haskell (as in this recent submission: https://news.ycombinator.com/item?id=21266201 ) are not problems you will have in OCaml. Yes, OCaml has garbage collection. It's a very efficient GC…

Something I've always wondered about Haskell. Given referential transparency, purity, etc shouldn't it be possible for the Haskell compiler to choose whether to evaluate something in an eager or lazy fashion depending on performance heuristics under the covers? You have to make sure you don't ever accidentally do that with an infinite list but it seems that there ought to be lots of scope for optimization and speedin…

Yes, it's called strictness analysis and is an important part of the GHC pipeline.

Re: Why Isn't Functional Programming the Norm? [video]

#203

Post by weberc2 »

StreamBright wrote: post #193
weberc2 wrote: post #122

Earlier quoted context omitted.

I use VS Code too, but dynamic typing means I have to deal with this sort of thing every day: https://mobile.twitter.com/weberc2/status/118275131245637632... Compared with, say, Go where I just hover the cursor. As for pip, you also need virtual environments to protect you from side effects, and even then, if you’re doing C interop you probably still have dynamic links to so files outside of your virtualenv. Our team…

>> Go is probably the best in class here Sorry no offence but I do not want to write Go at all. If I want to use such a language I will use Rust with nicer features and better out of the box performance (see TechEmpower results), no GC and more safety (no memory corruption bugs or data races). I am not sure if I am the one who paints himself into a corner.

Go for it (why would I take offense?). Rust is a fine choice. I'd pick Rust if I ever really needed to eek out every bit of performance out of my system and/or needed safety and was willing to trade quite a lot of developer productivity to get there. Mission critical real-time systems, high-end games, resource-constrained devices, etc are good applications for Rust (and of course there are many others). Rust is a great language and I'd like to use it more often; I just can't justify the productivity hit.

If Rust ever approaches Go's ease of use/learning curve/etc without losing its performance or incurring other costs, I'll happily make the switch for my productivity-sensitive applications as well.

Re: Why Isn't Functional Programming the Norm? [video]

#204

Post by soulofmischief »

AnimalMuppet wrote: post #191
soulofmischief wrote: post #147

Earlier quoted context omitted.

> In any case the point is this: I had some straight imperative code that was doing the same thing several times. In order to make it generic I couldn’t just introduce a loop around the repeated code, but I had to completely change the control flow. There is too much puzzle solving here. In fact I didn’t solve this the first time I tried. In my first attempt I ended up with something far too complicated and then just…

"It doesn't fit the way I think" != "I'm too stupid or lazy to figure it out". And why should s/he do so? Between the language and the programmer, which one is the tool? Should not the tool fit the human, and not the other way around? FP fits the way some people think. It doesn't fit the way others think. And that's fine. It's not a defect that some people think that way, and it's not a defect that some people don't.

I think the whole conversation is silly; FP is another tool in my toolbox. Yes, with some effort I can accomplish most jobs with a crowbar, but why would I do that?

Re: Why Isn't Functional Programming the Norm? [video]

#205

Post by McWobbleston »

BrissyCoder wrote: post #23

People at the places I work keep memeing links to blog posts along the lines of "OOP is dead. Functional programming is the new king". Yet to see a single line of a functional language in production. As other commenters have mentioned most decent modern lanuages are multi-paradigm.

Jet.com

https://medium.com/jettech

Re: Why Isn't Functional Programming the Norm? [video]

#206

Post by catalogia »

Borkdude wrote: post #3
onion2k wrote: post #2

JavaScript isn't a functional language itself, but you can use a functional library like lodash/fp ( https://github.com/lodash/lodash/wiki/FP-Guide ) on top of it to get all that lovely functional goodness in your frontend and node code. Using lodash/fp has made my frontend state management code a lot nicer, and I'm really only just starting out with it.

The video explains how JavaScript started out as a Scheme-dialect (Lisp) but for marketing reasons they chose a more Java-like syntax and adopted Java into the name.

Javascript falls short of scheme in ways more substantial than java-like vs s-expression syntax. It also has one of the worst numerical towers ever put into a language (that being: "lmao everything is a float".) Also, "function-scope" is an abomination compared to proper lexical scoping.

Edit: I forgot to also mention: weak typing was an awful idea.

Re: Why Isn't Functional Programming the Norm? [video]

#207

Post by shadowgovt »

tick_tock_tick wrote: post #158
bryanphe wrote: post #143

Earlier quoted context omitted.

In terms of performance, the way we build applications today is such a low bar that IMO it opens the door for functional programming. Even if it is not as fast as C or raw assembly - if it is significantly faster than Electron, but preserves the developer ergonomics... it can be a win for the end user! I created an Electron (TypeScript/React) desktop application called Onivim [1] and then re-built it for a v2 in OCam…

They already said they were working in games. None of what you said applies to that field.

I have a suspicion this is only semi-true.

For controlling what the CPU and RAM are doing? Yes. The graphics shader, on the other hand, is a pipeline architecture with extremely tight constraints on side-effects. The fact the shader languages are procedural seems mostly accident of history or association to me than optimal utility, and the most common error I see new shader developers make is thinking that C-style syntax implies C-style behaviors (like static variables or a way to have a global accumulator) that just aren't there.

The way the C-style semantics interface to the behavior of the shader (such as shader output generated by mutating specifically-named variables) seems very hacky, and smells like abstraction mismatch.

Re: Why Isn't Functional Programming the Norm? [video]

#208

Post by yogthos »

tick_tock_tick wrote: post #158
bryanphe wrote: post #143

Earlier quoted context omitted.

In terms of performance, the way we build applications today is such a low bar that IMO it opens the door for functional programming. Even if it is not as fast as C or raw assembly - if it is significantly faster than Electron, but preserves the developer ergonomics... it can be a win for the end user! I created an Electron (TypeScript/React) desktop application called Onivim [1] and then re-built it for a v2 in OCam…

They already said they were working in games. None of what you said applies to that field.

Here's a talk on making real world commercial games with Clojure on top of Unity.

https://www.youtube.com/watch?v=LbS45w_aSCU

Re: Why Isn't Functional Programming the Norm? [video]

#209

Post by yogthos »

chubot wrote: post #190
js8 wrote: post #142

Earlier quoted context omitted.

> FP will always occupy a niche because of where it sits in the abstraction hierarchy At some point in history, people stopped worrying about not understanding compilers, how they allocate registers and handle loops and do low-level optimizations. The compilers (and languages like C or C++) became good enough (or even better than humans in many cases) in optimizing code. The same happened with managed memory and data…

Programming is has grown so much as a field that generalizations like this rarely capture the truth. It's true that in many domains, people care much less about performance than they used to. At the same time, other people care a lot more about performance. Programming is just big and diverse. The end of single score scaling is one big reason it's more important than ever. Another reason is simply that a lot more peo…

The point here is that for many domains performance is not the top consideration. And it's also worth noting that it's perfectly possible to tune applications written in FP languages to get very good performance. It's also possible to identify the parts of the code that are performance critical and implement those using imperative style. This is especially easy to do with Clojure where you have direct access to Java.

So, yeah if you're working in a niche domain where raw performance is the dominant concern, then you should absolutely use a language that optimizes for that. However, in a general case using FP language will work just fine.

Re: Why Isn't Functional Programming the Norm? [video]

#210

Post by undershirt »

Crinus wrote: post #172
journalctl wrote: post #164

Earlier quoted context omitted.

Unless you’ve written a modern, optimizing C/C++ compiler, you have absolutely no idea what kind of machine code a complex program is going to spit out. It’s not 1972 anymore, and C code is no longer particularly close to the metal. It hasn’t been for some time.

This is wrong, you absolutely can have an idea of what a C (and most of the time, C++) compiler will generate. You may not know the exact instructions, but if you are familiar with the target CPU you can have a general idea what sort of instructions will be generated. And the more you check the assembly that a compiler generates for pieces of code, the better your idea will be. Note that you almost never need to care…

From: https://queue.acm.org/detail.cfm?id=3212479

> Compiler writers let C programmers pretend that they are writing code that is “close to the metal” but must then generate machine code that has very different behavior if they want C programmers to keep believing that they are using a fast language

Post reply on HN