Mark Tomczak @mtomczak@qoto.org

I'm excited about the potential for #Rust in embedded automotive programming... But they really should've chosen a different language name for marketing reasons alone. ;)

So I don't do book recommendations because, cards on the table, I hardly read books these days. Too much time spent reading to read.

But Catherynne Valente is on track to release the sequel to Space Opera in November this year. Space Opera was the best book I read last year, and I can 1,000% recommend it if you haven't read it.

Can't wait for the next one.

https://www.amazon.com/Space-Oddity-Opera-Book-ebook/dp/B0BTZ8VM4V

A little bit about #objectorientedprogramming.

So I'm pretty cool on OOP these days, and the main reason is that I'm pretty hot on writing code that's easy to change in the future. The main advantage to OOP is that one couples the data to the methods that can manipulate the data. This is great, and makes intuitive sense.

The main disadvantage, I've decided, is that for just about all OOP languages I'm familiar with, this divides the world into two sorts of functions per object class:

* The methods the class knows about

* Everything else

... and I've come around to thinking that drawing that line is prognostication. Especially since basically all systems I deal with don't let you "open up" an object definition and add new methods. So you end up with `foo.something()` methods, but also `manipulate(foo)` methods living in some other library, and don't even get me started on whether methods that involve manipulating two objects should be `foo.do(bar)` or `bar.do(foo)` or both or neither. All of that is just noise. These days, I prefer to keep the set of "methods the class knows about" as close to zero as possible.

So what's replaced OOP for me? Usually, I'm nowadays working with interfaces, composition, functions, and generics. I find those work great, and the situations where I *really* want OOP are vanishingly small. If I want to find the "methods" of a data type, I just search the codebase for functions that take that data as an argument (trivial with modern IDEs and modern languages)... and hey, bonus, it finds me the additional functionality that someone else wrote in their module because they couldn't re-open an object to add behavior and they weren't in control of the module that defined the object!

Watched a neat documentary on the making of #TRON.

There are "glitch" effects where everything is lighter for a quarter second. Those weren't intentional. The movie used literally tons of film from Kodak to shoot it, and they didn't realize until halfway through production that they hadn't controlled process to keep the film the same order it had come off the truck. If you keep it in order, small manufacturing fluctuations end up continuous through your shots and the human eye doesn't really notice; if you jumble raw film canisters, the difference can be up to half an f-stop and it's very noticeable.

But since the entire film was ultimately animated at the end, they solved the problem by animating in a little sprite or circuit surge or something every time the film quality jumped and several brighter frames spun through.

Fixed it in post. ❤

Seriously, I don't know if this is an our-codebase problem or a general C++ problem, but I generally use three configs: debug symbols, production-optimized, and address sanitizer.

We use Bazel as our build management system, and changing configs is a "go get coffee" change. Ten to twenty minute recompiles.

#cplusplus

"Oh no... that value changed unexpectedly. That's probably... A memory leak. I'm gonna have to recompile with... *gulp*... The address sanitizer."

*intense grinding noises*

Open #Fediverse though / question.

On a thread about someone being brigaded here (and being able to use the tools available to shut out the bad actors and several of their servers, working as intended), it was mentioned by someone that it's relatively straightforward for bad actors who've had their servers banned to create new servers and start again.

To my knowledge, there is nothing really blocking that scenario. What are the options? Because the risk is that if it's as easy to set up a bad actor in Fedi as it is in, say, the email server ecosystem, then the long-term trend of this experiment is we end up where we are with email: a few big players with a heavy first-mover advantage because new nodes are assumed default-hostile, and it becomes nearly impossible to set up one's own independent node and have one's messages seen by people on the established servers.

#JavaScript is hard because it's the language of web browsers.

#Cplusplus is hard because it's the web browser of languages.

There's a lot about how #cplusplus (the language) behaves that boils down to C++ (the implementations). In other words, "Look, the most popular compilers are implemented in phases, this thing is resolved in phase 1, and you have to be explicit here even though the language allows you to be implicit elsewhere because in phase 1 it hasn't built the lookup tables to guess what that symbol means, so you are forced to tell it."

... this is only one step away from "It is that way because it is that way" which is, I think, one of the reasons the language is so slippery in my brain.

#Gmail just needs a big "DECLARE BANKRUPTCY" button that archives all non-starred unopened emails older than 1 day.

I can't help but wonder if the broad success of #Klingon as a language would be deeply frustrating to Ludwik Lejzer Zamenhof.

I'm finding my relationship with C++ improves if I think of it like a collection of wild, ecosystem-evolved beasts... And I'm Steve Irwin.

"Crikey! Would you look at *this* li'l bugger! It's a distance calculator on N-dimensional coordinates! Now most people'll never even see this in their lives, but it's part of the standard templates, so it's runnin' around in the background, doin' the heavy work for you. Oh, here! Would ya look at these templates! Fully recursive! So what we're gonna do is, we're gonna write a concrete implementation at N=2, shortcut the recursion right out from under 'er! This is wicked dangerous, but we've had some practice, so let's get crackin'."

Having worked at four places that have used #cplusplus, I now have a nugget of wisdom worth considering if you're in a position to hire engineers and are on a C++ project.

C++ is wide enough that it's a "dialect-y" language. I've worked at places that used macros and places that banned them. I've worked at places that relied on exceptions and places that forbade them in all contexts except the ones the compiler forces upon you. I've worked in places that are comfortable with the implicit casting rules and places that are hyper-paranoid and require you to use `explicit` everywhere and eschew default operator implementations.

Point is: if you interview someone for a C++ project and their résumé says they know C++, they probably don't know *your* C++ and that might introduce friction. Multiply your ramp-up time estimates appropriately.

When you see `//clang-format off` in the codebase.

https://youtube.com/clip/Ugkx2-gM-WB59b1uNQ1n_T7XbpELLA9FgfWW

Google: "The problems introduced by macros are especially severe when they are used to define pieces of a C++ API... As a consequence, we specifically disallow using macros in this way."

Also Google: https://github.com/google/flatbuffers/blob/master/src/idl_gen_text.cpp#L223