artagnon

Ruby.

I still love the language, and maintain my SSG that was written in Ruby over a decade ago. Shame that it's nearly dead now.

LLVM deprioritizes helper scripts such as update_analyze_test_checks.py, and the build infrastructure is far from perfect. Scripts like the ones categorizing PRs are very much unpaid work.

LLVM also deprioritizes general cleanup work, such as getting rid off passes that don’t work, and are rotting in the tree: of the top of my head, I can think of GVNSink, LoopFusion.

There are additional problems unique to LLVM, as it doesn’t have a dictator: there are multiple different dependence analysis in tree, for instance.

This echoes the problems we see in LLVM. Tooling is de-prioritized in several large corporation-funded open-source projects.

LatexML has come a long way. Even arXiv uses LatexML internally to offer HTML5 versions as of late 2023. It does have limitations in not supporting all packages, or producing a high-quality translation in all cases.

If you don't need to convert entire LaTeX documents, MathJaX and KaTeX are really good at rendering a subset of LaTeX as MathML/SVG. I run MathJaX + an xypic extension for commutative diagrams with server-side rendering on my website, and it works great in practice.

It's standard MathJaX that's rendered client-side. I managed to get MathJaX + XyPic rendered server-side on my website, which is a lot nicer.

Oh no! I think we’re out of luck if my reading of [1] is right. Sonos API only supports streaming from a single URL.

[1]: https://docs.sonos.com/docs/streaming-basics

Very slick interface with a nice selection of sounds! I would definitely use this if only it could connect to my Sonos.

Honestly, everyone working with C++ sticks to a select subset of the language that they've chosen for their project, or the project they're contributing to. Nobody knows all of C++. Personally, I don't mind C++ forking out in different directions and accepting diverse proposals; while I wouldn't bother to use them myself, I realize that it may be useful to other people.

C++ is an engineer's language, and it's ridiculous to imagine that we'd ever need a C++2.0 that cleans it up. Subjectively, you could say that some features are "ugly", but this is an evolutionary process, and there are bound to be vestigial features.

Yes, there are memory safety issues, but in practice, these are isolated in very few places. Take a compiler like LLVM for instance: most developers are working on transforms or analyses, and they're exposed to zero manual memory management. Sure, the Pass Manager needs to build passes, and the IR needs to be allocated, but that's about all the manual memory management there is.

Personally, I couldn't care less about standardized argv-parsing, as each project has its own set of complex requirements. There are JSON parsing libraries available for C++, and I don't see why it should be standardized. Faster hashing in std could be a low-priority feature, but projects like LLVM have their own optimized version of std data structures and algorithms.

I suppose a module system could be useful; most C++ projects are built with CMake which is already very good at finding and linking dependencies. Personally, my biggest pain point is compile-times, but that's really an LLVM/Clang problem.

Overall, the article doesn't seem to be written by someone who has a lot of experience with large C++ codebases.

God, this is so dehumanizing. When I think about the places such a thing can possibly happen, I think of North America and third world countries.