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

411–417 of 417 posts

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

#411

Post by cztomsik »

bryanphe wrote: post #143
_han wrote: post #30

The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…

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…

Hey, and good luck with revery :) I am doing something very similar but I wouldn't ever consider any GC language for the low-level part.

I want to write UI in javascript because it's really nice language for prototyping but I also want it to be fast and javascript is unpredictable. Now, this might not be the case with OCAML but no matter what optimizations your compiler (or JIT interpreter) can do, you're still living in a lie, it's still some abstraction which is going to leak at some point.

I've recently removed quite a lot of rust dependencies (wrappers) and the speedup is very noticable, it's because abstractions always come with a cost and you can't just pretend you're living in a rainbow world.

BTW: you're not going to get much lower than 50M, cocoa has some overhead (10M IIRC), node has too (20M) and OCaml GC needs some heap too, and if you have any images, you need to keep them somewhere before sending to the GPU and GC to be fast needs to keep some mem around so that allocs are faster than just plain malloc.

BTW2: in rust world, it's common to see custom allocators and data-oriented programming because it starts to get noticeable and this is hard to do if you can't reason about memory.

If anyone is interested too, here's a repo https://github.com/cztomsik/graffiti

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

#412

Post by cztomsik »

hiccuphippo wrote: post #395
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…

Does Revery use a native toolkit (winforms, gtk, etc) or is it also a webview like electron? I've seen a couple of gui toolkits in rust following the Elm architecture and I think it's an amazing idea. It would be great if I was able to create apps like this using something like Qt behind the scenes.

revery does custom rendering on GPU, just like flutter & switfui (and graffiti)

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

#413

Post by blub »

BoiledCabbage wrote: post #394
blub wrote: post #359

Earlier quoted context omitted.

You're simply used to working in environments where technical excellence doesn't exist. In such environments performance is not a big concern, but neither is quality in general...

Over-indexing on performance has nothing to do with technical excellence. It having the the wrong priorities. Saying people who don't optimize for performance don't have technical excellence is just like saying people who don't get all of their program to fit into 32kb don't have technical excellence. Yes it requires skills to get a program to run in such a small amount of space, just like it takes skill to perform d…

Except OP said quite clearly "stopped caring" and "no one cares". Bit of a stretch from that to your over-focusing...

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

#414

Post by dllthomas »

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.

Even assuming that that's true (and it very well may be), the general topicwasn't games, and there are many places where "the norm" in programming as a whole differs from the norm in performance sensitive areas.

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

#415

Post by xamuel »

Hercuros wrote: post #399
jjav wrote: post #211

Earlier quoted context omitted.

Agreed. I arrived at programming through math (B.S. in Mathematics) and have no love for FP. At the end of the day all software (except hobby projects) is mostly about maintaining it. FP adds unnecessary complexity, abstraction and obfuscations. None of those qualities help code maintenance.

Is this view of FP based on actual experience maintaining a non-trivial program written in an FP language? In my experience, FP doesn’t necessarily add a lot of unnecessary complexity. Sure, languages like Haskell are perhaps initially a bit more abstract when learning them, but once you know the basics, you can write pretty straightforward code in it. You can also do crazier things, but there is no need for that in…

>You can also do crazier things, but there is no need for that in most software.

For dev teams of sufficiently large size, a general principle is: whatever crazy things the language allows, someone is going to do and commit into the codebase.

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

#416

Post by htfu »

hyperpallium wrote: post #410
ummonk wrote: post #405

Earlier quoted context omitted.

Well I agree with you that that kind of recurrence (which mathematicians love to use so much, as do some functional programmers who're overly influenced by math) is not very intuitive and frankly is a programming anti-pattern in my view. But I disagree with you that recursion is the essence of fp. For your concrete example, a more functional version of doing that (in Python) would be something like: print("\n".join(a…

> [recurrence] is not very intuitive and frankly is a programming anti-pattern in my view. [...] Reusing the previous step ... should only be done when absolutely necessary Thanks, that's my main concern (fp was just an example). Would you agree the reason it is bad is becase there is more to track mentally in the execution model? (i.e. the intermediate results). I think a complex execution model is problematic in ge…

Well I guess you could say the essence of FP is working recursively without (mostly) thinking of it, and not having to deal with the sort of control flow necessary for either loops or the kind of self-administered recursion you seem to think of.

The .join() taking the iterator in their example is, if you look closer, very much a fold/reduce repeatedly invoking a join of the thus far assembled string, the next part, and \n. Recursion!

Also rather than mutable i/j variables being incremented (albeit implicitly so in your example), generating a list of all numbers on which to run.

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

#417

Post by [deleted] »

_han wrote: post #30

The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…

[deleted]
Post reply on HN