>literally impossible to do anything useful unless you have a phd in abstract math
no thanks, C is enough
>muh bugs
just don't write bad code.

>>107217606
Top reason is that some asshat at Netscape made Eich remake his Scheme dialect into an object-oriented pseudo-Java abomination. Everyone would have to learn Scheme now if Eich got his way.

Second reason I think is that recursion takes a certain minimum IQ to understand.

Love me for loops. Simple as.

File: images (29).jpg (16 KB, 447x447)

16 KB JPG

>>107217620
Try using an actually good functional language

>>107217620
> C is enough.
If you look at typical C code, it’s usually just a bunch of lower-level functions, held together with simple glue logic.
Just use all those C functions as foreign scheme functions and write all the high level stuff (arguably the actual thing you are trying to achieve) in a high-level language.

>>107217620
can't avoid bugs if your language enforces it, not caring about purity and other things

>>107217752
Rust code’s compiler eliminates bugs, so I’m calling bullshit on that one.

>>107217888
because rust adopted functional approach from haskell and is obsessed with safety

>>107217606
barrier to entry too high
people got half-baked map/filter in their shitlangs and that was enough

>>107217606
i have a conceptual understanding of haskell up to monad transformers (and i love the monad model of i/o), but still have a really hard time reading sufficiently complex haskell code. it's also really tough to reason about algorithmic complexity and more generally about "what exactly the code is actually doing". the clarity bonus for fp really only applies to the most basic code you could write. it's probably higher for lisp family languages with macros where you can bend the language more, but then again these are dynamically typed and highly unsafe languages, so it's not what you mean anyway.

>>107217606
>>107217644
Corporations hate FP since it makes it harder to replace high iq programmers with dumber, cheaper, less educated programmers.

Ideally every SWE should adopt functional programming and try and evangelize it against their pointy haired CTOs will.

>>107217606
It's just not taught anywhere. If I was exposed to it for 20 years I'd probably use it for mundane things too.

Apart from maybe Elixir, its pointless wankery only used in academia

growth of memory consumption when undergoing a serialization/deserialization cycle of data where shared state is lost

>>107217741
Except that what actually happens in practice is that a high-level language has tons of "features" and libraries that can create unnecessary overhead. Even basic stuff like polymorphism can kill your performance if not used properly.

It's ironic that the whole selling point of OO and functional programming language is the supposed ease of development due to abstraction, but in practice pinpointing performance bottlenecks and optimizing code in those is a nightmare. Meanwhile I can look at my "primitive" C code and immediately see what I did like an ape and optimize it, because it's all just pointer arithmetic, loops, and conditional expressions.

>>107217606
It's jeetophobic. Even Scala, made to on-board jeet java drones to functional programming, failed.

>>107219382
This. Which makes it a good poison pill for anyone that wants to ensure that their company maintains a white majority.
>>107219265
Not as big of an issue these days. AI has lowered the learning curve, but not the IQ curve of functional programming.

>>107217606
I had a brief foray. It is an enjoyable exercise, but some things are easier to express procedurally. But learning a proper type system is fantastic. I was able to use Zig's comptime to emulate some relevant parts for project.

>>107217606
>>107217620
>>107219139
Have you guys ever seen modern Java web applications? Practically everything Java programmers do is an attempt to emulate FP.

>>107219850
Only indirectly. Practically everything Java programmers do is an attempt to emulate C#, which does everything it can to emulate F#.

>>107219878
>>107219850
I have seen this phenomenon at a previous c#/react job. It worked well for most devs who "got it" but c#/typescript are not pure so that allows those 1-2 shitters who just don't get it to fuck your codebase.

>>107217606
Waste of time at the corporate level. You should start asking why corporations don't require it in the West.

>>107219878
I wish the C# devs did a better jobs at it. We're still missing DUs and exhaustive checks...
After you taste the forbidden fruit, going back to any language that don't have those feels incredibly bad.

Reminder that Whites (Mainly Germans) are the only thing keeping up the West at a technological level. The US is a slop and lazy country that can only maintain itself off of the brains and talent of other countries. It's time to make people better locally, instead of poaching from elsewhere and weakening the rest of the world.

>>107217620
>abstract mathematics
Yea me with my PHD in abstract mathematics. Haskell is literally just functions. It's easy as shit. One of the easiest languages, even. Invented so that it's literally impossible to fuck up anything because everything is so simple.

erlang is a like a million times better than hasklel

>>107217606
fib(15) -> out of memory

>>107220663
>doesn't know about TCO
your lack of knowledge about quite basic things should motivate you to continue your education

whaat kind of deep web tankie psyop is this where the shills want people to do programming instead of making statues, how will covilization suriveve without the stateus

>>107217606
You need to rewire your brain for that shit, Time issue.

>>107217606
Anybody seen this? Thoughts?

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

At least for Haskell, it is a great language to write for many things, but unfortunately it's just slow, and uses a lot more memory than idiomatic code in other non-onions languages do. Ocaml is much better in this regard, as...
>>107217665
...said.

My code in C and C++ generally runs a lot faster than in Ocaml, and it's more obvious how to deal with memory efficiently e.g. creating a string view to avoid copying a large amount of data, though this might simply be because I've spent more time writing in these languages. I would be very eager to adopt an FFP approach/language in more of my projects if I'm not sacrificing runtime performance and memory efficiency either due to a lack of experience or unavoidable bottlenecks.

I've heard that Lisp and its other derived languages are a lot faster than Haskell and Ocaml, at least on average with idiomatic code, so if anyone has recommendations for me I would be very excited to try them out.

>>107221143
it is a very common misconception that Lisp is functional. Common Lisp, the language one should think of when thinking of Lisp, is quite imperative. yes, it has lambdas, but so do many languages. Common Lisp also has CLOS, which is a very powerful object system, featuring things like multiple inheritance and multiple dispatch.

the most fundamental thing about "functional" languages is not lambdas, but immutable data structures. Common Lisp has the Fset library that offers immutable data structures. Clojure (another Lisp) features them by default, and is the only Lisp that I know of that fully embraces functional programming (although you can very easily use Java mutable data structures when you feel like doing so).
Rust has RPDS.

>>107220932
A surprising miss from him. Time isn't going to be any more friendly to an inherently unpopular and difficult (for most) paradigm. The one and only issue has always been an ergonomics one, which he should have realized from his time with Elm, which was made with new (to FP) people in mind.
It's sort of what he's trying to do with Roc, but i don't think it will affect much.
Ultimately people want the next true paradigm shift, FP will probably be a part of it, but it won't be the entirety.

>>107221404
>Common Lisp, the language one should think of when thinking of Lisp
Is it not also the least used of the big three/four lisps? I think Emacs Lisp, Clojure, and Scheme seem to get way more stuff in them than CL. Emacs Lisp is pretty much dogshit for functional programming, but idiomatic Scheme/Clojure code rarely involves mutation. At least not much more than Haskell does.

>>107217606
haskell is just cs fags wet dream. looks pretty on paper, zero grip on reality. it is a totally mistake.

try ocaml (or f#) instead. it lets you mix imperative stuff, which is what computer actually do, with functional style without pretending the machine is a magical math unicorn.

btw, there’s no such thing as a bug-proof language. FP doesn’t make your code holy, but it could create new kinds of nightmare you can’t even debug. trust me, i maintain >300k realworld fp code.

>>107217620
>too stupid to use types
i would hate to see the utter dogshit you write in c.

>>107222457
you don't do shit, you're regurgitating truisms.

>>107221793
the next big paradigm shift will likely be fully declarative data models, a la SQL (but more refined).
see how indexes are automatically used and kept in sync. native hooking techniques will likely be prevalent.

>>107222884
basically mech-lang , not sure if i agree it will change things.
https://mech-lang.org/
But rediscovering concepts from the 60s is pretty standard nu-lang stuff, so it might take off.

>>107220788
now do fib(15) with TCO on

>>107220488
>erlang
try Prolog

>>107220663
>>107223538
You can make it up to about 30 before it starts to struggle. I'm not sure why this is supposed to be a gocha, though. You can write a recursive Fibonacci implementation in any language and it's an equally bad idea.

>>107217606
Doesn't fit into existing OOP codebase as easily (inheritance based shitware, mostly)

>>107224655
>you can make it up to about 30 before it starts to struggle. I'm not sure why this is supposed to be a gocha, though. You can write a recursive Fibonacci implementation in any language and it's an equally bad idea.
Consider upgrading your i386 to something more modern

>>107224655
>recursive
you don't have to go that route

>>107223538
>with TCO "on"
these are the niggers that think they are superior at programming to you

>>107225256
>>recursive
>you don't have to go that route
Recursion is the future.

File: 1743573371877438.png (822 KB, 917x1080)

822 KB PNG

>>107217606
i get paid to write functional things in python

>>107219927
The only way to keep retards like that under control is to block merging directly to master in favor of pull requests with a certain number of required reviewers. Then reject anything that fucks your codebase.
We did it on Azure, but I assume other repo hosting services can do it too.

>>107217606
Functional programming is only appealing to intelligent people.

Most people are morons.

>>107222884
>>107222894
Very cool
Will definitely be checking this out

>>107217606
Because it's snake oil.

>bug-free programs
lol. lmao, even.

>>107217606
what are you talking about? functional programming is very popular, functional languages not so much

i did react for 2 months, it was kind of ok

>>107226825
I did your mom for 2 months, it was kind of fishy

Is FP really harder for most people, or is it just a meme? I could understand how being forced to think in a more principled manner is harder than the tinkering most imperative languages allow, but I reckon one could get used to it. Don't get me wrong, I'm a FP fanatic, but I doubt it's a matter of IQ. More likely it's the old 'worse is better' tragedy.

>>107227421
It’s artificial difficulty. You confine yourself to some idiotic dogma of muh function purity, which always results in bloated spaghetti code.

Take a simple swap function. In C, you would just pass pointers and call it a day. But the FP fags will immediately yell at you because his nazi wet dream of function purity isn’t realized. So instead you pass by value, which immediately hogs memory and performance due to copying, and then you have to create a whole new object, return it, and reassign your original object. But wait, we’re talking about a pair, so now you have to create a whole separate struct for that pair, initialize it with the two objects, get a new object via the function call, and then do a reassignment. All this fucking overhead for some retarded demand for purity,

FPfags are all midwits pretending to be math geniuses who are le based enough for category theory when in reality they never touch anything outside of Lawvere theory. It’s just autism and unemployment doing their thing.

>>107227495
C is for people who are basically like vegans.
Vegans eat the cow food directly.
Meat eaters feed the high-level cow the oats and eat the meat.

Similarly, Lisp programmers write the lisp implementation in C, and then use the high-level results to implement programs.

>>107227659
If we’re going with the food analogy, C is for people who like cooking. Yeah, you can always buy bread at the store, but you can make your own bread however you like and if you screw up then the fault is on anyone but you.

FP is like veganism more than anything. You’re telling yourself that this and that food is haram because my dogma says so and compensate with overly complicated “meat substitutes” that always taste like shit and take way more effort to make than just cooking a steak.

>>107227659
>Vegans eat the cow food directly.
That's more like assembly.

>Similarly, Lisp programmers write the lisp implementation in C, and then use the high-level results to implement programs.
Lisp implementations are usually written in Lisp with C only for interfacing with the OS (because Windows and Unix/Linux use C), but some don't have any C at all. Lisp machines didn't use C at all.
https://github.com/froggey/Mezzano
https://github.com/robert-strandh/SICL

>>107221143
> My code in C and C++ generally runs a lot faster than in Ocaml

Programmer here.
So, what you said doesn’t make sense.
Actual programmers test their programs, and if there are any parts that are too slow, those get re-written so they are fast enough. This may include re-implementing that piece in C, assembly, machine code, FPGAs or asics.
Research the lisp machine and the TI Explorer which has one of the largest and fastest processors of the era designed to run lisp based of earlier lisp machines by Tom Knight.

>>107227707
> usually written in Lisp
Hahahah… no.
Xlisp (which became autolisp) was all C. Emacs elisp? C. It’s C all the way down. Guile? C.

If course, some pieces of it, library functions, etc are often written in C but only obscure hobbyist/phd-thesis stuff is actually written in Lisp.

If you do find a primordial lisp written in lisp it didn’t start out that way… they eventually bootstrap it into an old version of itself when it gets big enough, gradually removing as much C as they can. Go and Java was originally written in C, too. It’s nothing to be ashamed about.

>>107219382
scala failed because why would anyone need to do anything in the JVM?

>>107227495
>pass by value
wrong
>copying
wrong

you are a midwit that cannot even do the most basic of reading. you just assume a bunch of retarded shit.
95% of FP programmers have done imperative programming, almost certainly more than you.

>>107227827
Look at the source code for Mezzano and SICL. They don't use any C. Everything is all Lisp. The garbage collector is Lisp. The compiler is Lisp.

>Xlisp (which became autolisp) was all C. Emacs elisp? C. It’s C all the way down. Guile? C.
Those are toy versions, which are slow. Real compiled versions of Lisp are written in Lisp.

>If you do find a primordial lisp written in lisp it didn’t start out that way… they eventually bootstrap it into an old version of itself when it gets big enough, gradually removing as much C as they can.
Lisp is older than C. The first versions of Lisp were written in assembly, then bootstrapped into Lisp. They didn't use any C because it didn't exist.

>>107227831
> JVM
This thing was one of the biggest fuck-ups in the computer world.
Leaks memory by design.
Bloated (was designed to be light-weight)
Stack based “machine” running on a register-based machine.
Before hotspot, which burned around a million hours of development time, it was show-stoppingly slow.
Probably designed to generate hardware-sales revenue
Fujitsu made a processor that could run bytecode directly called the pico. Too fucking slow.

People who base their language on something like the JVM are not legitimate and should consider paying back society by becoming ditch diggers.

>>107227881
> Mezzano and SICL
I’ve never heard of them.

>>107222894
let me guess, it uses interaction nets under the hood

File: E0324FD2-52FA-4BF6-88F7-3(...).png (758 KB, 2048x1536)

758 KB PNG

>>107227881
> first versions of Lisp were written in assembly
Obviously, if C didn’t exist, it wouldn’t be written in C, but after C existed… since the 80s most things were written in C. Since it, you know,… like existed and stuff. Everybody knows the first lisps were written in assembly/machine, because you inevitably looked up what car and cdr came from.

>>107227703
The other anon is correct. C is like eating cow feed instead of raising a cow for meat and then eating the burger. Most higher level languages are like junk food, java is like indian takeways. FP is like fine dining.

>>107228043
>since the 80s most things were written in C.
Because trannies of the time wanted to rewrite everything in C.

>>107227716
How doesn't that make any sense?

>>107228161
Guess FP comes at a high cost *budum-tss*

I may prepare some food at home exactly the way I want to (C), which will cost me time and may be tedious, but it completely matches my own specifications.

Or I may go to Cheesecake Factory (Python) where I’m presented with a talmud of slop items and the portions are way too big, and I spend more time browsing the menu than actually eating.

Or I may go to a Chinese restaurant (C++) where I am building my meal from greasy, overcooked components. It costs me nothing, it’s quick and efficient, but I regret it afterwards. Besides, reading the menu is impossible because it’s all in broken English with ten thousand versions of the same dish.

But I’m definitely not going to a fancy Michelin restaurant (Haskell) where the chef spends more time making the dish look good than actually cooking it. I am then charged with an absurd price for something that should have cost me 20$ tops. But hey, I can show off to others how I went to that place and y’all are plebs or something. Completely impractical.

shut the fuck up with the food analogies, fucking retarded ass motherfuckers
>muh vegetables
>muh meat
>muh fine dining
write some fucking code for once in your shitty ass lives

>>107228185
I see your point there, but other languages, COBOL, PL/I, algol, RPG, etc existed, and very little was actually re-written. C can’t do fixed point/decimal math. On “microcomputers” we had things like PL/M as a “high” level language.
Also, in the early C days, there wasn’t that much to rewrite. The bulk of it was new.
The very early unixes has a lot of stuff written in assembly.

>>107217606
1. Java and Python and other shitlangs are entrenched in most fields and companies
2. A lot of programmers are incapable of understanding recursion so everything has to be done using for loops for them
>>107217665
Ocaml has nothing to offer over Haskell doe
>>107220663
???
just calculate the nth power of the 2x2 matrix [[1,1],[1,0]]

>>107228755
stfu mr manager guy

>>107228755
Please understand, the morbidly obese can't help but think of food no matter what they're looking at.

>>107228766
you shut the fuck up bitch
I would smack the fuck out of you
get in the text editor, Shinji
make daddy proud

>>107226037
this doesn't even have tail recursion, how do people write recursive functions in python?

>>107228788
>get in the text editor, Shinji
lol

>>107224655
>recursive
THIS is the actual bad idea

>>107228767
mmm, hotpockets..

>>107217606
Monads are confusing

>>107228868
Just tell the IT guy to install more ram. Done ezpz

>>107228735
Preparing food at home the way you want is more like Rust. Comfy home cooked meal just the way you like it, using a variety of ingredients.
C is like eating grass, wholegrains, so-y and all that hippie stuff 60s and 70s getting nutrients straight from the source.

>>107227421
Bad programmers only reason imperatively
They can't wrap their head around the fact that there is more to programming than telling the computer how to compute

iv read that someone tried to rewrite Quake in F#. Droped the project after some years as it was too hard.

File: 1751502753720601.png (22 KB, 600x600)

22 KB PNG

>muh recursion
You don't need either loops or recursion.

>>107230153
>iv read that someone tried to rewrite Quake in F#.
https://github.com/TIHan/FQuake3
That was 11 years ago.
>Droped the project after some years as it was too hard.
Skill issue. Some autist wrote an entire game engine in F#.
https://github.com/bryanedds/Nu
He actually posted about it himself in /gedg/ a few times.

>>107217606
because fp is "good" (slow but easy to write) at boring spreadsheet stuff. you can write a crud (lame), but not a good database (cool)
deep down most programmers want to write something that runs fast and with fancy side-effects

>>107217606
what's the use case for bug-free programs?

File: 1731108354284273.jpg (690 KB, 1125x1115)

690 KB JPG

>>107217606
carmack was re-wrting doom in scheme a while back. don't know what happened in the end.

>>107228185
c and unix were basically free for universities. so it gained popularity because generations of students were taught it at universities.

d-do not bully haskell

>>107217606
>Don't people like writing bug-free programs?
Given my many years of experience in the software industry, the answer is emphatically no. Writing bug-free programs is something that engenders a deep revulsion in most people paid to write code. They seem to prefer to write absurdly structured and bug-ridden code. I think functional programming and strong, expressive static types encourage well-structured, easy to understand code, but the reaction to the suggestions I make have largely been of dismissal. I don't think this is due to job security, rather I simply think that most programmers are stupid people who (like most stupid people including conservatives) react to novel ideas with fear and disgust and also lack the reflectiveness to question if they *should* react with fear and disgust. Most people who go into the industry have no passion for the craft and see it only as the means to get a reliable pay-check, so most programmers treat their craft with indifference and laziness: writing bug-free code is hard, writing bad code is easy.

>>107227421
You *vastly* overestimate the intelligence of the average programmer. Most programmers struggle with object permanence.

>>107230462
scratch is free and it's used to teach students programming and yet I hardly ever see software written in it. curious

>>107230574
if scratch existed 40 years ago maybe things would be different.

>>107230535
yup, the actual answer someone who programmed professionally would have
to them, "good code" is just that which is done as fast as possible and is functional enough to get the PR approved. i know i can't ask people to see prgramming the same way i do, but it's really frustrating and kinda lonely sometimes

>>107230648
worse is better.

>>107230535
It definitely is job security. Bug free code means a skilled programmer is not needed anymore. If it does not result in firing then once a programmer writes bug free program, he is then expected to always write bug free code. In other words even meeting a standard is dumb, let alone exceeding it. Always complain about everything and write code that's just shitty enough for the management to keep you in the job.

>>107217606
too slow
you have to trust the compiler will optimize everything. no wonder people in the 70s used to call it "the ai kool aid". any non-trivial program in haskell will use too much memory because of the weird immutability thing it does

no one is stopping you from writing pure functions in c or whatever

>>107230763
>no one is stopping you from writing pure functions in c or whatever
C is.
User "enforced" X has always been a disaster in programming and never works.

>>107230926
GCC lets you mark functions as pure with an attribute.

>>107230462
we have FORTRAN77

>>107217606
>Why isn't functional programming more popular?
recursion suck

because functional programming solves nothing and adds unnecessary complexity

>so were gonna be like MATH where everything is PURE
>umm yeah but when we get errors we will revert back to imperative and call it a monad

test

File: okamal.png (43 KB, 1123x492)

43 KB PNG

>>107217665
this just looks like "Object Pascal But Kinda Weird", seems pointless

functional programming is the unemployed man's rust

>>107217606
Zbugzarzozimplzee'zday000

>>107229633
No they're not, at least up to a point, they're your friends.

>>107234169
do notation sux, and using them without do notation sux even harder

>>107217606
>Why isn't functional programming more popular?
Because immutability sucks at least half of the time.

>Don't people like writing bug-free programs?
Your shitty Haskell program's memory footprint grows at a pace of 100 mb/sec and it's hanging the system but that's ok because a memory and time leaks (TIME LEAKS!!!!! a concept dreamed up by the mentally insane) are not a real bugs. :^)

>>107232388
>and adds unnecessary complexity
It's simpler. A compiler for an imperative language has to conservatively analyze whether a variable or field has been updated between its definition and point of use, e.g.

a = 5
b = 7
r = {x = a, y = b}
z = f(r)
y = r.x + r.y
...

In a pure functional language the compiler knows when y refers to r.x and r.y, it's going to be the values of a and b, so we can freely substitute r.x and r.y for 5 and 7 and evaluate them at compile time. The computation of f(r) in an impure language might assign new values to the fields of r, so would require further analysis

>>107235726
>too retarded to know what code he's writing translates to
stick with javascript and bash buddy

File: 1749338255343394.jpg (44 KB, 720x715)

44 KB JPG

>>107235867
poor compiler i feel so bad for it

Give impure, strict haskell and a parametric ptr type which behaves like an ocaml ref type except you can also index it and do arithmetic on it.
I will now use your language. Haskell is super fucking comfy, but I'm too much a brainlet to understand FP

>>107235696
Why does it suk? Also, there are other PLs beside Haskell which use monads.

File: 1737478289882647.jpg (26 KB, 277x160)

26 KB JPG

>>107236086
>Give impure, strict haskell and a parametric ptr type which behaves like an ocaml ref type
Just use any other *ml anon, purity and non-strict evaluation is what differentiates haskell from them to begin with

>>107235934
You sound mentally ill.

>implement min heap in FP language
>*stack overflow*
Bug-free doe!

>>107236383
trees are literally one of the most common data structures in FP. they are the basis for efficient immutable data structures.
you are so fucking retarded.

>>107236442
How do I insert into a heap? Oh wait it’s le immutable! I now have to create a new heap from scratch… sowwy uwu :3

>>107217606
It is very popular right now. Many languages, including Rust and JS, incorporate many features inspired by functional programming.
It's just that writing pure functional code is pain in the ass. Analyzing pure imperative code is pain in the ass. It's only when you combine both you can get clear, simple code that is easy to write and to understand.

>>107227703
>>107228161
>>107228735
>>107229775
IMAGINE BEING
AT COMPUTERS

File: 1750556683632897.png (83 KB, 459x475)

83 KB PNG

>>107236218
The thing is that I want Haskell's type system, which also completely deprecates the ML module system. I like the runtime language I get with SML, but Haskell's compile time language is about as good as you can get without going full dependent types. Kinds, type families, higher kinded types, GADTs, higher order polymorphism, etc. are all very real boons you get from Haskell. The functor/module system of sml/ocaml works, but it can feel super rigid and it's easy to run into limitations. The cuter you get with it trying to offset those limitations, the more the seams start to come apart.

indians can't do functional programming

>>107236495
Maybe you should have generated code with ghc instead of hugs.

>>107236495
https://hypirion.com/musings/understanding-persistent-vector-pt-1
https://hypirion.com/musings/understanding-persistent-vector-pt-2
read, you stupid motherfucker

>>107236564
kek do you even program

>>107236383
I can't even imagine how retarded you have to be to create a stack overflow in a language without a call stack.

File: 1698971355588463.jpg (41 KB, 683x661)

41 KB JPG

>>107236684
The other alternatives are to use
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/strict.html#strict-by-default-pattern-bindings
with your ref library of choice, or maybe idris which is strict (but idk if it has ref cells)
https://docs.idris-lang.org/en/latest/faq/faq.html#why-does-idris-use-eager-evaluation-rather-than-lazy

>>107236791
It's a meme you dip

I really don't understand how OOP won the game. Thinking in terms of functions is infinitely easier than thinking in terms of classes and the other hundred things that come with that baggage. Functions are practically "natural" in programming, while classes require an absurd intellectual effort to truly understand. Whereas functions can be simplified as being equivalent to an instruction (note that I'm only comparing them, not saying they're the same thing, you son of a bitch!).
I started "working" with Haskell, stayed in the research department for almost 4 years, and only after going to work for the big corpo did I come into contact with C# and Typescript, which haunted me. I thought it would basically be a change in syntax, but that the logic would be basically the same. I couldn't have been more wrong! Even after almost 10 years working with web development, I still can't understand how this OOP disgrace won the game. It can only be the work of lazy boomers trying to show off. I hate OOP.

>>107237704
>I really don't understand how OOP won the game
Corpo retardation mostly. Xerox PARC's decisions trickled down and shaped the industry. Imperative code had already replaced functional thinking by the 1960s, and OOP is is like a logical extension of imperative code. Adoption isn't a rational process, it means nothing other than some middle manager somewhere fell for some marketing gimmick and decided to foist it on his team.

>>107236958
There is also lean4, but it is mostly a mathfag language (theorem prover), but it supports general pure functional programming, and its syntax is nicer than haskell's imho.

>>107237704
it is not even real OOP, it is a very gimped version of it, real OOP was in Smalltalk, but coproniggers took only the class thing from it, butchering the system.
And in the end what people call OOP is just imperative code with OOP-like capabilities.

oop is the most lukewarm "abstraction" that exists
omg, I'm, like, inheriting functionality
teehee

>>107237704
>I really don't understand how OOP won the game. Thinking in terms of functions is infinitely easier than thinking in terms of classes and the other hundred things that come with that baggage.
Your approach is incorrect. With OOP you dont have to "think". You just mutate state, subclass, or override until you hack together something stable enough meet requirements for a deliverable. You're approaching this like someone studying strategy for a super smash bros round where items are on instead of accepting that its button mashing time.

>>107237704
It didn't. We no longer live in 2010.
The current meta is to use OOP for general architecture and FP for expression.

>Even after almost 10 years working with web development, I still can't understand how this OOP disgrace won the game.
Currently most of webdev is done in react hooks which is very functional like.

functional programming IS popular and walks hand in hand with oop towards making computers gay and retarded respectively.

>>107217606
because Rust allows for mutability, so there is no usecase. you can argue purity matters, but then your code just looks like stacks of monads everywhere anyway. Not really sold.

File: zero-cost.png (281 KB, 900x966)

281 KB PNG

>>107238439
>because Rust allows for mutability,
It doesn't support any nontrivial functional programming, thoughtbeit.
>inb4 muh map, filter and reduce

>>107238587
Ok. Don't really care. ever since using Rust, I don't see a use case for Haskell. Also the standard library of Haskell sucks and is clearly showing age.

Rust has safe mutability via its shared xor mutable, it has traits, it has auto derives and a build system and toolchain that just works. I don't need to play games with strictness or laziness or contort my usages so I don't have 10 minute runtime using 30GiB of memory.

>>107238358
>most of webdev is done in react hooks
Wrong. Most of webdev is made with PHP and Java.

>>107238708
>Ok.
Ok. Not reading the rest of your post. Nothing Rust users say matters but I'm glad we both agree Rust doesn't support nontrivial functional programming.

>>107217606
Because:
1. It’s slow as fuck;
2. code written today becomes gibberish the next time you read it;
3. real world problems require altering states. Haskell use cases are just mental masturbation.

Most mathematicians don’t use it anyway (we prefer something as simple as Python), so the argument that it’s used by "smart" simply isn’t true.

>>107238708
> and is clearly showing age
Bits age eh?
> Rust groupie following latest buzz words and fads from internet randos with hyper-religious zealotry.

>>107238984
Can't the same functional language concepts be used in other languages like C?

explain it to me like I'm a retard that never touched a functional programming language in his life (I am) what can functional languages do that the average imperative language cant?
Every modern language nowdays lets you create first order functions. If I want to pass a function to a function I can also do that in Java.
What more is really there in Haskell?

>>107227961
>Fujitsu made a processor that could run bytecode directly called the pico. Too fucking slow.
it didn't fail - it became standard for contact and contacless cards. every single credit/debit card you have in your pocket has this small processor and RAM which contains compact JVM with cryptographic functions, which are being used by a java applet installed on it

>>107238439
how about having a language that doesn't suck cock and balls to read and write

>>107239144
No, because C is crippled, but you could do it in most other languages.

>>107239181
point-free style
>what can functional languages do that the average imperative language cant?
allow you to write functional code without wanting to kill yourself

>>107217620
English adj+N adjectival phrases use functional programming and Spanish N+adj adjectival phrases use object oriented programming.

We're in a simulation, and the languages we speak were written by our creators

>>107239274
lay off the ket, elon

>>107239299
I've been thinking much more clearly about things ever since I stopped doing ketamine.

>>107220932
Is he jewish? Provide proof that he is and I'll watch it, otherwise I don't trust nonjews.

Why isn't functional programming more popular?
Don't people like writing bug-free programs?

>>107239212
so, rust? probably the best language to read and write in right now.

>>107239181
nothing. what matters is type system features at this point and Haskell may be more advanced than most, but you'd need to go towards idris, lean4, etc to get a stronger dose.

>>107238795
gm sir

>>107239181
Haskell is garbage but erlang is very good at multiprocessing

>>107239800
retarded babyducking of sepples glyph soup immediately disqualifies it. that's without getting into the autistically poorly designed module system that litters the whole codebase with additional noise, explicit type variable list syntax (more retarded sepples babyducking), mut as a keyword and not a built-in type constructor (more retarded sepples babyducking), no support for point-free style (more retarded sepples babyducking), and who could forget the AST macros. because I love having side effects in my god damned syntax tree.

rust is a candidate for the worst new language on all of these points. it's actually impressive how dogshit the language is.

>>107239051
>Bits age eh?
APIs do, as developers mutate them. Developers make bad decisions or good decisions or correct mistakes leading to deprecation cruft. Mostly though the decisions have to make a choice between tradeoffs and "better" or "worse" depends on the usecase.

I don't have a point I'm just arguing to argue.

>>107239181
A procedural program is a list of statements that cause things to happen, and may contain within it expressions that compute values out of other values.

A functional program is an expression that compute values out of other values, and may express within it procedures that cause things to happen.

You need both. A functional language decides that expressions are more important and should be the most readily-available vehicle of computing. And that's the correct attitude imo.

File: 1704071481771436.png (249 KB, 360x594)

249 KB PNG

>>107237944
>There is also lean4, but it is mostly a mathfag language (theorem prover), but it supports general pure functional programming, and its syntax is nicer than haskell's imho.
Yeah the type signatures are a lot better, it's closer to what you'd ordinarily write. Differentiating = and := is unaesthetic though, depending on the grammar it's possible (like in sml) to treat = as both a lhs/rhs delimiter and an identifier in expressions

>>107238795
I refuse I consider Wordpress a real webdev.

>>107240463
Wordpress, React, PHP, Node, Java, those are all the same webshit. It's funny to see some "backenders" here thinking that they do "real programming" while everything they do all day is just creating fucking endpoints in a fucking framework like Django, Spring, Laravel, NestJS etc. Backend is also webshit, the same way front-end is. They don't do real programming, not at all. I still have some respect for those working in the web domain developing infra and network, for example, but webdev in general is pure horse shit.
I was discussing this the other day in a thread here on /g/ and it turns out that the "real programmer" that was talkign to me was simply a "backender." He didn't know shit about programming, in his head, being back-end meant being a real programmer, when all these idiots do is create endpoints and write database queries, something even my mother, who isn't even a programmer, knew how to do before retiring lol.
We should create a secret board where only those who prove they don't work with web development would be allowed to post. This would filter out 90% of the dumb fuckers we have here. The quality of the posts would certainly increase significantly.

>>107240310
>babyducking
>babyducking
>babyducking
>babyducking
Allowing brown zoomers to access the internet that are incapable of forming a single coherent sentence without resorting to juvenile buzzwords has irreparably cratered the level of online discourse.

>>107240793
Can't wait for age verification on 4chan

>>107217606
>Don't people like writing bug-free programs?
what do you mean by this? bugs are introduced by human-error. your favorite language will never compensate for that.

>>107241139
>bugs are introduced by human-error.
That's not always the case.

>>107241245
then while i can't be sure what you're referring to, it is accurate to say it's almost always introduced by human error.
it isn't often that a bug in my code is due to some underlying or fundamental flaw in the language or standard library, unless it has to do with version/porting compatibility issues.

>>107237704
Maslow's Hammer

>>107240602
All that word salad and you haven't explained what a "real" programmer is.

>>107241386
idk nigga. functional programming : oop, seems like what waterfall is to agile.
it's less flexible and doesn't leave as much room for error.
pls don't try to exploit the analogy. surely you understand the overarching point.

>>107239800
>so, rust? probably the best language to read and write in right now.
LOL
People complain about Lisp having too many parentheses and then write in syntax soup langs like Rust

>>107241765
the sad thing is that rust almost had a decent syntax. but then they changed it to the abomination it is now in an attempt to "appeal" to sepples programmers. funny thing is, i am a sepples programmer and it killed all interest i would have had in rust. when ante is usable, i'll probably end up adopting that. sorry, just not gonna fuck around with pub impl mut' Abstract::Ownership::Util::Reifier::Module2::Tmp dogshit

>>107241385
No. It often pays better to introduce small non critical bugs into code and then spend time fixing them. In my previous company the devs responsible for the main app our company used did exactly that.

>>107217606
Ancient guy here. When I first got into programming in the 1980s, functional programmers were mostly academics and pretty much insane assholes. They would openly state that anyone who had been to exposed to imperative programming was forever tainted and never could be a real programmer. If you weren't using LISP, you might as well die. That type of gatekeeping guaranteed that no one outside of their little club wanted anything to do with them and their paradigm.
For decades they endlessly ranted about how superior they were while more and more of the world's software was written in anything other than functional. Then JavaScript handed them a bastardized Frankenstein language as a backdoor into the mainstream. Eventually functional paradigms started leaking in from other sources and the old guard started losing control, partially due to dying off but also because there were some good things about functional programming that were worth adopting but no one touched before because they didn't want anything to do with the functional assholes.

>>107242273
honestly have no clue wtf you're on about, or how it could be relevant to what I just said.
we must be misinterpreting each other's posts.

>>107242338
>Ancient guy here. When I first got into programming in the 1980s, functional programmers were mostly academics [...] guaranteed that no one outside of their little club wanted anything to do with them and their paradigm.
The problem with this larp is symbolics alone made up 10-20% of the ai and expert systems market during the 80s

>>107223538
With TCO you have the same perfomances of loops

 
#lang racket
(require profile)

(define (fib n)
  (define (tco-fibo n a b)
    (cond
      ([= n 0] a)
      (else
       (tco-fibo (sub1 n) b (+ a b)))))
  (tco-fibo n 0 1))

(time (fib 100000))
 
;cpu time: 550 real time: 538 gc time: 142                 

It start struggling a little bit with 1 million for which is takes aroung 28s on a stinkpad x250

>>107242434
Sorry, you are clearly not a programmer, I should have been more clear with my post.

>>107236684
>without going full dependent types
solve the problem by going full dependent type

>>107242788
Ok well, I'll tell you what my experience with 'functional programming' and you can tell me what you think in non-programmer language.
I used react a number of times, which is supposedly designed around 'functional programming'. Everyone said it's better, but it just makes everything into a gigantic mess.
You end up having to use solutions, which everyone approves of, but basically violate all the things React (and it's 'functional' style) set out to avoid in the first place. In the end you have a product that is unnecessarily complicated, difficult to refactor, and difficult to navigate.

>>107239181
you can't do currying cleanly in java

 
#lang racket
(define apply-this
  (λ (f)
    (λ (args)
      (logging-in-functionality) 
      (f args)
      (logging-out-functionalty))))

(define my-generic-sum
  (λ(a)
    (λ(b)
      (+ a b))))

(define my-sum-one (my-generic-sum 1))

(define logged-sum-one (apply-this my-sum-one))

(logged-sum-one 4)

I find currying/partial applications really clean for ML programs where you can define "symbolic" functions that leave unset parameters list you can then find the optimal one with a optimization function that accept a function that accept parameters

>>107239181
>What more is really there in Haskell?
a good type system
good defaults (immutability, no null)
easy concurrency
software transactional memory (STM)
parser monads, e.g. parsec

>>107243022
Currying is pretty dumb. It lets you easily create a partial evaluation of a function's first argument. And what if you want the second argument? Closure. So why not just use a closure all the time?

>>107243210
Because `f x' is generally nicer than `\y -> f(x,y)'

>>107243210
>It lets you easily create a partial evaluation of a function's first argument
you order the arguments of your function based on your goal

>>107242338
List is not a functional programming language and the academics were right to gatekeep.

>>107243210
>It lets you easily create a partial evaluation of a function's first argument.
you can curry for every parameter in sequence, not just the first one
for (f a b c) you can do
g = (f 1)
h = (g 2)
(s 3) -- same as (f 1 2 3)

>>107232546
you just don't use the 'O' in Ocaml

>>107243471
But you do in Ocaml.NET / F#.

>>107243505
but you shouldn't

>>107242552
ai and expert systems never delivered anything of value until the 2000s/2010s

>>107227495
Because data is immutable in functional languages it's never copied.

>>107242695
>define (tco-fibo n a b)
wtf? it not what THEY say FP is

>>107242695
and it need only 1GB to run

>>107243923
Maybe do the bare minimum and either Google or GPT "TCO" before posting stupid shit.

>>107243361
>were right to gatekeep.
Then don't whine like a baby that your favorite toy isn't widely adopted. Why do so many gatekeepers expect to be the default but also tightly restricted? You can't have both.

>>107243937
He isn't wrong about Racket being a memory whore. Most my Racket programs take between 5-10x more memory than their C equivalent.

>>107244462
Racket can also do things like sandboxed execution with memory limits and restrictions of capabilities
it's a dynamic language with features that most languages literally have not even conceptualized at this point in time
C doesn't even have namespaces lmao

File: 1752336533600942.jpg (23 KB, 479x330)

23 KB JPG

>>107240445
>Differentiating = and := is unaesthetic though, depending on the grammar it's possible (like in sml) to treat = as both a lhs/rhs delimiter and an identifier in expressions
You can't because = is used for math equations, and automatic prover.

>>107244462
>he never saw haskell binary sizes, or rust one

>>107244820
Racket be like: ‘Oh, you just added pattern matching in 2023? Cute.’

>>107245191
erlang had pattern matching back in the 90s

>>107245187
>Why is a statically linked binary bigger than a dynamically linked one nooooo

>>107245243
>id rather look for excuses than fix my shitty language

>>107245501
post research papers denoting viable techniques

>>107245587
I am a programmer.

File: 1735769617253791.png (27 KB, 238x212)

27 KB PNG

>>107244820
>C doesn't even have namespaces lmao
>what is clone(2)?
>what is unshare(2)?
what is setns(2)?

>>107217606
use case for functional programming?

File: 1741473310061920.jpg (7 KB, 333x141)

7 KB JPG

>>107240445
lean4 has the best approach to programming imho, it is purely functional first, but allows to write imperative code

>>107246675
So the same as Ocaml, F#, and Scala?

>>107246711
no, it is still a pure language, the imperative code is syntactic sugar

>>107240310
>>107241765
Retards who say this can never articulate what they mean by bad syntax. Reminder Rust can be trivially parsed because it actually has a well designed grammar.

>>107246774
When people say bad syntax, they mean trivially parsed by a human.
Fuck making languages that are harder to read to make the job of the compiler developers easier and fuck you for being intentionally obtuse.
It's incredible that a language that aims to be a modern C++ somehow manages to make the syntax worse when it didn't have 4 decades of backwards compatibility holding it down.

>>107246832
Which it is because you only need to look ahead a few tokens. Nothing about rust is hard to understand, you're just a brainlet.

File: 1749453514559588.jpg (5 KB, 249x250)

5 KB JPG

>>107246080
hahahahahahaha holy fuck

>>107217606
you can do better functional programming on real languages that have better tooling than strict functional languages
haskell is unnecessary

>>107219850
>Practically everything Java programmers do is an attempt to emulate FP.
not everything, it's mostly the CRUD parts
all business logic stays imperative

>>107226198
only midwits care about competing in "intelligence"

>>107247156
Isn't that, like, the opposite of what one would ideally want?

Many concepts from functional programming languages have in fact made their way into mainstream languages

>>107247279
NTA, but yeah, 100% this.

Also Java 8 was a nice improvement imo because it added all these FP fancies. I stopped using Java around that point though.

>>107237704
>Thinking in terms of functions is infinitely easier than thinking in terms of classes and the other hundred things that come with that baggage.
you think functions are better/easier because you only think of trivial problems
enterprise processes are abstract and complex as fuck so you need a paradigm that can model that high-level complexity
OOP does a good job at handling complexity for relatively low effort (assuming you don't write shit code)

>classes require an absurd intellectual effort to truly understand
a class by itself is just a limited scope for running a piece of code, so you don't have to deal with global state and all its issues. how complex a class is depends entirely on how you write it

>>107247279
you mean imperative CRUD and functional business logic? that would be absolute hell
business logic is a list of things to be done, and almost always include state. it's a natural fit for imperative, especially object oriented code
CRUD operations can easily be declarative, that's why they often get turned to functional or functional-like code

>>107247309
Which is funny because funcfags both point to that as a demonstration of functional's superiority and as an abomination that shouldn't be permitted as everything should be strictly functional.

>>107247399
you unironically are just stating nonsense. you're just claiming things:
>OOP does a good job
wtf does that even mean? do you think that functional languages do not allow for structuring data into a singular type? the most simple benefit of functional programming is extremely clear:

def add_user_if_old(old_users, user) do
  if user.age > 25 do
    [user | old_users]
  else
    old_users
  end
end

old_users = []
user = %{name: "George", age: 38}
add_user_if_old(old_users, user) |> IO.inspect() # What does this print?
IO.inspect(old_users) # What does this print?
old_users = add_user_if_old(old_users, user)
IO.inspect(old_users) # What does this print?

code is Elixir

>>107247399
You simply haven't realized that everything you said is just a simple coping mechanism to deal with the sunk-cost fallacy.
You've dedicated so many years to this domain that you start to feel it's no longer worth pursuing another path, even if the path is "wrong," you've already invested too much time to abandon it. Intellectually, this is a form of suicide; you're killing any potential to discover new things.
I worked in research, using Haskell as previously mentioned, and in the last decade I've worked with webshit (Java and Dotnet). I could very well have continued in my research work; I enjoyed programming in Haskell, but it was Java that allowed me to change my life and earn real money. The point is that even after a decade working with OOP, I'm not stupid enough to say that OOP is wonderful simply because it pays my bills. It's objectively an inferior paradigm, and even though it has some interesting applications in game-dev, for example, it's still far from having the same elegance and simplicity as FP, very far indeed!
You should try Haskell, at least for a week. I'm sure it would change your mind.

>>107247957
sounds like projecting mixed with larping

>>107247610
how is your example with elementary school level of triviality relevant to enterprise process complexity?

>>107248148
most "enterprise process complexity" is contained in SQL queries, which is more declarative/functional than imperative (which OOP is btw, literally all that OOP does is add the concept of inheritance, which is objectively inferior to traits/typeclasses)

>>107217606
Hardware isn't optimised for it.
Normies can't into it.
It isn't objectively awful and insecure.
No one is shilling it, paying to write infrastructure in it, and pushing it everywhere.
>>107219139
Also this.

>>107248195
>insecure
Please explain yourself. I could use a good laugh.

File: antioxidant manifesto.png (140 KB, 825x3574)

140 KB PNG

>>107238708
>toolchain that just works
Kek. Haskell has working type inference. I don't have to twist my nuts and manually write type signatures longer than the program. Also, it's stable and well-defined. A new version won't break my stuff. If you knew your shit you'd be using something with a linear type system (it prevents memory leaks, not just dangling pointers, and does not take forever to compile), not Rust.
>>107238984
>"mathematician"
>preferring a "dynamically typed" language
Disgusting. Use wolfram language or at least C# if you can't grok Haskell and don't have the balls to write C. Have some dignity.

>>107248173
>most "enterprise process complexity" is contained in SQL queries
factually wrong

>literally all that OOP does is add the concept of inheritance
conceptually wrong

File: uncle Terry.jpg (41 KB, 500x500)

41 KB JPG

>>107248232
>insecure
The Rust compiler is written and compiled in Rust. That's NSA's wet dream for self-propagating backdoors. Know your history, newfag.
https://wiki.c2.com/?TheKenThompsonHack

>>107248604
>Rust is insecure because it is compiled by Rust
So, like every self hosted language?

>>107248504
>>107248604
It's funny how you can always tell apart LARP when someone can only discuss one language by talking about different language.

I guess they managed to ruin C programmers' reputation so much they now have to jump the ship and pretend to be Haskell programmers.

>>107248646
>So, like every self hosted language?
If it's exclusively self-hosted, then yes. You should be able to build something out of something that's lower-level than it. The push to replace every gnu core utility with rust is not organic.

>>107248536
nice arguments broski

File: beavis-computer.gif (219 KB, 492x376)

219 KB GIF

>>107248707
I like C. I like Haskell. I like Lisp. I like Wolfram language. I can tolerate C++. I hate tranny-mutt languages like python and rust. Simple as.

>>107246774
>can never
Try reading the post you're replying to.

>>107243264
honestly the one thing i hate about haskell is the lambda syntax and the implicit currying. i could give a shit about monads or whatever, but i really just hate this shit like no tomorrow. ocaml has the same problem. now people just use implicit currying for basically every function, never touching tuples.

>>107248728
>what is bootstrapping

>>107249233
"I hate currying / partial application" is an unusual complaint. Mind elaborating?

File: 1762358599947550.png (109 KB, 500x500)

109 KB PNG

>>107243210
>Currying is pretty dumb. It lets you easily create a partial evaluation of a function's first argument. And what if you want the second argument?
You can flip the argument order to apply the second argument first:

(define first
  (lambda (x)
    (lambda (y)
      x)))

(define flip
  (lambda (f)
    (lambda (x)
      (lambda (y)
    ((f y) x)))))

((first 1) 2) => 1
(((flip first) 1) 2) => 2

or more concisely

first x y = x
flip f x y = f y x
first 1 2 => 1
(flip first) 1 2 => 2

>>107217644
trvke
>I met John McCarthy in 1977. In college, a professor (Ruth Davis, I think; SCU EECS department) brought in someone who taught Friedman's "The Little LISPer". By the time I got to Netscape, I had read SICP. I knew enough about LISP to be dangerous.
>But as I've said many times, and Netscape principals have confirmed, the reason JS isn't Scheme is because Netscape did the Java deal with Sun by the time I hired on (after I was recruited with "come and do Scheme in the browser"), and that meant the "sidekick language" had to "look like Java".
https://news.ycombinator.com/item?id=13149123

>>107250513
I don't hate currying in and of itself, I hate implicit currying because it royally fucks function type signatures. My problems are twofold:
- Arrows are the ML-family's equivalent of Lisp parens. Things start getting a bit annoying at 4 arrows. (Int * Int * Int) -> Int is immediately skimmable in a way that Int -> Int -> Int -> Int is not.
- Ambiguity. Consider for a moment someone who doesn't write a lot of Haskell. They haven't even begun to memorize all the associativity rules of the built-ins. They write a function with this signature:

Int -> Maybe Int -> Int

And they expect it to be equivalent to:

Int -> (Maybe Int) -> Int

Rather than

Int -> (Maybe Int -> Int)

They're going to have a C++ templates-tier compiler error trying to hunt that down.
It's not unique to learners of Haskell. I don't write it enough to have all the associativity stuff memorized, and I fall victim to it whenever I pick Haskell back up. It gets especially bad once we introduce type variables.

These two points compound each other, too. Can't skim signatures and I have to disentangle ambiguous ones. Currying is powerful and implicit currying is ergonomic in functional programming, but I've come to prefer explicitness in code. Rather than treat everything as composable, I like to be a bit more deliberate and indicate composability boundaries. You can easily lose sight of the logic of a program that composes multi-argument functions that are partially applied in a way that you can't with functions that accept and return tuples. Makes them less flexible, sure, but I find that flexibility can end up a footgun.

I don't necessarily hate partial application either, but I greatly prefer partial instantiation. Imagine a type system where this is possible:

f :: (Int * Int * Int) -> Int
let x: Int -> Int = f (1, 2, _)
let y: Int = x 3

>>107251129
>And they expect it to be equivalent to:
>Int -> (Maybe Int) -> Int
That should be

Int -> Maybe (Int -> Int)

QED I can't even get my own examples right lol

>>107246832
>Fuck making languages that are harder to read to make the job of the compiler developers easier and fuck you for being intentionally obtuse.
C and C++ are harder to read and make the job of the compiler developers harder.

>>107251889
Which acts as a form of gatekeeping, life always finds a way though, that's why C++ compilers are objectively the definition of compiler.
Think a compiler is any program that just outputs some jeetsembly? Think again fucker, a compiler is literally
>A C++ program written by an oldfag C++ programmer who still remembers seeing C compiler emitting errors because his C++ compiler at the time was just a C macro preprocessor v2 and outputs top quality GODsembly that singlehandedly prevents current power grid from being overloaded by IoT slop drawing energy from it no matter how fucking mentally ill codemonkeys get in current year.

And I forgot to add: I feel sorry little ones, once last competent C++ programmers die, we will genuinely be doomed. Who can even replace them? Rustroons who had to piggyback from OCaml into LLVM and failed to even initiate RIIR for LLVM? If you run any Rust code, it was compiled by a C++ compiler, once C++ compilers start decaying, it is objectively over for humanity.

>>107217606
For the following reasons:
- It's difficult to learn due to poor learning documentation and fragmentation of methodologies.
- Has dynamic libraries issues due to not having an ABI.
- Because it's not popular is lacks many libraries.

Modern Haskell is using a better prelude and may lenses/optics. You don't learn that with tutorials. You eventually figure that out.

>>107251998
Shared libraries are asinine.

>>107252019
Foe you maybe but in real world nobody wants to compile everything again just because something changed or have giant executables with all libraries in it. GHC devs are finally fixing that problem but it will take a while.

>>107248604
>The Rust compiler is written and compiled in Rust.
That's good, because that's how all real languages work. The Ken Thompson hack is literally about C, and most compilers are written in their own language. Ken Thompson actually backdoored C and bragged about it. The Haskell compiler is also written in Haskell, Lisp compilers are written in Lisp, Pascal compilers are written in Pascal, and so on.

>>107217606
If you write as few and as irrelevant programs that do nothing of interest it's not very hard to keep your programs bug-free.

>>107252039
Don't write bloated jeetslop and you won't have to compile everything again.

>>107251961
>Which acts as a form of gatekeeping, life always finds a way though, that's why C++ compilers are objectively the definition of compiler.
C/C++ "gatekeeping" keeps out the good people. There are some people who eat feces, but most people find it repulsive and disgusting, like C++.
>A C++ program written by an oldfag C++ programmer who still remembers seeing C compiler emitting errors because his C++ compiler at the time was just a C macro preprocessor v2
That's not a compiler at all. C++ is a turd sandwich and you're happy to pay for it.

>>107252118
Retards objectively are not good people. Retards are the reason jews thrive.
Every time I see a /pol/tard screeching about jews, I just roll my eyes, because I know that he fell for a jewish trick at least once himself. Pathetic display of gentility.

>>107252146
>Retards objectively are not good people.
C/C++ are bad because they are made by retards who are not good people.

>>107252161
No, it wasn't made by you, retard. Keep seething.

>>107252068
You don't have a choice. Everytime you change anything you have to recompile everything. The solution is split the base, and now you'd only have to recompile if you change GHC. That doesn't exist yet and it will take a while but it would improve the status quo a lot. For now it's annoying, especially with package managers, Arch Linux being notorious for it. Honestly Arch Linux should simply provide static packages but they decided not to do that.

File: frog.jpg (54 KB, 976x850)

54 KB JPG

>>107252176
So stop changing things, retard.
>b-b-b-ut
JUST STOP ADDING MORE BLOAT YOU FUCKING NIGGER.
JUST DON'T DO IT.

>>107252197
That's not a solution, that's just a workaround. A cope for not sharing anything. It's what haskel developers do. It's not ideal.

>>107252170
Why would you use something that is bad because it "gatekeeps" good people who have standards and don't like the programming equivalent of eating shit? It's the opposite of the kind of gatekeeping you want. C/C++ make sure that there are no good people and only bad people who don't care about anything. This is what created the enshittification of software.

>>107252258
The browser you used to post this niggertarded drivel on is written in C++, get the fuck out of here subhuman.

>>107252276
Browsers are some of the most bloated and ugliest code in the world. The web has become an abomination because of C++. C++ itself is subhuman.

>>107252302
So can you fuck off from here already? Get a life. Go outside.

>>107217606
just because it's harder doesn't make it better.
recursion is just intellectual masturbation, OOP is easier to understand and make large programs with.

>>107252321
That's just because you're more experienced with OOP. It has nothing to do with FP being poor for large programs. Pandoc is fairly large and there are Haskell web developers too. It's no different from OOP programming languages. However Haskell did introduce new Preludes and optics to make large applications easier to handle. It's also a lot easier to maintain Haskell code in my experience because it's a lot shorter and encourages you to have minimize impure functions.

>>107251998
>has dynamic libraries issues due to not having an ABI.
https://hackage.haskell.org/package/plugins-1.6.2.1/docs/System-Plugins-Load.html
the only languages I can think of with a stable ABI are C and Fortran. even java and c# have the same compiler compatibility issues.
>because it's not popular is lacks many libraries
it lacks [libraries written in other language] and has its own libraries. there is no lack of high quality, useful libraries for everything from mathematics to web to database interfacing to graphics.

>>107251129
People having trouble with this need to remember a basic rule. All functions (->) take exactly one value and return exactly one value. No ifs and buts.

>>107252388
Java doesn't have that problem. You can share libraries and maven or gradle do that for you. Java has major compiled code versions to know if bytecode is compatible.

While it has a lot of libraries and some have much better quality than other programming languages, it still lacks libraries. The most obvious is a mature native UI library. There's one. All others are bindings.

>>107252454
>Java doesn't have that problem
I said it has the same dynamic loading issue, not that it exists because of ABI incompatibility. GHC checks code compatibility at a module level when dynamically linking. Neither Java nor GHC can load incompatible code any better than the other.
>The most obvious is a mature native UI library. There's one. All others are bindings.
All native UI libraries are bindings at their core, that's much the point.
>There's one
Do you need multiple? Is there a reason you can't use bindings?

>>107252449
>All functions (->) take exactly one value and return exactly one value.
And tuples help underline that:
(Int * Int * Int) -> Int
I can see immediately the boundary between inputs and outputs.
Int -> Int -> Int -> Int
No such obvious boundary. I have to slow down and reason about what I'm reading. After a while, this is a trivial example. If you're dealing with complex types, function type aliases stacked monad transformers, etc. it starts to quickly become a tarpit just to find out where inputs begin and end.
Currying/partial application is essential for functional programming, BUT I prefer for it to be explicit.

f :: Int -> Int -> Int -> Int
f = \a ->
           \b ->
                 \c ->
                      a + b + c

It really doesn't cost a whole lot to write this out, and since I can quickly jump between arrows in the signature and in the body to piece together a complete picture in a rapid manner, it ends up massively speeding up my ability to navigate and reason about a codebase. If I have no usecase for it to be partially applied, I'd greatly just prefer a function that takes a tuple:

f :: Int * Int * Int -> Int
f (a, b, c) = a + b + c

Implicit currying makes currying the default, which also leads to stuff like type alias hell when you've got a bunch of nested type aliases being used to describe a web of partially applied functions.

>>107252449
No. Functions can take any number of values and also return any number of values.

>>107254148
A tuple is only one value.

>>107251129
if you're filtered by operator associativity then lisps are pretty much the only suitable langs for you.
>>107253115
Basically the difference is that inputs are contravariant and outputs are covariant.

File: 1731046256970149.png (214 KB, 468x396)

214 KB PNG

>>107253115

fun tuplize f =
    case Compiler.arity f
      of 1 => fn (x) = f x
       | 2 => fn (x, y) = f x y
       ...

Why is functional programming so slow and memory hungry?

>>107254762
Because you're using hardware and operating systems not designed for it.

File: purple bird is roc lang.png (489 KB, 1793x837)

489 KB PNG

>>107254762
in-place mutation while maintaining practical purity is solving it.
the next generation of func langs are going to close the gap and probably even beat c/c++ with aggressive compile time assertions.

>>107254762
>Why is functional programming so slow
FP seems to be a bit faster than OOP in general: https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html
>and memory hungry?
Again, it's not.

>>107255001
>If I straight up lie for the fifth decade, people will finally believe me.
You had your chance old man and you lost.

>>107254953
It's surprising that these are all within a factor of 1.5 of each other. Shows that compilers have gotten pretty good

>>107255015
>lie
nigger the link to benchmark results is right there

>>107254953
Damn might give that a look

>>107253115
Int -> Int -> Int -> Int
is
Int -> (Int -> Int -> Int)
always and forever

File: fp vs c.png (77 KB, 1209x1239)

77 KB PNG

>>107255001
I'm not sure about that.

>>107255328
lisp isn't FP.
But is that racket with a chez backend?

>>107255351
If people say “Lisp isn’t functional” it doesn’t mean much. Languages themselves are rarely fully functional, with Haskell being the only one that’s close, but Lisp can justifiably be called functional too on the sense that you are allowed to mutate data, but Lisps support you using a functional style much better than anything else. Especially Scheme dialects.

>>107217644
>>107250637
pretty nuts. JS is an order of magnitude harder to parse than Scheme. Think of how many terawatts of electricity have been wasted on parsing JS slop because of some asshole in a suit at Netscape.

>>107255328
>C
I wonder about this...
Your GCC or Clang is written in C++ with tons of ASM optimizations.

>>107255351
>lisp isn't FP
yes it is. that was literally the point right from the beginning.

>>107254420

type X a = a -> a
type Y a b = a -> b -> a
type Z = forall r. (String -> r) -> r

f :: X Int -> Y String Bool -> (Bool -> Int)  -> String -> Int

Too easy?

infixl 8 :@@
data a :@@ b = Con1 (a, b)

infixl 7 :##
data a :## b = Con2 a b

type A = String :## Int
type B x = x :## Bool
type C = A :## Bool
type D x = x :@@ C

f :: D A -> B A -> Bool -> A

My original examples were completely contrived, these are a bit more realistic. I could have gotten cute with kinds and monad transformers, try to reflect some autistic continuation patterns maybe, but I think this is enough to illustrate my point. You're not going to know what these do at a glance and they're not even particularly nasty examples. I like being able to look at a function and know what the usage is at a glance.
The problem with implicit currying, as I said, is that it makes currying the default. It's comfy, but ends up making real world code that looks like the above. I just don't think it's worth it. If something is made to be composed so freely, fine, but it should be an intentional decision reflected in the function. It's a matter of taste, but I was asked to explain why I felt this way. It's all grounded in experiences lol.

>why is ada not more popular
>do people like bugs?

its called usability, the only functional language most devs I know can remotely get behind is elixir, but its faster to work in the same C/C#/C++/Java/JS/TS shit you've been writing for 10+ years. even I enjoy elixir to a degree, they have outstanding documentation

if you do a lot of coding outside of work, you honestly have no life. you gotta pick and choose and since its typically hard to convince a company to "lets try this one small app in this other language" you realistically don't get to write in the main 1-2 languages your company uses

>>107243937
Maybe do the bare minimum and either Google or GPT "CPU memory management" before posting stupid shit.

>>107255001
I just looked and java is literally twice as fast as Haskell on some tests while being more readable, the few ones it loses it doesn't lose by much.

>>107252694
Those are just excuses. Java can dynamically load libraries, no issues, while Haskell you change something you have to recompile everything around it.

You can use bindings that let you use GTK or Qt but that sucks.

>>107217665
Just a worse version of Standard ML.
Why this trash caught on instead of SML is beyond me. Use SML lads.

>>107217606
The sad reality of Haskell is that the ecosystem is bad and portability is suffering, GHC is now pretty much the only viable compiler, it's basically impossible to bootstrap, and they keep adding bloat and weird pointless features because it's an "experimental compiler". Continuous breaking compiler changes and a majority of the Haskell packages on hackage make use of GHC specific extensions so it's a monumental task to make another compiler that can build the packages on hackage. Not even mentioning the dumbass cabal versioning system.

It is a very nice language to use though if you ignore the GHC bloat and manage to build it on your platform.

>>107217606
Because c is taught in academia followed by cpp and it destroys poeples minds.
Exibit A
>>107217620

>>107219362
>functions call functions
>you can literaly time the execution time of function
>change function in repl
>repeat

Let me guess going trough clusterfuck of imperative C ans compiling it all is suposed to be easier.
Baby ducked faggot.

>>107237704
>>107252354
OOP is a retarded clusterfuck. Outside of theoretical examples and simulations of things representing real objects like characters in a game it makes things worse. Especially with shit like dependency injection.
FP is way more closer to natural way of thinking. The reason poeple findn it hard because they are close minded weak slaves whos preferences are decided by university and their boss.
You have poeple here claim C is easy and scheme is too difficult.
>>107238027
This smaltalk is OOP done right but its to simple and clear cut for tryhard midwits.
CPP is what they prefer. Even though US military used Smaltalk to write better and faster programs than cpp. Still cpp won out because bureaucrat codemonkeys and suits hate simplicity and if its replaced it wont be with sometuing lisp haskel forth like it will be rust or something even more complex.

>>107242695
unreadable FP shit of trivial fib() function

The only person I have worked with who has ever shilled for functional programming languages is not particularly skilled at programming. Not incompetent, but not one of the greats. The only person I know who has ever used functional programming is quite skilled and has no particular preference between programming paradigms except for whatever fits the task (he was doing some CRUD work and decided it was simpler to program functionally).

Maybe it's just my personal experience biasing me, but I can't take functional languages or their advocates all that seriously, even if functional programming itself is a nice tool.

>>107255952
Based actualcoder showing a real problem with a language. Too many people in this thread are operating on vibes and abstract theory rather than what's in front of their eyes.

>>107259284
>Outside of theoretical examples and simulations of things representing real objects like characters in a game it makes things worse
those theoretical examples are why people end up disliking OOP in the first place
it's always paired with no practical experience in writing object-oriented programs - only doing academic exercises/assignments does not count as experience, and so does not code written in an OOP language when you do all you can to avoid doing any OOP in it

>Especially with shit like dependency injection.
that's a completely random jab

>FP is way more closer to natural way of thinking. The reason poeple findn it hard because they are close minded weak slaves whos preferences are decided by university and their boss.
typical cope after being filtered by OOP

>CPP
don't use that abomination as a representation of OOP
C++ code is bad not because it's OOP, it's bad because it's C++

>>107217606
because sadly we live in a dysfunctional world

File: Screenshot_20251119-073021.png (142 KB, 1080x651)

142 KB PNG

>>107255952
>I deliberately obfuscated type signatures and now they are obfuscated, this is somehow Haskell's fault
>>107258593
Look again

>>107256037
Elixir is terrible, just use erlang

>>107259885
Haskell is unironically one of the best languages out there, and people are rightfully cagey about criticism because 99% of it is bullshit

>>107261564
Phenomenally based. At least there's a point to using Gleam (if tenuous), Elixir is just ruby boomer cope because they're afraid of a mildly alien syntax. God forbid.