• Monday, 05/22/2023 ** 10:57 Writing for clear communication

• Do not start a sentence with 'it'. Whenever a sentence addresses a subject, use a specifier that will either provide additional context to the subject or
• Use the simplest words that you can. The English language has too many words. Using words that are not very common can cause confusion. Assuming a definition or having an incorrect understanding of the definition of a word or structure can confuse the reader.
• Use the simplest sentence structure that you can. Sentences that are more concise are more easily read and understood by more people.
• Use proper English with as much parallel structure as is reasonable. Parallel structure can help recipients read faster.
• Use a proper subset of English. Just like programming or mathematics, if a well-defined specification exists, your intention will be more easily understood. The English language relies heavily on context. This complexity can add ambiguity to sentences. Avoid complex sentence structures and vocabulary to avoid this ambiguity.
• Use as much detail as is necessary to include for the subject.
• Break down long passages or essays into more easily understood contents with clear headings that summarize the purpose of the passage. Introducing differences in font size, spacing, and formatting adds additional structure to the text, informing the reader of the document's structure explicitly.
• Use examples if your description is abstract. [Descriptive examples should be added here].
• If using an expressive platform for writing, use all of the tools available to you. Include images, drawings, and diagrams if possible. The interactive diagram, if executed correctly, is the best tool available to explain information today. Make heavy use of tags, links, and other expressive tools that your writing allows. Improving the user interface to your writing can communicate your ideas in a more expressive way. Linking to other people, documents, tables, and other information throughout your knowledge base can help readers understand how your document relates to other parts of the project or business. ** 11:52
• Don't omit context from the document. If all of the context is available in writing, everyone reading the document can understand the motivation. If context is missing, a reader might not be aware that the context exists. Avoid including an unreasonable amount of context, but if someone who reads the document does not have an easy way to find that context, the document loses purpose.
• Define abstract concepts and use those definitions exclusively when referencing the concept. If words are not chosen carefully, different people are speaking different languages and therefore saying different things. Definitions are vital to communication. ** 23:00 Technology appreciation thread!

Nix is getting better and better. This new Emacs interface - running on Wayland and natively compiled - feels so, so fast compared to earlier today. Glad I rebuilt.

Nushell is the easiest tool I've ever used to write comprehensive shell scripts. I'm incredibly impressed - casual-looking comments fit the 'vibe' of an ad-hoc script but they're instantly used as documentation for their associated commands. Crazy! Check jakeisnt/nixcfg on github at today's date - the hey command was rewritten from an 85mb clojure bundle to a 'free' (because we're already using nushell) shell script that's a third of the number of lines of code and far, far easier to understand - while preserving the same kinds of type information that clojure was (just under the hood). JT and the rest of the nushell crowd are brilliant creators of user interfaces.

Can't wait to see how I can get interactive polling commands working and similar - would love to make reactive tables.

Zig feels just as modern. Still sort of undecided on the Rust vs. Zig spectrum, but I've gotten quite tired with the typed baggage of Rust while Zig lets me goof off and do more or less whatever I'd like (for good or bad). My flipbook project is definitely rendering a raw pointer instead of the buffer that it's supposed to right now, but we'll figure it out.

Blown away by the comptime feature and how dynamic it feels. I've never been able to create a data structure on the fly before and use it in normal code with a strongly typed language such as this - but comptime feels magical, automatically shifting 'meta' code to the compile time step to interpret normal Zig code and bake in the results. I've used it to create rendering engine that uses a fixed-size buffer - without any heap allocations! The buffer struct definition is inlined (? i think) up front at compile time so that the instantiation can be so seamless.

I'm lacking the proper programming language words to describe this, but I also love the build system and how seamlessly I can integrate with C code - a process that's quite difficult for C <-> Rust, javascript <-> typescript, etc... both systems that claim to be easy to do but that, in practice, require modifying the build system of your project and introducing typed headers (which can be real or fake).

Zig builds Clang into its own compiler and simply has all of the information from the C headers and their types available, and has a memory model that maps cleanly to the same LLVM types that clang's C code uses. Brilliant. I don't have to learn Bazel's Python dialect after all - I can just get to work.

Wondering if Rust or Zig with hot reloading would be possible. Zig's anytype annotation is lovely - letting you wing it with systems code and test solutions fast - but not sure how well systems like that scale. Rust is slow with binaries that are too big - Trying to get my launch program - a simple egui app - to work on my computer was a disgusting mess when having to build from source. We'll stick to Zig and stick to boring libraries that can be dynamically linked (when necessary) or my own code (when possible) to make transpilation from scratch a fast process for as long as we can. Fast compile times are so, so wonderful for creating and distributing software. No messing around with caches or storage. You can send someone the source code and they can change it and compile their own tool. Simply brilliant. ** 23:33 Software keeps getting better and better, but only as a result of the significant amount of effort put behind making open-source software faster and more useful for the prople on the other side of the screen. Incredibly reassuring to see great projects succeed and to feel my computer become faster and use resources with greater optimality.

Hurts me how slow darktable is. I'm not sure why it's that way but I want it to be faster. that tool is the weakest link of my graphics programs and I'd love a replacement - or for the developers of that software to make it better and faster and more beautiful. The code runs and works for sure, but does not look great - and you can feel that pain as an end user. The external interface and feel of software closely mirrors the structure of the code and the organization of the team behind it.

Just opened my web browser. Half the websites I open feel like software going backwards. Feels like web software gets slower no matter how fast my computer is. Upsetting.