>>109026324
it isn't how a computer works

I've been having fun with Clojure lately. But I will never give up my beloved for loops.

>>109026324
i have and now i'm jobless

>>109026324
Because most of these look like ancient Egyptians wrote it to me.

>>109026324
Didn't like Lisp in college. Hated Scheme in college. Am ok with the bits and pieces of FP that have been shoehorned into C#. The bits that have leaked into Javascript are mostly anal cancer.

Am I right in my perception that some algorithms are really just easier to implement in imperative style? Or is this just because I'm treading walked ground, then?

>>109026328
You don't program logic gates in boolean algebra with manually applied electricity, quit LARPing

>>109026324
I like erlang

>>109029126
algoritms are literal math, so it's naturally fp

>>109026324
Most aren't really general-purpose in practice. You can code financial software with C++ and get it done rather nicely, but it's impossible with Haskell.

>>109029126
in-place mutation is the key.
As long as you can verify things before runtime, mutation is useful and FP can be fast without needing imperative style.
It's why Roc will become a very important sleeper language in the next decade.

>>109029214
MongoDB and React weren't made in Haskell or Clojure for a reason. When the rubber meets the road, that's where problems start to show and now you're in a bit of a problem because you're not using the right language for the job.

It's all about the practical applications.

>>109029229
>MongoDB
Datomic
>React
Phoenix

>>109026324
Because it doesn't make sense in the majority of circumstances.
It's great for backend stuff where you need fault tolerance on the beam vm like Erlang/Elixir (I in fact am not sure why you would use anything else for a backend).
None of the other ones provide that benefit because their underlying architecture isn't actually constructed well and many are just architecturally using the JVM.

It's also great for dynamic loose scripting w/ lisps, babashka + clojure work very well but it also embeds great w/ stuff like janet.

ML family stuff is autistic useless garbage though that there is 0 point to. Anytime people try to reduce things to "math" or try to solve issues in programming by having strict systems it's just the neurosis of a mentally ill freak

>>109029229
mongodb is declarative, so it's fp
haskell is also declarative, written in fp
so declarative languages can absolutely be written in fp

>>109029229
I believe functionals in some niches are very good, but those are really narrow ones. And you probably can do it more like a microservice thing and then write eveything else in a regular prog lang.

>>109029245
The common point I guess I should say is FP is actually really bad for actually interacting with computers as
>>109026328
says. You'd be far better off using something more procedural for most cases.

However if you are dealing with anything that's basically a transformation of inputs/outputs, and it benefits you to abstract away the underlying computer (say for scripting w/ lisps or backend stuff where you need to be able to start/end processes without impacting other ones) it's the best thing by far.

The ideal form of programming is something procedural and low level that can leverage higher level GC functional languages where it makes sense.

>>109026328
>>109029277
bull fucking shit?
Lisp can be used to create operating system (so is Haskell), you don't need imperative language to have access to low-level stuff
>procedural
FP is procedural

>>109029366
as I said people who care about ML languages are literally just mentally ill, imagine how fucked up you think to be to thing this post has any relation with reality at all

>>109029366
>FP is procedural
no it isnt

>>109026324
>hurr durr i wish i had a mathematics job instead of an engineering one
no thanks

>>109029126
no, you are right, and it's one of the many reasons FP hasn't doesn't and won't see widespread industry use
>>109029202
peak midwit

>>109029126
yes different languages and approaches are better at different things, is that really surprising to you?

>>109026328
This is like the mating call of morons

>>109026324
most of my programming is in scripting and these are all shit for scripting
the least ergonomically shit one (Clojure) still has to boot an entire jvm or use a worse runtime

>>109029933
>and these are all shit for scripting
>lisp
ok retard

>>109026324
Having been in the industry for 10 years now at many companies, I have learned

> Scala
Used by JVM retards who would post in this thread. Terrible.

> OCaml
Nice language, rarely used

> Clojure
Nobody ever tries this. I did. If you remove the parens from Lisp you get Elixir, and Elixir is right.

> Erlang, Elixir
Very rare skill. You would never use this in production because hiring for it is impossible. Great stack though.

> Haskell
Pretty great too, pretty rare for the same reason as Erlang & Elixir

Want to know the truth anon? You can use Rust at most companies, and Rust can be used in a pretty functional way. I do this all the time in my job.

Functional people are correct, 100%, except for the idea that it needs to be the entire language. Every part of your program that you write should be as functional as possible, while trading off for functionality (sometimes you need to print to the screen / send to the network), and performance (copying is rarely but sometimes expensive)

>>109029952
what part of
>still has to boot an entire jvm or use a worse runtime
did you miss
cli programs written in clojure take 5 seconds to start just to run for 200ms
>but other lisps
weren't in op's image

>>109026324
it doesn't compile to clean C89.

>>109029993
>>but other lisps
>weren't in op's image
try actually fucking looking at the image

>>109029993
doesn't it use some stripped down jvm compiled with graalvm?

>>109029980
Why shit on Scala but suck off Rust? Most companies don't need the fastest language, and those that do would be using C++ anyway. Having a GC and hybrid functional/OOP in an ML syntax is better than dealing with Rust's borrow checker and functional syntax bolted onto C++.

>>109030280
He's sucking off his boss, straight cock, not gock. Read it again, "muh industry realism".

>>109030280
I've had to maintain large codebases in each.

The issue I've had with most Scala codebases is I'm working with data-tards who are using Spark to do transformations. Their code is completely unreadable. Scala's type system is a more complex / worse version of what Rust is trying to achieve. Scala can never compete with the optimizations that Rust's compiler will do to your code.

Why does Scala need objects, case classes, regular classes? The generics system is too complex because it's weighed down by Java's class hierarchy / inheritance. The DSL features / macros that evolved in the Scala ecosystem are just too terse and are terrible to read.

I genuinely have written probably 20k lines of Scala in my life, and probably 500k lines of Rust (and about 500k lines of Go, too). Pre and post AI.

I do have a bias for Rust but it's due to trying everything out at scale. Let go of the hate in your heart and just give them a try for larger projects. The borrow checker is NOT your enemy. They just fixed C++'s horribly designed move semantics, and introduced a genuinely good idea (scopes = lifetimes = part of your mental model while programming). If you're writing RAII style C++ you will already have to think about this, Rust can just do it automatically.

With respect to functional programming, Rust is the PERFECT compromise.

>>109029126
>Am I right in my perception that some algorithms are really just easier to implement in imperative style?
why would this matter at this point? haven't all the algorithms been implemented by now?

i want to use Haskell but why is the tooling so fucking bad

F# is best, but noone taks about it. Ever. And you have the entire .net ecosystem (even though using it is a bit akward, since its all oop)

>>109030575
If F# wasn't as overlooked as it is, Microsoft would be fucking it over yearly with pointless syntax sugar additions like they are C#.
Singular downside is that finding F# jobs is impossible.

>>109030486
This kek
Nobody who says “muh industry” ever gives a serious reason why anything is good. They defend dogshit on the basis of them having to use it for work and nothing more

>>109026328
toasting this epic bait

File: 1731366455608273.png (86 KB, 498x498)

86 KB PNG

>>109030575
>discount ocaml (which is already a pile of crap) is best

>>109031106
OCaml.NET tyvm

>>109031053
Nailed it, even the "it's making bad from worse" means "having to use for work something less dogshit than I had to use for work", there's no solid bottom to it.

>>109029214
I don't know what you mean with financial software specifically, but Jane Street which is one of the biggest quantitative trading firms in the world, uses Ocaml exclusively

>>109031226
ocaml is more predictable than ghc for code monkeys

File: Screenshot_20260611_20032(...).jpg (300 KB, 1440x1983)

300 KB JPG

>>109031226
They use OCaml to implement HFT systems?

>>109029993
I see Common lisp in that image.

>>109031247
The part that runs in software, yeah.

>>109031357
You mean not the stuff on FPGAs that also has software. Okay, that is quite misleading in the total picture where OCaml is used more to attract maths grads than for its own sake.

>>109029648
I guess I had the vague idea that i.e. GUIs work best with OO, while straight data transformations work well with functional programming, but I never imagined it makes that big of a difference. But thinking about it, transforming a loop into a recursive function with a counter arguments just seems like a straight up complexity increase

>>109031384
What you're missing is that, besides syntax, the computational models often differ between programming paradigms. Different algos, data structures, computational primitives, everything different.
Meaning you spec into more specifics than just "a syntax + libraries" when picking a language.

>>109031376
>OCaml is used more to attract maths grads than for its own sake.
Then what disadvantage is the article talking about? Functional should be well suited to finance and they get their pick of grads.

>>109031429
Well, they're modifying the compiler for stricter typing, and hand-tuning the GC, which means re-introducing direct pointer manipulation and which may not be analyzable by the compiler.
So I don't see this example really generalizing? It's not a proper steelman argument for FP.
Article:
https://www.efinancialcareers.nl/news/2023/11/ocaml-vs-c-high-frequency-trading

>>109031226
>>109031247
>>109031357
No they don’t, python is also extensively used at JS lol

>>109029126
not at a fundamental level, but the way many languages do it it is harder, yes.

>>109031384
OO isn't good for anything

>>109029154
I do. Just through a couple of layers of abstraction. Just like if I had an AND logic gate I can define ANDn gate with an arbitrary number of inputs.
What's retarded is adding layers abstraction that add arbitrary restrictions for no gain (muh purity)
Just like if OP could lay transistors as they wish but insisted on only making NANDs from them, then making every other gate from NANDs

>>109029126
Yes, style can make as big a difference as you want. Declarative programming is also a thing, to make it obvious that you can have the same programming coded with 0 algorithms to begin with, "just because of a different style". It canbe a whole other game.

>>109027332
kek

Patiently waiting for OxCaml to get Windows support

>>109031479
>Article:
>Scheduled Maintenance
>Our systems are currently undergoing scheduled updates. Please try again later.
lol

>>109031590
Loads fine on my device, prob it's a firewall

>>109029126
Some of them yea. FP is good for dynamic programming/divide and conquer stuff

>>109031384
this is however not profoundly a fact in computation theory or anything

we are still getting better FP syntax/concepts over time and many of these did actually make it into language revisions of otherwise impereative/OOP languages

in the end functions that always do what they should do and nothing else ARE easiest to work as such

>>109031247
Jane street isn't really HFT

>>109031621
I suspected that because I wasn't finding cabling lengths to exchange routers measured in meters.

>>109026328
... unfortunately

File: B2B4C079-5DDF-4A61-8364-C(...).jpg (506 KB, 673x982)

506 KB JPG

>>109026328
Depends on the computer. This was one of fastest of it’s time beating out it’s contemporaries (Sun 3 workstations) based on the Knight machine.