Chris Parsons

It completely depends how you use it. There's so much misuse of it out there I can understand why people hate it so much. But done right it's an extremely valuable collaboration tool. I'd recommend the Cucumber Book if you want to read about how to use it well: http://pragprog.com/book/hwcuc/the-cucumber-book I've also blogged a lot about how to use Cucumber well here: http://chrismdp.com/tag/cucumber

interesting - I think I have to side with the Boundary (YC W23) folks on this one - if you want bleeding edge performance, you need to be able to open the box and hack on the insides. I don't agree fully with this article https://www.chrismdp.com/beyond-prompting/ but the comparison of punchards -> assembly -> c -> higher langs is quite useful here I just don't know when we'll get the right abstraction - i don't think langchain or dspy are the "C programming language" of AI yet (they could get there!). For now I'll stick to my "close to the metal" workbench where I can inspect tokens, reorder special tokens like system/user/JSON, and dynamically keep up with the idiosyncrasies of new models without being locked up waiting for library support.

You might like this: https://fungos.github.io/blog/2017/11/20/cr.h-a-simple-c-hot-reload-he… And this: https://chrismdp.com/2015/08/how-to-add-live-code-reload-to-your-game/

C++ compile times are a huge problem for large projects (and painful even on medium projects). The Go designers joke that Go was conceived while waiting for a C++ compile. (Google engineers I know tell me their full C++ compile times can be measured in hours.) AAA game devs I've met tell me their C++ project times are usually 30 min to an hour. On even the medium size projects I work on, the compile time difference between C and C++ can be magnitudes. C++ encourages templates, which are typically included by everything, which in turn causes lots of files to need to be recompiled. Both C/C++ have fragile ABIs so if you have built libraries and you change their memory layout, you need to recompile world. And in some cases, even if your library is internal and not external to your project, a bad build system or a bug can fail to detect this kind of change leading to subtle bugs/crashes, which then in turn encourages developers to do full rebuilds periodically. It is hard to find real world data converting C++ to C to measure compile times because nobody wants to invest in rewrites like this. However, I am also among those people that have shifted back to pure C from C++ and seen compile times improve by magnitudes. I sometimes work on slow devices, like the Raspberry Pi, and this really magnifies the difference. (On this, the C parts can take 10-20 minutes, and the C++ parts are measured in many hours.) This one person recently wrote about he switched back to C from C++.…