index

Finds from the Web August 2023-08-31

Some things I've found during this month worth sharing.

Laws of Tech: Commoditize Your Complement by Gwern Branwen

A plausible idea to why for-profit organisations contribute to open source or release things free or subsidise. One reason can be to make the complement (a complementary product) to your product more accessible to the market, that in turn increases demand for your main product (operating system and computer hardware are complements, car and petrol are complements). Another reason can be that it helps create a "desert of profitability" around the for-profit business. For example, Google and Microsoft -- both with search engines that need traffic -- have made it hard for other actors to compete purely in the web-browser market by financing vasts amount of developer hours to create their own browsers and giving them away free with source code. This gives market protection for Google, since it becomes hard for a company solely focused on creating a browser -- that might not be aligned with Google's plans -- to compete with Chrome and to make a profit. An interesting article to read while seeing Meta release their Large-Language-Model llama-2 model as open source.

In general, the entire site gwern.net by Gwern Branwen is inspiring.

Emergence and Composition by Ryan Fleury

Nice article where Ryan shares some nice programming wisdom and insights. One well put point was being clear on the distinction between effects and computational concepts. Teachers in programming can lead people astray by not distinguishing these two. You often hear: "you want a playable Knight and an enemy goblin character that disappears in a cloud of smoke? Start by making a knight class, a cloud class, then the goblin class." But that conflates the effect with the computational concept needed to achieve that effect, leading students down the path to make convoluted software design. For example, there is no such thing as a knight from the machine's point of view. The computational concept is instead data to draw pixels to a screen.

Intelligence Signalling: why we do it, and why it matters by Hamish Todd

Reflections and comparisons on how communities and their cultures will have different ways of boasting about their intelligence. Hamish argues that there is both good and bad in this signaling behaviour, and we would do well to recognise that this is something we do and can motivate us, so that so that we can try to do it in a nicer way.

One example brought up -- that I have been guilty of -- is saying that "the natural world and the scientific exploration of it is plenty inspiring, there is no need for superstitious stories". Expressing this view is a way to put yourself above people inspired by other things in a bit of dominating way. Not so nice.

Another point is that this signalling can be a big motivator for people and a much of human progress can probably be attributed to this motivation. We should be honest with ourselves and accept that this can be a big driver for us so that we can be careful in how we express it, especially when teaching. When in the role of a teacher, we are showing off, and we should be aware of it so that we can be mindful to do it in an empathetic and pedagogical way and not in a dominating or alienating way. Martial-arts lifted as a good example of a community that elegantly handles this signalling, they keep their ranks, clothes and other signals within the community. Another example was purposely deflating the in-group language: When Feynman describes the scientific process to undergrads during one of his lectures he uses the phrase "a guess" instead of "hypothesis".

Strategies for Open Source Development in Academia by Wenzel Jakob

Researcher Wenzel Jakob and creator of open source projects presents his ideas on how to do software development in an academic setting. Big software projects take a lot of effort, better to focus on smaller parts instead of one big monolithic project: "make small things to perfection". As an example the rendering software mitsuba. It seems big monolithic project, but by splitting it into smaller parts using its plugin architecture, people can develop and contribute to camera models, light sources, materials, integrators independently.

The wet codebase by Dan Abramov

How DRY (Don't repeat yourself) and "test everything" and similar software engineering "best-practices" can get you in trouble and makes the codebase less flexible. These best-practices can often lead you to make an abstraction or generalisation prematurely. "Easy-to-replace systems tend to get replaced with hard-to-replace systems" When designing and maintaining a codebase, have the mindset of trying to keep things fluid. Abstract responsibly by:

Sommar i P1 - Max Tegmark

Swedish radio program where invited guests host a 90 minute program about a topic of their choice. Max Tegmark -- a prominent voice in public AI discourse -- talked about the risks of AGI and that recent rapid developments in AI. During this talk, Max brought up the question if we as a civilisation should value human exceptionalism to the degree we do. This struck a chord with me and inspired some existential thoughts...

Personally, the recent AI progress when extrapolating it to a hypothetical AGI scenario causes a sense of dread. One reason for this is that a big motivation for me in life is understanding, gaining knowledge and perhaps also contributing back knowledge. That purpose would disappear, if an AGI where to become super intelligent. Perhaps artist communities have had similar anxieties, with some digital artist tasks that required much skill have recently been replaced by AI tools (rotoscoping, keying, matte painting). Even though most would deem this as drudge work, there is a technical craftmanship and skill to it that has now lost its economic value. This fantastic talk by Jeff Fowler comes to mind that addresses this: Does Technology Destroy Art?.

It hit home for me that it's probably not healthy -- regardless if AGI happies or not -- to put so much of your own self-worth into "human exceptionalism" and our intelligence. Instead we should value our consciousness. Value that we can feel and experience things. Value community and sensations. Value that we can express ourselves in different creative ways and enjoy what other people express. A bit of an existential insight gained from this programme.

Creating a Tools Pipeline for Horizon: Zero Dawn

When designing the Decima Game engine, how to keep the game engine and the editor decoupled? Don't want any editor specific hooks or behaviour in the game engine, they want these decoupled. Yet their editor is interactive with the game engine. To achieve this the engine and its editor each keep their own copy of the node tree -- which contains all game objects and their hierarchy. They have the concept of an EditorNode that provides all editing functionality for an object in the game (in the editor). The actual game object does not know of EditorNode (lives in a separate part of the project from the game code). Another important part is the undo system. Before doing an action the code indicates which objects will be modified and when the modifications are complete. This records a set of commands, a transaction.

spotLight spotlight = GetSpotlightToEdit();

DiffUtil diff;
diff.TakeSnapshot(spotlight);

spotlight->setconeangle(1.0);

diff.CommitChanges("Set Cone Angle to 1.0"); // Produces a transaction for this change

To revert a change: reverse to order of the commands, and replace the command with its inverse. With the concept of transactions, how are these changes applied to the game? The editor NodeTree listens for transactions. The Editor NodeTree will determine what node is affected by this change, and will send this info together with the new parameters for the node to the game. Corresponding NodeTree in the game receives the change and applies it to the game object.

Other things

Music