Hacker News new | past | comments | ask | show | jobs | submit login

It shows that abstractions are leaky as f :)



No, this simply shows that abstraction slows performance, which is usually a worthwhile tradeoff.

Leaky abstractions are a different problem altogether.


The problem with that tradeoff is that you only compare the performance with the 'top layer of abstraction' that is already implemented and not with the baseline.

Death by thousand cuts


Not usually. There's a stack of a thousand abstractions between me writing this and you reading it, but it still works fine.


Yep. I suspect most people here could write a working fizzbuzz on a whiteboard in language of choice in under 5 mins during a job interview.

Sure your Python/JavaScript/Haskell/Rust version builds on a bunch of abstractions, but it’ll run on just about anything, and …

“I've spent months working on this program”

That’s not what your boss wants to hear.


You can pump out a Modern C++ version in 5 minutes too that will run loops (haha) around the higher level languages. The readability won't even be very different...


True. I bet the Rust guys would come close too.

But realistically? For anything except code golf and nerd fights, the actual client requirement is probably better met by a WordPress widget written in php/html, because what they asked for is something that'll print the fizz buzz all the way up to the person's age when they log into the company website... Nobody is even going to notice if it takes a whole second to fizz buzz all the way to 95 :-)

(Now I'm wondering if that guy's raw hyper optimised x86 assembly can get transpiled to WASM... Because nerd fights are fun.)


> Now I'm wondering if that guy's raw hyper optimised x86 assembly can get transpiled to WASM

Not really. WASM is significantly simpler and more abstract than x86 assembly, and has a JIT compile step that probably wouldn't get anywhere near as optimized. You could probably hand-write a WASM version that would JIT compile to something roughly similar and still get very good performance, but it would probably be more comparable to the other compiled versions at best, rather than the x86 ASM one.


> probably wouldn't get anywhere near as optimized.

Yeah, I'm not doing this for performance, I'm doing out for nerd fight points and the lulz :-)

The Most Hightly Optimised Fizz Buzz EVER!

In your browser!

As a service.

Join the waiting list now! Email: [_____________] [submit]


>But realistically? For anything except code golf and nerd fights, the actual client requirement is probably better met by a WordPress widget written in php/html, because what they asked for is something that'll print the fizz buzz all the way up to the person's age when they log into the company website... Nobody is even going to notice if it takes a whole second to fizz buzz all the way to 95 :-)

What if 100 million people log from different corners of the world? Would the WordPress widget still cut it?


In that scenario, the fizzbuzz widget is gonna be just a tiny tiny part of your WordPress scaling problem…


Not only you can write a modern C++ version in 5 minutes but by carefully choosing your subset of C++ and coding style you can do that while being as readable and maintainable as in higher level languages. C++ isn't hard because it's low level, it is hard because it is a Frankenstein monster and I don't think there is a living being that masters all the complexities of C++. I would love to see a C++ Next version with lots of crap cut down from it.


C++ next version with lots of crap cut down is called Rust. ;)


Judging by it's age and how much crap it's accumulated already, I think in 10 years time Rust won't be in a much better situation.

Similarly, judging by C++'s current trajectory, in 10 years it will have a simplified subset (enforced with something similar to --pedantic) which is easier to get right than Rust is today. Also, it will have a static analysis borrow checker based on clang-tidy.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: