Be C++ programmer

FP has some valid use cases unlike OOP.

Where is this chart is C?

It does, but pretending it's the savior of everything that's right and holy is fucking obnoxious.

For some reason functional paradigms tend to turn programmers into whiny bitches.

You can do some (?) FP stuff in C++.

1. I'm not an "FP programmer"
2. Debugging is a normal part of programming, and doesn't mean that you "can't program to shit". The fact that you don't understand this shows that you've never written any non-fizzbuzz software

C is neck and neck with C++ in 99% cases

In 0.5% cases C++ is faster
In 0.5% cases C is faster

>unlike OOP
Orly

The dude I was replying to claimed it's normal for C++ programmers to spend weeks on searching for the cause of segfault and implying FP is better because you don't have to deal with that shit.

Fair enough but that attitude is obnoxious and shows you have no fucking idea how C++ programming is done. When someone's searching for a segfault you better fucking thank him because he's the reason your la-la land FP programs work to begin with.

How can asm be slower than anything? just decompile the fastest one and voila, asm is as fast

OOP tends to create spaghetti code. Also the extra time it takes to write reusable code isn't worth it.

Functional programming is for people who are intellectually incapable of understanding program states.

>be C++ programmer
I'm so, so sorry

why can't Jow Forums just collectively agree that people like you are either stupid or deliberately misleading

In most situations? Yes.
In ALL situations? You're high.

In 0.5% cases C++ is faster because RAII handles heap fragmentation better
In every other case, it is either almost as fast as C, statistically significantly slower than C, or neck-and-neck with C with higher memory consumption because the program is literally pure C, but run through a C++ compiler for RAII

C++ is C with, somehow, extra steps.

this wtf.

Good luck hand-optimizing asm to the same level a C++ compiler would.

On the off chance you are serious,
1. What your chart says, OP, is that MLton gives you 75% of the performance of C++ with all the perks of FP in one the most computationally intense tasks that exist. Not bad at all. Even Ocaml gives you 50% and Haskell 30%.
2. What your greentext says is that FP programmers talk about correctness, YOU try to change the subject to performance, but they go back to talking about correctness. Presumably, it's because being 30%-75% as fast as C++ is enough for them.
3. The chart was made in 2010 by Jon Harrop, who happens to be an FP and OCaml advocate, but not a very good Haskell programmer. The Haskell solution could be improved. OCaml and GHC also are better now than they were then.

so you're telling me I should learn assembly?

You should just use Fortran for numerics. No dynamic allocations, baby!

Honestly... I'm surprised Hasklel is only 3 times slower than C++

It's a place full of trolling and a kind of programmer's chuunibyou.

it's standard standard library is fucking trash

its easy as fuck?? compilers are literally monkey tier, the only things that compilers have over hand writing decent assembly is the time it takes to code and catching pajeet up to speed when he takes your job and asks what the weird symbols mean.

Real men write in machine code.

you can get away with not knowing assembly if you only ever mess with high level languages and dont have to optimise down to the uop, but if you think security, malware, os theory etc etc is cool its worth learning 100% its actually really easy once you get past the initial learning curve.

good lock hunting "zero-cost abstractions" that GCC won't optimize

>the only things that compilers have over hand writing decent assembly is the time it takes to code
For small subroutines, sure. However, very few, if any, humans would be capable of doing whole-program optimization by hand on the equivalent of 100k lines of C even if they had years to do it.

only times ive ever written in machine code was to put instructions inside other instructions to intentionally misalign non-recursive static code analysis, if you code it write it can mess up recursive ones like ida as well, i wanted to write some self modifying code but couldnt think of any applicable uses for it beyond obfuscation and im lazy. Beyond those two cases i cant think of an advantage to machine code because it takes way to long.

It's useful for reverse engineering. I can't think of many other uses.

I don't even know that much about asm but even I realize you're a moron.

>i wanted to write some self modifying code but couldnt think of any applicable uses for it beyond obfuscation
It's cool for tuning demo scene effects in real time. Give the user some sliders and patch the values in at runtime.

id disagree to an extent because you can write ALOT of what youd write in C using macros in nasm etc. whilst still retaining a 1 to 1 relationship with your machine code, that said i dont know of any asm projects that large other than that russian malware agent bz or w/e its called, id say that very large projects also benefit from the clarity of a higher level language being actual words as well as asm isnt very scalable in terms of working as a team but ive written decently large projects like crypters etc. entirely in asm.

The thing i like so much about asm is that i know EXACTLY what instructions my code is going to produce and what all the dependencies are going to be.

its also not incredibly important to get an extra cycle here or there for code thats only ever going to run once on an edge case or w/e.

Considering they use 95% of the same compiler and 95% of the same syntax, it's not surprising that C and C++ is on par. Hell with minimal alterations, you can port you C code to a C++ compiler

And RAII is a hell of a reason to switch

pajeet who let you out of the java containment chamber, use an actual argument other than "lol i dont know about that but ur dumb huhuh"

So... is Java /our/ lang?

You're not better than your compiler at optimizing assembly.

some demoscene stuff is beautiful but only has really specific use cases like incredibly efficiently looping 3 times, and alot of the instructions in x86 are stupidly slow because they not used very often and because they arent used very often they arent improved making a cycle that promotes only the more popular instructions being improved.

C/C++ might be fast for number crunching, but for string operations even JavaScript is faster. And I'm quite certain which of these I'm going to do more often.

are you baiting or do you genuinely believe its impossible to write better code than a compiler?

#include
int main(){
[](){std::cout

It's a matter of using a decent string library. For C pick github.com/antirez/sds.

I don't believe it's generally impossible to write better code than the compiler.

I do however believe you're not capable of it.

It's possible but almost never worth the effort.

Good post on Jow Forums for once.

>never wrote asm
>"COMPILERS ARE MAGIC! IT'S PHYSICALLY IMPOSSIBLE TO UNDERSTAND THEM!"
Who cares about your opinion, you dumb brainlet.
Go back to web "programming" general.

Can't see shit senpai

why not? just compile but dont assemble the code, look through what the compiler produced in all your important functions, optimize whilst preserving semantics and then assemble. Or hand write your important functions at the very least, being scared of assembly when its very easy to work with is some stupid notation bad programmers got around the times cpus started getting very fast.

t-ty user :c

>Haskell vs. Ada vs. C++ vs. Awk vs. ... An experiment in software prototyping productivity (1994)
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.368.1058&rep=rep1&type=pdf

Attached: chrome_2018-05-30_15-57-02.png (1105x300, 81K)

>24 years old anecdata
Based.

>Be C++ programmer
>Become insecure and angry

>LuaJit = 8
>C++ = 10
>C = 10
>ASM = 10
C++ LITERALLY beaten by an interpreted language. Compiled languaged BTFO?

You should not blindy trust c++ compiler to do proper optimizations. You must have a decent asm knowledge to optimize your program when writing in c++ to have it be optimized.

same for c++ and fucking everything else ever

>ASM - 10
In what world would anyone take this chart seriously?

in a world of suboptimal implementations

Roller coaster tycoon and zsnes are both written in assembly.

If you can do C/C++ you can hand-optimize assembly at crucial locations of critical algorithms. Otherwise fuck you, it's not needed.

This is why Lisp failed, dispite the protests of neckbeards. Purity means nothing when programs use a shit-ton of memory and take an age to run.

Haskell is fast enough for most applications.

>Lisp
>purity

This is most likely retarded test. Jit is optimising loops and if it can determine that running loop doesn’t change anything it will simply skip it. That’s the only possibility I see for JDK being faster than c or asm.

Lisp isn't purely functional. Modern implementations like SBCL are actually pretty fast. It died out because of a false reputation as a language designed expressly for AI, even though most dialects are general purpose languages.

std::copy is faster then memcpy

>LuaJIT and V8 faster than C and C++
Basically a guarantee that the benchmark is too simple and doesn't represent reality in any way.

basically, no

But your programs have no meaning if they take years to build and filled with all sorts of security holes and bugs.

Or maybe the code is just shit. Last week a friend of mine complained that C# would be a lot faster then C++ processing huge amounts of data.
I argued well maybe, JITs are amazing these days and with runtime information maybe there are some optimizations impossible to do statically.
Then I looked into the code. He used std::list..

Shit I'm going to redesign all my programs now because you totally dismantled functional programming.

>JavaScript (a dialect of lisp)
t. Never wrote in Lisp

On the contrary. Worse is better don't you know?

>I argued well maybe, JITs are amazing these days and with runtime information maybe there are some optimizations impossible to do statically.
You forget that those optimizations and their success are relatively frugal compared to the optimizations a AOT compiler can afford.
And in the end, a JIT compiler can't fix the more dynamic parts in a programming language. C# and Java have rather few actually dynamic parts, but JS, Lua or Python are another story.

>LuaJit
>interpreted

choose one

>"Modern" Lisp is actually quite fast

Well it couldn't get much slower could it?

Tell me how you do OOP with Lisp again. I could do with a laugh.

>JavaScript (a dialect of lisp)

Attached: 1524047667870.jpg (1280x720, 94K)

>OCaml
Fuck this shitz they taught us this at uni, never seen any use of that language, on the project's page there's a list of known organizations that use OCaml and it's basically the institute that created it, some no name start-ups and Facebook (because they use like one library with some elements written in OCaml). Absolute failure of a language.

>JavaScript (a dialect of lisp)

Attached: 64 keks avgn.jpg (600x6009, 405K)

I take your slut and raise you an Angel.

Attached: 1526839567014.png (800x770, 822K)

>C++
>not functional
#include
#include

template
auto operator>>(Monad muh_monad, Function muh_function) {
return [=] { return muh_function(muh_monad())(); };
}

auto write(std::string str) {
return [=] {
std::cout >
[](auto _) { return write("haskell "); } >>
[](auto _) { return write("now\n"); };

io();
}