Is functional programming the best way to write GUI code?

Why are people so afraid of OOP? I understand it makes some things harder to read/follow in the moment, but if there is any complexity in the system functional programming seems like a fucking nightmare desu.

Functional programming has always seemed silly to me.

Like I can understand engineers and scientists using it for numerical analysis of equations but for literally anything else it seems like pure cargo cult cope. They should know by now that engineers and scientists don't give a shit about their matlab/julia/spark scripts or whatever after the svg has been exported and put in the latex doxument. And no, software developers are NOT engineers. They do not have the same training, and they cannot deliver the safety and secure the evidence of safety like engineers can.

>>105934718 (OP)
Functional programming is probably the worst way to do GUI
GUIs are by definition stateful unless you're doing something super basic like a dialog box. Funtional programming tries to be as stateless as possible

>>105934718 (OP)
functional programming is the worst way to make a program with complex state like GUI or game.

>>105935039
you don't seem to know what it is

>>105934718 (OP)
I just do react way, don't care about the pseudo science like functional, procedural, oop, data driven, etc

>>105934718 (OP)
>+= in initializer
kiiiiinoooooo

>>105934718 (OP)
That is not functional it's more like OOP + declarative.

>>105934718 (OP)
>import scala.swing._
>compared to import java.swing.*;
>mfw scalaniggers use _ instead of *

>>105934718 (OP)
Depends on the approach.
Functional programming makes most sense for immediate mode gui.
OOP makes most sense for retained mode gui.

This is not OOP, it's composition using objects. OOP is about sending messages between objects

>>105934718 (OP)
dynamic languages are the best

>>105934718 (OP)
ahhh, functional programming. where people would rather write a 150 line ungodly mess with 3 layers of recursion that performs like shit instead of solving the problem by writing 5 lines and introducing a tiny bit of state. all the faggots glazing fp right now who never even used it will be in for a rude awakening when it becomes mainstream.

>>105938382
But it's OOP where you write 1500 lines of ungodly mess with 3 layers of SingletonBeanFactory. FP generally gives you very succinct, but difficult and abstract code.

>>105938464
FP performs horribly on any program which makes generous use of states.
One bright exception is the more pragmatic OCaml which also supports loops, and Scala.

>>105934718 (OP)
>nested 5 deep
NGMI

>>105938464

OOP can be as simple as you want it to be. Don't blame the overengineering overabstracting faggots for making it worse with their conventions. You can make OOP very tight and simple while still being intuitive.

>>105938566
Pure FP sure. But you don't even have to go full OOP like OCaml, Rust is a good example on how to use FP style in performant way. It was inspired by OCaml too.

>>105938590
Of course you can do it sanely. I'm just saying that the implication that FP typically produces more code than OOP is just plainly wrong, it's the other way around. OOP comes with unavoidable declarations that generally take quite a lot of LoC, while FP can often be reduced to absurdly small sizes.


Pro tip: the current meta is to use OOP to structure your data/responsibility and FP to express how to manipulate that data.

>>105938647
Sure, but Rust has that disgusting borrow checker

>>105938664
That's completely irrelevant to the conversation.

How similar is reactive programming to functional? Everything frontend seems reactive these days

>>105938464
i never said i'm an OOP fag. procedural code is the only one that makes sense

>>105936764
fucking this.

Functional programming is just for prototying and thats it.

>>105938692
It's not very similar to actually writing functional programming, but it can(but doesn't have to) be built on top of functional concepts like React hooks.

what no one seems to understand that both fp languages and rust are trying to solve the same problems that arise from shared mutable state.

fp tries to solve it by eliminating the mutable part while rust tries to solve it by eliminating the shared part. in the meantime OOP is playing in the puddle next to them like a child giggling and declaring they already solved the problem by smearing state all over your screen.

also rust is procedural not fp

>>105938762
rust is also gay and unneeded

>>105938840
let me guess, OOP nigger...

>>105938840
People have been begging for a C++ alternative for decades.

Dont care about OOP. Tired of hearing about Rust. Shitty thing

>>105938864
>People

Retards and trannies aren't people.

>I am tired of hearing about Rust
>so I am going to incite a discussion about Rust

>>105938880
These "retards" design C++.

>>105934718 (OP)
Functional programming is not well suited for GUI code because in GUIs, things are SUPPOSED to have side effects. However, for small, local calculations, functional is okay.

>>105934718 (OP)
>functional programming
>picture of scala
nice b8
>>105938908
>Functional programming is not well suited for GUI code
Is that why most ui toolkits are declarative or provide a declarative flavor?
>things are SUPPOSED to have side effects.
>le functional means NO side effects maymay xdd
Face the truth: imperative & OO bloat is THE problem with GUIs with all the nulls, side effect poop flinging, and inheritance bloat

>>105936383
Scala would be so much better outside the JVM
>no slow comp time
>no leaky abstractions
>no half-baked/humiliation ecosystem using java-focused libs

>>105939892
If something has side effects it is not a function — it is a method or a procedure.

Procedural programming will just keep winning forever, sorry hipster–paradigm fags.

>>105939959
So this is your brain without moan ads.

>>105940042
All the most important software in the world is procedural — with perhaps a pseudo object–oriented system bolted–on.

>>105938908
>QML
>Glade
>flutter
>jetpack compose
>most famous web UI frameworks
Imperative bros, it's ove-NullRef[Segmentation fault]

>whole thread is retards not knowing the difference between functional programming and pure functions
every time i come back to this board it reminds me how retarded the average programmer actually is

>>105939959
>If something has side effects it is not a function
i'm not a mathematician, i don't use their intentionally gimped definitions of shit. go back to the blackboard, grandpa.

>>105940117
I gave up 4 years ago when some mouthbreather trying to prove a point with a shitty script that piped see into itself 5 time. When you have like three ways of doing the same task better and one of them is using the -e builtin avilable on pretty much every system from the last 18 years still operating today.

>>105940117
I know the difference and I for one say it is bullshit. Play semantics all you want — you're still wrong.

>>105940139
Sorry but you're using procedures — you're a procedural programmer kiddo.

>>105940232
tried* to prove a point with a sed script. I'm half assing even redacting a paragraph.

>>105938905
Indeed, look at how poorly C++ is designed.

>>105934787
We aren't afraid of it. We just realize it is almost always a waste of time.

>>105934718 (OP)
Is there anything like this for C# and for C++?

>>105934718 (OP)
imgui is the best way if you dont care about muh styling

>>105940316
This. ~90% of the benefits of OO can be had with simple structs.

>>105940299
And now you understand why Rust is needed and why people wanted an alternative.

>>105940330
Please don't use C# for product UI unless you have an internal tool or windows-only view
The best they have is blazor on MAUI aka .net on WASM on webview on .net on glue to host OS
Anything can break if use MAUI alone so forget about MVU solutions.

>>105938647
Rust's FP abstractions are only fast because the Rust compiler knows how to convert those abstractions back to imperative style code. Stray outside the abstractions Rust provides and see how well it performs.

>>105934787
The only benefit to I see from OOP is containerizing thing. I do this with structs and c files making OOP obsolete.

>>105940643
Isn't Rust failing in every area that it claims to be made for? Last I checked it was pretty much dead in embedded with only a few niche products using it because no one wanted to rewrite decades of C libraries/drivers/etc etc in Rust and Rust compiler only really supporting x86 and arm as first class targets. Linux kernel devs had a meltdown with only one or two trannies willing to use it who have now quit meaning no one is really using Rust anymore. MS is using it in some areas for windows but none of the big, commonly used API's are being changed over from C to Rust and modern Windows is basically dead because of a bunch of buggy ai slop being pushed and with shit like the UI being re-written in fucking javascript of all things. It is doa in game dev because it turns out games require a lot of shared state. The biggest compiler re-written in Go because it turns out shared state and circular datastructures are useful in compilers, something Rust can't do without jumping through a bunch of hoops. The only area Rust has seemed to taken off in is in making Rest API's / crud apps and it isn't really Rust but Rust + 3rd party runtime which bastardises the language and makes it something akin to typed Javascript. It's a far cry from being a C++ replacement, more like a Java/C# replacement/Typescript replacement. It seems Rust looks like it's a good idea on paper but as soon as it's used for anything remotely complex with any sort of complex state, the language is unable to make any sort headway into that area of programming.

>>105940707
>structs and c files
That's basically OOP

>>105940879
What is your definition of OOP? What are the main characteristics of it in your opinion?

>>105940701
That's literally why I said
>Rust is a good example on how to use FP style in performant way

>>105940860
>Isn't Rust failing in every area that it claims to be made for?
It's used in every relevant OS, even in Android. A lot of large companies use it in production. It seems pretty successful for me.

>Last I checked it was pretty much dead in embedded
Embassy seemed to be quite a hot topic recently.

>Rust compiler only really supporting x86 and arm as first class targets
Rust supports much more than this. x86 and arm are first tier meaning that it gets automatically tested on that hardware. Compilers like GCC are not automatically tested on any other architectures as well, so their support is more like Rust's tier 3 support. Even Linux doesn't get automatically tested on any hardware upstream and it's downstream responsibility to detect and report issues.

>Linux kernel devs had a meltdown with only one or two trannies willing to use it who have now quit meaning no one is really using Rust anymore
The drama only involved Hector and some C boomer. Both of them quit in result. Hector was never essential to Rust for Linux, he was just working on the GPU driver for some apple shit and joined Linux after R4L was already in works.

>MS is using it in some areas for windows but none of the big, commonly used API's are being changed over from C to Rust
C ABI is the standard way of doing FFI. No matter if you write in C, C++ or Rust, you are going to use C ABI for FFI because this is the only stable ABI of the three and it's simple. Even if you are not using C directly. This has very little to do with practical differences in language, it's a common convention. These Windows APIs probably do not use C but C++ or some other Microsoft invention behind the FFI interface.

>>105940860


>It is doa in game dev because it turns out games require a lot of shared state
This is not a problem in practice. It's trivial to share state in Rust. Lifetimes even ensure that you are not causing UB by doing so.
The reason why Rust is not good for gamedev is because it heavily favors waterfall approach. It is not a flexible language that you can quickly prototype shit in, And quick prototyping and iteration is essential for gamedev.
Rust never claimed to be designed with gamedev in mind. If you want a language made for gamedev, look at Lua, Squirrel, GDScript, etc. They are very different from systems programming languages like Rust or C++.

>The biggest compiler re-written in Go because it turns out shared state and circular datastructures are useful in compilers
Since when GCC has been rewritten in Go? What are you even talking about.

>something Rust can't do without jumping through a bunch of hoops
It is easy to write shared state and circular data structures in Rust. You do that in the same way you would do in C or C++.

>The only area Rust has seemed to taken off in is in making Rest API's / crud apps and it isn't really Rust but Rust + 3rd party runtime which bastardises
I don't recall any popular Rust based project related to Rest APIs. CLI tools, encoders, compression libraries, desktop software seems to be more popular.

>It's a far cry from being a C++ replacement, more like a Java/C# replacement/Typescript replacement
Rust is a systems programming language. It's not a replacement for a managed languages like Java/C#/Typescript.

>It seems Rust looks like it's a good idea on paper but as soon as it's used for anything remotely complex with any sort of complex state, the language is unable to make any sort headway into that area of programming.
I wrote quite some programs in Rust, including a game engine and never had any problems with complex state.

What exact problems did you actually had with complex state in your program?

>>105940933
Objects that can be instantiated that have methods.

>>105941223
Concurrently working on arrays where you have to give each thread a section of each array to work on without incurring additional copies. As far as I can tell even something as simple as doing vector math without copies requires jumping through a bunch of hoops. In C you can just spin up a thread and have it work on the section you hand it while other threads work on sections and have it updated in place. In Rust you have to prove those threads can't overlap thus requiring extra copies or moving parts of the array in and out of the original data structure/doing the work sequentially/using a third party library to do it for you. I've had people throw a bunch of examples at me how to do it on here, calling me retarded etc like you're insinuating and Rust, every single time tells me it's breaking borrowing/ownership rules. It always needs a copy or some sort of wrapping in a smart pointer which means I might as well use Go, have a better garbage collector than basic bitch reference counting and get access to green threads.

>>105941341
>Concurrently working on arrays where you have to give each thread a section of each array to work on without incurring additional copies
Pic related.

>As far as I can tell even something as simple as doing vector math without copies requires jumping through a bunch of hoops
impl Vector {
fn add_assign(&mut self, other: &Vector) {
self.x += other.x;
self.y += other.y;
self.z += other.z;
}
}


>In C you can just spin up a thread and have it work on the section you hand it while other threads work on sections and have it updated in place. In Rust you have to prove those threads can't overlap thus requiring extra copies or moving parts of the array in and out of the original data structure/doing the work sequentially/using a third party library to do it for you.
Pic related.

>t always needs a copy or some sort of wrapping in a smart pointer which means I might as well use Go, have a better garbage collector than basic bitch reference counting and get access to green threads.
Pic related.

>>105941412
You're not doing any work.

>>105941428
Each threads fills it's own section of array with it's id. They all work in parallel and do not take any extra copies or smart pointers or anything. It is sound and supported by std to just split a mutable slice into multiple, non-overlapping slices and it doesn't take any extra runtime checks to do so.

>>105938864
Skill issue. That is how we got Java and trash tier coders everywhere.

>>105941450
ok but you're still not doing any work here on the underlying array. Also .fill() says it clones the passed element which isn't a copy? Also why would I want the ID of the thread here? I want to edit the underlying array.

>>105941489
You are kind of dense, aren't you?

>but you're still not doing any work here on the underlying array
slice::fill is the work here. It fills chunk, which is a part of buffer. The buffer is the underlying array and it gets changed, look at the print.

>Also .fill() says it clones the passed element which isn't a copy?
It's a memset.

>Also why would I want the ID of the thread here? I want to edit the underlying array.
It's called an example. By each thread filling their own chunk of underlying array, this example shows that it is possible to "give each thread a section of each array to work on without incurring additional copies", which is what you asked about.


Jfk, how did you even found your way to /g/

>>105941412
WTF, one second to compile a dozen lines of code that is not even optimized? Holy shit, rust compilation is slow AF!

>>105941524
It's being compiled inside the browser though. I don't have the code anymore to test it natively though.

>>105941519
>Jfk
I mean jfc. It's too late for me, I need sleep.

>>105941519
Fill
>Fill self by cloning value.
I guess the documentation is wrong?

I got into functional programming cause of how delightful it was to do frontend with Elm which is essentially GUI.
MVU/TEA is great, I've ported the pattern to TypeScript in case I'm forced to use it. Moved on to PureScript and then to Haskell. Miso is looking fine these days.

>>105941587
We had this very conversation already.
Do you understand how memset works?

>pic
You are mutating the same vector(data.a) which you are using to calculate maffs in other threads. None of this is atomic. This is an undefined behavior and Rust caught it.
Even if you use atomics, the output is going to be nondeterministic, you have to rethink your algorithm. You probably want to do a copy or precalculate maffs before mutating the array.

>>105941665
Ok so Rust does need to do extra copies. That was my original point. Thank you for admitting it and we are now on the same page.

>>105941534
IIRC, that's not compiling inside a browser. That's compiling inside a VM that's accessible from a web app.

>>105941673
Holy retard

>>105941693
You keep moving the goal posts. Do this concurrently, in place or fuck off and admit you're a ingenious rust shill who has an agenda. This is basically your code and it doesn't work lol.

>I am going to shoot straight down
>*warning, feet is in the way*
>shitty gun, I do not have to move my feet to shoot my other guns

>>105941719
You can do maffs on the chunk, but you can't do it on the data you took the chunks off of.

>>105941735
>Does not address the point
>Doesn't post code
>Resorts to story telling and ad homiem to score points
I can't wait to see your game engine.

>>105934718 (OP)
>scala.swing

>>105941719
struct Data {
a: Vec<usize>,
b: Vec<usize>,
c: Vec<usize>,
}

fn maffs(a: &[usize], b: &[usize], idx: usize) -> usize {
return a[idx] * b[idx];
}

fn update(data: &mut Data) {
use std::thread;

thread::scope(|s| {
let &mut Data { ref b, ref c, ref mut a } = data;

for (id, chunk) in a.chunks_mut(4).enumerate() {
s.spawn(move || {
chunk.fill(maffs(b, c, id));
});
}
})
}

>>105941826
Wow you're the first person to give me a working answer after months of going tit for tat with Rust faggots over this and them giving me non working example after non working example. Thank you.

>>105941880
Well, probably because your initial code was straight up, unsalvageable undefined behavior in any language. You can't read and write to the same memory location from different threads and not have at least non determinism or UB. It wasn't even matter of splitting the array, your first thread was writing to the same exact location from which threads 2-4 were reading from(data.a[1..4]).

>>105934718 (OP)
Take a look at xmonad/haskell and get back to us.
https://github.com/xmonad/xmonad/tree/master/src/XMonad

>>105940933
OOP is when class invariants are the primary method of proving semantic correctness.

>>105941931
No the code wouldn't compile because data being moved. The compiler was telling me the problem was the same when I removed access to the array we are mutating. The &mut data {ref...} solves the problem but yes the code was bad. I meant to pass another index for A to ensure unique access to the element.

>>105940933
I go by Alan Kay's definition

>>105934718 (OP)
Im not a programmer. What's the difference? I languages have functions.

>>105943548
all

>>105934718 (OP)
I always thought the old school VB was the best for UI. Object based, but not OOP.

>>105934787
Inheritance is why OOP is bad

>>105934718 (OP)
Yes.