Yossi Kreinin
yosefk.com · Personal blog · on HN since 2008
Yossi Kreinin, a programmer and hardware engineer, writes about C++, programming languages, stack machines, and software and engineering culture.
What HN saysHN commenters recommend his C++ FQA as a classic takedown of C++, and praise his writing and humor alongside Steve Yegge's.
387HN people shared it
222linked it in comments
327stories submitted
12Kstory points
2 months agolast shared
2008people per year2026
Most-shared posts
- 1C++ Frequently Questioned Answers (2009)56 people · 121 points · first shared 2008 · 110 comments on HN
- 2Yosefk - My history with Forth & stack machines55 people · 810 points · first shared 2010 · 43 comments on HN
- 3Defective C++26 people · 59 points · first shared 2008 · 23 comments on HN
- 4The “high-level CPU” challenge (2008)19 people · 326 points · first shared 2009 · 127 comments on HN
- 5I can't believe I'm praising Tcl (2008)18 people · 268 points · first shared 2008 · 78 comments on HN
- 6Redundancy vs. dependencies: which is worse? (2008)18 people · 252 points · first shared 2008 · 39 comments on HN
- 7People can read their manager's mind (2015)15 people · 361 points · first shared 2015 · 70 comments on HN
- 8Do call yourself a programmer, and other career advice12 people · 509 points · first shared 2013 · 112 comments on HN
- 9Low-level is easy12 people · 408 points · first shared 2008 · 101 comments on HN
- 10What “Worse is Better vs The Right Thing” is really about11 people · 286 points · first shared 2012 · 46 comments on HN
- 11Blog11 people · first shared 2009
- 12SIMD < SIMT < SMT: Parallelism in Nvidia GPUs (2011)9 people · 291 points · first shared 2011 · 37 comments on HN
- 13Profiling with Ctrl-C9 people · 114 points · first shared 2024 · 40 comments on HN
- 1410x programmers – 10x more selective9 people · 33 points · first shared 2013 · 5 comments on HN
- 15“It's done in hardware so it's cheap” (2012)8 people · 311 points · first shared 2012 · 40 comments on HN
What HN people wrote when they linked it
guard-of-terra · 2017-01-30
Steve Yegge http://steve-yegge.blogspot.com/
Wil Shipley https://blog.wilshipley.com/
Yossi Kreinin http://yosefk.com/
All three brilliant, with good sense of humor and having good "vision thing"
jari_mustonen · 2025-11-12
The classic "Frequently Questioned Answers" is the ultimate takedown of this abomination of a language.
https://yosefk.com/c++fqa/
rep_lodsb · 2025-06-03
A great article about why this might be: https://yosefk.com/blog/my-history-with-forth-stack-machines.html
zahlman · 2024-12-24
> C++ became great to work with once C++11 was rolled out.
Have Yossi Kreinin's objections (https://yosefk.com/c++fqa/defective.html) been addressed yet? In particular, can I reuse source code from another file without a text preprocessor yet? Can I change a class' private members without recompilation, or am I still stuck with indirecting that behind a "pImpl" pointer in the class declaration in the header file? (Being able to use a smart pointer for that is not addressing the problem.) Are compiler error messages resulting from type mismatches reasonably short (without third-party tools like STLFilt) yet (never mind whether they're informative or pleasant to decipher)?
I know that "some parts of the FQA are not up to date with C++11 [and onward]", but I haven't heard of these problems being fixed.
AlexandrB · 2024-07-05
For more C++ wackiness, I recommend the C++ FQA: https://yosefk.com/c++fqa/
It's 15 years out of date now, but also timeless since C++ rarely/never removes old features or behaviours.
ReleaseCandidat · 2023-11-29
It's like the frequently questioned answers of C++: always a good read.
https://yosefk.com/c++fqa/
kragen · 2023-11-16
the classic problem for such number systems is linear algebra https://yosefk.com/blog/can-your-static-type-system-handle-linear-alge…
the issue is that each column and each row of a matrix can have different units. worse, gauss-jordan elimination chooses which rows to operate on dynamically. there is eventually a solution to this problem in c++ far down the comments thread
i don't see anything in https://numbat.dev/doc/type-system.html about aggregate types such as vectors, matrices, maps, arrays, lists, trees, records, etc., though it does have a suggestively named scalar type. i wonder how it handles this sort of thing
zdw · 2023-02-12
Monorepos are great... but only if you can invest in the tooling scale to handle them, and most companies can't invest in that like Google can. Hyrum Wright class tooling experts don't grow on trees.
A good article to reference when this topic gets raised:
http://yosefk.com/blog/dont-ask-if-a-monorepo-is-good-for-you-ask-if-y…
shadowofneptune · 2022-05-27
https://yosefk.com/blog/high-level-cpu-follow-up.html:
"Reduceron is designed to run Haskell, and focuses on an optimization problem I wasn't even aware of, that of graph reduction. [...] I think I'll look into this whole business some more. Pure functional languages are a weak spot of mine; for now, I can only say three things for sure: (1) side effects are a huge source of bugs, (2) although they get in the way of optimizers, side effects are a poor man's number one source of optimizations, so living without them isn't easy, and (3) the Reduceron is a pretty cool project."
H8crilA · 2021-07-28
This blog is amazing. I currently find myself in some sort of a conflict with management over the classic "new-features vs make the thing stable" situation. Management openly admits to valuing tech debt repayment, reliability etc. but I can clearly tell that it is not what is actually valued.
And why shouldn't I just skip code reviews, skip analyzing failure scenarios. Just churn out new shit at an "amazing pace" with little regard to fulfilling the harder part of the target objectives of the system.
http://yosefk.com/blog/people-can-read-their-managers-mind.html
We'll try to fix it when shit actually hits the fan, when the harder to achieve properties of the system are considered urgent again :)
(Just to make it clear: I am not working on medical devices or power plants or anything of this sort).
mumblemumble · 2021-01-10
Agreed. Though, that to comes at a cost, so I don't want to do it except when it's worth it.
http://yosefk.com/blog/redundancy-vs-dependencies-which-is-worse.html
camgunz · 2020-03-08
Second this. Read it all more than once; the insights it will give you into C are so valuable.
I'll also recommend C++ FQAs [1]. It's C++, yeah, but it's relevant to C in many places, and since a lot of systems programming now uses C++ as the lingua franca, it's a good, entertaining resource.
1: http://yosefk.com/c++fqa/
senderista · 2020-01-29
I'm gonna be That Guy and point out that rayon addresses parallelism, not concurrency (which is crossbeam's domain). My favorite explanation of the difference (by the inimitable yosefk): https://yosefk.com/blog/parallelism-and-concurrency-need-different-too…
lifthrasiir · 2020-01-06
I feel the following line (from [1], quote original) is a way better summary:
> Remember the freedom quote? "Forth is about the freedom to change the language, the compiler, the OS or even the hardware design".
> …And the freedom to change the problem.
[1] http://yosefk.com/blog/my-history-with-forth-stack-machines.html
a1369209993 · 2019-12-22
> a small number of constructs composed into more complex concepts.
Emphasis on small; my favorite Forth quote[0] is:
: ( 41 word drop ; immediate
( That was the definition for the comment word. )
( Now we can add comments to what we are doing! )
Of course, per the original topic:
> (You [can also do that] in Lisp but they don't teach you those parts at school. They teach the pure functional parts, where you can't do things that you can in C++. Bastards.) [1]
0: philburk_pforth/fth/system.fth:12
1: http://yosefk.com/blog/my-history-with-forth-stack-machines.html
ignoramous · 2019-02-20
Personally, a blog post by yosefk, the greatest CPP basher of all time [0], cleared the differences up for me: https://yosefk.com/blog/parallelism-and-concurrency-need-different-too…
[0] https://wiki.c2.com/?CppBashing
dasmoth · 2018-09-10
A bunch of comments on this post give pretty good advice about what to expect, and if you're in your first commercial job it's probably worth going with the flow. However, one thing I'll add is that it's worth watching out for the "academic bad, commercial practices good" mindset. Keep your eyes open, form your own opinions about what is and isn't working. Don't necessarily kick up a fuss about the things you don't like right now but do file them away for the future.
https://yosefk.com/blog/why-bad-scientific-code-beats-code-following-b… is an interesting counter-point to some of the usual commercial-vs-academic thinking.
vilhelm_s · 2018-03-30
I also highly recommend Yossi Kreinin's "What Worse is Better vs The Right Thing is really about" (https://yosefk.com/blog/what-worse-is-better-vs-the-right-thing-is-rea…
> Some view [markets and competition] as mostly good and others as mostly evil. This is loosely aligned with the "right" and the "left" [...] I will try to show that the disagreement about markets is at the core of the conflict presented in the classic essay, The Rise of Worse is Better [...] and not the trade-off between design simplicity and other considerations as the essay states. So the essay says one thing, and I'll show you it really says something else. Seriously, I will.
landtuna · 2018-03-07
Once you've got the basics down from a tutorial (old C++ or modern C++), move on to internalizing all the lessons here:
https://isocpp.org/faq (what Marshall Cline's excellent C++ FAQ has become)
and here:
https://herbsutter.com/gotw/ (Not as organized, but Herb Sutter wrestles with the essential questions of how to deal with the tricky bits of C++)
If you've got the cash, read Effective Modern C++ by Scott Meyers.
Finally, if you're ready to snark at all you've learned, read the C++ FQA:
http://yosefk.com/c++fqa/
nothrabannosir · 2017-06-02
> And I'm not here to argue how terrible C++ is (I've done enough of that elsewhere)
Haha that's one way to put it :p
For those new to this debate: Yosef Kreinin is the author of the (in)famous C++ Frequently Questioned Answers.[0] it's quite a body of work. Speaking of which: thanks for writing it, Yosef. I greatly enjoyed reading it back in the day, and it had a big impact on young me.
[0] http://yosefk.com/c++fqa/
qwertyuiop924 · 2017-01-28
That sounds about right. I've already linked it, but yosefk's take on the subject (http://yosefk.com/blog/my-history-with-forth-stack-machines.html) is worth reading, assuming that you've been living under a rock, and thus haven't already.
8918912819 · 2016-10-22
The C++ "community" has always been great at talking and presentations.
The reality is this and it is getting worse with every new feature:
http://yosefk.com/c++fqa/
That said, I'd love to use Ada.
jamesgeck0 · 2016-10-14
This article he linked recently is also worth a read. http://yosefk.com/blog/my-history-with-forth-stack-machines.html
nickpsecurity · 2016-09-17
Intro here:
https://users.ece.cmu.edu/~koopman/forth/hopl.html
Yosefk's write-up is the definitive one for me, though, showing an intro, some amazing stuff about it, weird stuff, and reasons for ultimately not going with it. Link:
http://yosefk.com/blog/my-history-with-forth-stack-machines.html
samatman · 2016-09-05
Good context on why Forth didn't pan out can be found here:
http://yosefk.com/blog/my-history-with-forth-stack-machines.html
I adore Forth and feel that it's in the small handful of languages / approaches to language that will permanently change a developer's understanding of the field. Perhaps if GreenArrays had succeeded well enough to make a few more generations of processor the landscape would be very different. Perhaps not.
Given today's architecture, the impedance mismatch between the stack paradigm and the register architecture costs Forth most of its advantage. Still, if there's another language that allows one to write an interactive assembler for a system with 8k of RAM, I've yet to hear of it.
The minimum investment in Forth, which I recommend to all thoughtful developers, is reading Programming a Problem Oriented Language by Chuck Moore, Forth's inventor.
wmf · 2016-07-15
This isn't a direct answer, but when hardware doesn't provide an "obviously useful" feature the reason is often because it wouldn't be faster. http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/high-level-cpu-follow-up.html
wolfgke · 2015-12-27
> a dedicated chip for executing javascript will be created
Unluckily this is not so easy: If you know a way, Yossi Kreinin would be really interested to know:
> http://yosefk.com/blog/the-high-level-cpu-challenge.html
And here is a list of ideas/problems that he identified within "the usual suspects":
> http://yosefk.com/blog/high-level-cpu-follow-up.html
_chris_ · 2015-10-09
Yah, the author does a follow-up blogpost (albeit, only a few days later, and not years, hehe).
http://yosefk.com/blog/high-level-cpu-follow-up.html
lbruder · 2015-07-28
Interesting article about the "Tcl experience" here: http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html
I love how simple the language is. Quick and easy to learn, small footprint, embeddable. For quite a while I used to prototype simple web services in Tcl, then convert to C for speed. The Tcl versions were so much easier to write, adapt, and debug, and had more features, because in C at some point I thought, meh, don't really need this...
_delirium · 2015-01-09
With modern hardware, I think it's not entirely obvious that specialized Lisp hardware would be a significant win. It's possible it would be, but not in the classic CISC-style approach of just baking important Lisp primitives into the instruction set. Without more, that would in practice just be implemented the way x86 is, translating the CISC-style instructions to RISC-style micro-ops, with no huge change to the basic CPU architecture. A more interesting question is whether significant architecture change would better suit some language paradigms.
There was an interesting series of posts on possibilities in that direction at Yosef K's blog:
http://yosefk.com/blog/the-high-level-cpu-challenge.html
http://yosefk.com/blog/high-level-cpu-follow-up.html