Yossi Kreinin

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.

> 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.

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).

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

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-really-about.html)

> 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.

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-best-practices.html is an interesting counter-point to some of the usual commercial-vs-academic thinking.