Object-oriented programming should never have gained the traction it did. It lends itself to high single thread performance, up to about 4 threads, then the vast majority of programmers are simply too brainlet to effectively split their programs into more threads and still realize a performance gain.
Functional programming, meanwhile, lends itself to high thread count due to its inherently compartmented nature. It's easier to multithread, and sees performance gains from multithreading to a larger degree than OOP.
We know the direction of the industry right now: more cores, with slight generational per-core gains. Even Intel is playing the core game now that they can't hyperthread securely.
OOP should have been the exception, and FP the norm, not the other way around.
Object-oriented programming should never have gained the traction it did...
Other urls found in this thread:
blog post
pls subscribe
>Functional programming does multithreading so well that it can with a 32 core cpu match the performance of a single threaded program written in C.
>OOP should have been the exception, and FP the norm, not the other way around.
Why? OoP allows significantly more flexibility when this matters and you want to deal with state in arbitrary ways. This is more difficult to parallelism, but if you want that kind of dynamic behavior it would be silly to just give it up just in case.
there are good reasons to use oop, but for many if not most commercial applications oop is a liability
[segmentation fault intensifies]
[memory leak intensifies]
good luck with your 4-8 months of debug to make c work nearly that well
This is mostly only true of Haskell. The compiler needs to limit side effects enough that it can parallelize your code safely. OCaml for instance has no multi core support, and few languages offer the same multicore performance as Haskell.
Haskell is pretty much the only 'real' FP language in the senses most people mean.
I agree OOP is bullshit. And it might make multithreading harder, but I haven't analyzed that idea very much so could be wrong here.
I know very little about functional programming but it seems overly abstract and therefore bad for performance.
>I can't write code in C. SEGMENTATION FAULT! HELP ME!
I know C can be hard. Segemenation faults is a rare annoyance for more experienced programmers. There could be improvements made in this area but I haven't seen a good c replacement yet.
Takes an hour to debug shit in C tops
Lmaoing @ ur lyfe
>oop is pajeet shit
>functional is a meme
the only real programming is procedural, that's how computers works, the hardware is made for procedural
OOP is actually quite good at concurrency and parallelism if you do it properly (objects with no shared state passing messages).
>I know very little about functional programming but it seems overly abstract and therefore bad for performance.
as bad as poorly written oop? probably not
abstraction is a great safety net for retardation, and looking at today's software engineers, there needs to be a stronger safety net for retardation
OOP and functional aren't even mutually exclusive, you brainlet. You can do OOP with immutable objects just fine.
FP has different definitions to different people; just like OO has different definitions. If we were strict about things Erlang and Elixir would be the only OO languages because they are the only ones which handle messaging as it was originally intended, but that’s not what most people think.
Passing messages in many threads and there are now data races in your code. Procedural programming makes the distinction between data and procedures clear.
Using abstractions is a matter of tradeoffs. Most abstractions have some downsides. Leaky abstractions increase complexity and most abstractions are leaky. Also being super experienced in oop is meaningless unless you can prove that there is just a single advantage to oop. Sadly there are none.
>I know very little about functional programming but it seems overly abstract and therefore bad for performance.
Leaky abstractions are. Pure abstractions can improve performance because the compiler can optimize more aggressively. Haskell gets excellent performance because the compiler is free to interleave and reorder pure code in whatever manner it finds most efficient. But the abstractions of most high level languages are not this clean, so you pay a significant runtime penalty.
>FP and OO have vague definitions.
That's a bad thing. Please come up with precise definitions, then we can use them instead and get rid of the mental fog of vagueness.
>Functional programming is actually good for performance.
If you get too far away how the hardware through abstractions, just in you thinking, then that will cause a decrease in performance. If you do think about the low level stuff while doing high level stuff, that's a big mental load and decrease productivity. I might get convinced once people write impressive things in a functional language, and with high performance. ;-)
time to write some pascal
I've started learning programming (Python) over the past few days. I took programming in high school and it didn't go anywhere--partially, I think, because we used Java, and Java programs contain a bunch of stuff that looks completely meaningless to a noobie (and also because I was ~14-15).
Now at 24 I'm starting over with Python, and it just clicks, intuitively and easily...until I hit classes and objects and modules yesterday. I don't have much trouble with them conceptually or intellectually, but the syntax makes my brain hurt.
Facebooks spam fighting engine is written in Haskell and it handles millions of transactions per second.
The C/C++ model for parallelism is also very abstract. The scheduling and context switching is handled by your OS, not by you. All you provide are some locks to try and avoid race conditions, but those locks also decrease performance and can be difficult to get right. It would be better not to worry about them at all and use something like OpenMP when possible. But that’s an even bigger abstraction as your using a macro to do a bunch of things behind the scenes for you.
>OS has bad asbstractions and you can't avoid them
And you can't either.
>Mutexes all over the place is the only way to do multithreading without FP.
Yeah I used to do that. My new plan is to use very few mutexes and ensure no thread is using data another thread is writing to. Main thread when ready will schedule more work to do. And when main thread has to wait it will join in finishing the work. This should allow at least 2-3 different things to do, where multiple threads can work together, and keep the threads busy all the time. Never tried this, but it should work. I'm no expert in this area so don't take my advice. ;-)
you're actually the opposite of a Jow Forumstard
Jow Forumstards tend to learn the syntax and hate it, but don't understand why anyone would use classes and objects
>MY CODE IS SILLY
I’d recommend looking at OpenMP if that’s your plan. It was designed for that type of work which can be easily parallelized. What your doing is also very similar to how a pure language handles parallelism, except that it helps you avoid making the calls which can lead to bugs in your parallel code.
>Anonymous 04/25/19(Thu)19:19:47 No.70691753▶
right--wait, what are they programming? like, I get the sense that if you're making, say, a roguelike, you want to store your character and NPCs and pick-up-able objects as objects etc. are they all doing stats stuff?
Good OOP can work very well; however, this relies on using good design and enforcing read-only properties when possible. However, since it’s enforced by the compiler, good OOP takes more effort than FP. Essentially, OOP can utilize the powers of FP, but with much more effort, while FP has a steeper learning curve but enforces good reliability.
I suppose I’ve taken my FP knowledge and have applied it to OOP the best I can, and I get by.
OpenMP must be implemented by the compiler to introduce new syntax? Would prefer just a library, but I'll look into it.
Just use Erlang then.
Procedures barely produce output, their side effect thing is by design
This but unironically.
>you want to store your character and NPCs and pick-up-able objects as objects etc.
I don't think you really understand 'objects' in the sense of why people would want to use systems that support abstract polymorphic interfaces as means of accessing the state of an entity as opposed to direct access to data fields, which is really the core of OOP vs non-OOP that people are talking about when they discuss it.
Idot's who make zoo animal diagrams and use Java are not fit to discuss 'object orientation'.
Is there any language that has atomic variables for every single type.
If we had everything atomic, there would be no way to mess up with a multi-thread software.
OOP didn't fail because being useful to competent people was never what it was designed for. It was a corporate-motivated fad to turn every language into a tool that drooling retards can use without hurting themselves or each other.
The usual brainlets will reply en-masse. Meanwhile, I've worked on mammoth C only projects that have spanned over a decade on products that bring in billions of dollars are year. This is for critical hardware that has 9 9's of reliability. No goofy real-time OS frameworks. Complete C from scratch. You can literally drop into the main() { } where the whole system boots up and trace out 10 years and millions of lines of code. OOP was a meme at Uni to help brainlets decide on their major... that and a preferred language for brainlets who couldn't do sys level programming and wanted to go towards web-dev. In reality, just about every critical piece of software is written in C or C++ (LITE). You think of things in terms of data, control, threads, and locks. I've written solutions with over 40 processes and 100s of threads with no serious bugs or issues. You just have to have a big enough brain to 'visualize' the interactions and flows. It's the most comfortable programming ever. There's no such thing as an 'object' at the hardware level. It's just memory addresses and data. Abstractions remove you from reality. The future is indeed more cores. Sys level coding is clearly making its run back... not that it ever left.
^sums it up almost completely.
Multi-threading software isn't some unworldly complex paradigm. You have local thread data and you have data that is shared between threads. Data that shares needs proper protection. This gets to actual software engineering principles where you diagram/design/plan out your code before you author as opposed to being a code monkey that types out 60 lines of code per minute. Interaction diagrams/etc proof your code before you author it.
> Is there any language that has atomic variables for every single type.
atomics are handled in the OS via syscalls. They are costly. Which is why you author your atomics yourself and selectively use them only when needed.
>good luck with your 4-8 months of debug to make c work nearly that well
Because of its simplicity and transparency, C is actually extremely easy to debug
Brainlets will never understand this.
4-8 months of debugging means the engineers were trash tier. Large companies have an API/Platform independent team that segments "dangerous" code into infras. Even then, lower level engineers still call malloc/free often. Even when doing so, there is no real danger if you have a competent engineer. Further, there are all sorts of industry standard tools that check for memory leaks/etc. Our test suite took 2 hours to run. It did anywhere from static analysis/etc to full on cycles of systems test... this is in addition to your own unit test. Only then can you call a code review meeting. After 5-8 engineers grill your code, you need 3 senior engineers to sign off on it. Only then do you get authorization to commit. Nightly tests builds run and even more serious range of tests. You're pretty much squared away.
I feel like the anons shit posting about C have never worked a corporate job in their life. They speak as if you literally write out some shitty C code and are able to commit it to the main branch at will.. LMFAO