DNEAVES

I think the shallowness of understanding also stems from the codebase itself, and moreso that than the Ai finding where something is.

A poorly organized codebase, dynamic file imports lsp’s can’t follow, lack of annotations on unclearly-named arguments, etc. are way worse for understanding a codebase than Ai saying “the thing you need is this method”, which Ai could also explain how it got there at least. At that point, Ai is a better than what they would have without it.

Write clean, understandable code. Document it, too. Everyone will thank you

Functional language developers are obsessed with side effects but I rarely ever see problems with it in real code. Like I can remember once in maybe 10 years setting a developer write a “get” method that also wrote to a file. Caught during code review, rewritten easily.

While, sure, get methods writing files could happen in side-effectful code, the side-effect concern is less about that and more of expectations. With OOP languages, class methods can create a dichotomy of expected returns: Using a list reversal as an example, will a list.reverse(some_list) function reverse the list in-place, or return a copy of the reversed list and leave the original in-tact? To know the answer, you have to check the docs or the type signature (which, yes, is easy, but the answer isn’t obvious). Which, the main concern is trying to debug things “magically changing”, since nested function calls and inherited function calls can modify something from layers upon layers of abstraction away.

FP languages tend to not have this dichotomy, with very few exceptions like IO in Haskell, ports in Elm and Gren, external functions in Gleam, or FFI in Haskell, to name some ways from languages I know, all of which usually move the control of the program outside the language’s “default area”, anyway. Outside the exceptions, to reverse a list a reverse function needs to be given that list explicitly, and it also will be returning a copy of the list reversed, only and always

I’d imagine it’s as simple as Nvidia doesn’t want to support OpenCL because CUDA forces people into their market, and AMD doesn’t want to support OpenCL because Rocm forces people into their market. Open/free standards are great for smaller players in a market, but in the graphics space I don’t think a smaller player in the market exists, and if they do, no one seems interested in them.

It’s not a bug, it’s a feature!

!![] + !![] == 2

At the same time, that is part of the developer experience, so the tutorial is still accurate

If its something that represents mutually exclusive states, like the license plates examples (Gov’t, Embassy, Learner), an enum like 4wd mentioned is a better idea than many boolean keys. This would also be the switch/case question you posed. For a “regular case”, I would include that in the enum, but if you create an enum that only contains “special cases”, you can always set it to null.

On the case of booleans, I would suggest avoiding them unless it is necessary, and truly a binary (as in, two-option, not binary numbers), self-contained-in-one-key thing (obligatory anti-boolean video). If the use case is to say what a different key’s object represents, you don’t need it (see: enums. You’ll thank yourself later if you add a third option). If the use case for using it is saying another key contains value(s), you don’t need it. Many languages can handle the idea of “data is present, or not present” (either with “truthy/falsey” behavior interpreting “data-or-null”, or “Maybe/Option” types), so often “data-or-null” can suffice instead of booleans.

I would suggest trying to always include all keys of a present object, even if it’s value is null or not applicable. It will prevent headaches later when code might try to access that key, but it isn’t present. This approach might also help you decide to reduce the quantity of keys, if they could be consolidated (as in taking booleans and converting to a state-like enum, as mentioned above), or removed (if unused and/or deprecated).