A non-profit organization that teaches programming languages.

I like all "effective $progLang" books. In case of Rust, I might even finish Effective Rust before the Programming Rust book.

That rare stackoverflow answer written by a real expert, worth saving.

Would've been nice to see these before reading the novel "Three Body Problem".

A gallery of Sylvia Ritter's artwork about Ubuntu releases.

NocoDB is an open-source alternative to the proprietary AirTable. It can be used locally without ever connecting to their cloud offering. It uses a SQLite database by default when used locally, without any configuration. The sign-up is also local.

I don't want to use Notion or AppFlowy, just for tables. This seems like a better alternative.

The same GitHub repository of awesome-selfhosted, but in a website format.

The wiki for computer chips and processor architectures.

This paper by Leiserson et. al (the L from the famous CLRS Algorithms book) explores how computer performance can continue to improve after Moore's law hits its limits. In this paper from 2020, the authors predict that there will be diminishing returns after 5 nm transistors, but there are 3 nm and 2 nm transistors being manufactured in 2024 (not available to China though they have the highest number of supercomputers/country). Clock speed had pretty much stopped increasing since 2004 due to increasing power requirements. We cannot continue to reduce voltage with increasing clock frequency (Dennard scaling).

The gains at the bottom are due to improvements in semiconductor technology - the tide that lifts all boats. The gains at the top on the other hand come from software performance optimization (while taking the target hardware into account), algorithmic efficiency and hardware streamlining.

Unlike the historical gains at the Bottom, however, the gains at the Top will be opportunistic, uneven, sporadic, and subject to diminishing returns as problems become better explored.

Looks like it will be great for the use case of maintaining one project's documentation in a single file.

I just migrated one very large org-mode file which was serving as my FreedomBox development diary to Feather Wiki. It looks better organized into multiple pages. I might keep one quine file per significant project.

I am still sticking to TiddlyWiki for my general memex and journaling purposes.

A tutorial on developing GTK4 application using Rust. A TODO list app is built as part of the tutorial.

Not really a substitute to reading the Rust book, but is a good reference.

Tools for building networked communities. Spritely Goblins has an implementation of object-capabilities security system based on actors. Actors have easy local transactionality (allowing time travel) and also location transparency.

Promise-pipelining is not just a convenience for programmers, but also reduces the overall number of roundtrips on the network.

I didn't find the equivalent of a fire-and-forget message in Goblins. Every asynchronous message needs to be handled with a promise.

An object-capability security system can do several operations through simple object-oriented programming, without the need for cryptography. The object reference that is passed is unforgeable by default.

Guile has an OOP system called GOOPS, but Spritely Goblins isn't using that.

Turns are cheap local transactions in Goblins. I didn't see distributed transactions in Goblins.

The Unum pattern seems interesting.

The meme, but as a HTML page with clickable links to articles.

Why programming languages don't provide graphs in their standard libraries:

• There are many different kinds of graphs
• There are many different representations of each kind of graph
• There are many different graph algorithms
• Graph algorithm performance is very sensitive to graph representation and implementation details
• People run very expensive algorithms on very big graphs.

A journalist lamenting the ways in which technology has ruined his life.

A book to learn about TiddlyWiki.

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.

1. Red Flags of a Toxic Tech Company
   • Vague Answers About Work/Life Balance
   • Long Hours Are a Badge of Honor
   • Suspiciously High Salary for the Title
2. Why Do We Ignore Red Flags?
   • Justifying Stress With Money
   • "It's a Stepping Stone"
   • Need to "Prove Our Worth"
3. How Can You Overcome The Temptation?
   • Make a list of how your relationships would be impacted
   • Ask Brave Questions
   • Avoid Companies That Resist Transparency
   • Listen to Your Gut!
   • Write a Catastrophic Story

This article from 1995 is just as relevant today. Just convert the KBs to MBs and MBs to GBs.

Some of the author's identified causes of software bloat:

• user-friendliness (with graphical elements)
• measuring power of software by its number of features
• misinterpreting complexity as sophistication
• profitability of customer support contracts
• lack of interest in refining existing software
• time pressure to ship faster than one's competitors
• using C instead of languages with good abstractions (i.e. object-oriented ones)

Niklas Wirth was involved in the design and implementation of a new system called Oberon (using a programming language derived from Modula-2) in hardware, meant for worstations.

Three underlying tenets of the Oberon system

1. Concentrate on the essentials
2. Use a type-safe object-oriented programming language
3. Extensible using new data types

Oberon's core is only 200 Kilobytes, including the editor and compiler. It loads modules on demand and every module is in memory at most once.

This was achieved by carefully designing the modules and iteratively refactoring them.

9 lessons learnt building Oberon:

1. Use a strongly typed language
2. Module hierarchy design with the least duplication
3. Type extension
4. Identify primitives and avoid their proliferation
5. Designing a system that can be understood in its entirety by an individual
6. Keep the team size small to avoid communication problems
7. Try to keep complexity low at every step of the process
8. Programmers participating in all aspects of the development and dogfooding
9. Not publishing programs until they are of publication quality