Wheel Reinvention Jam

August 15 - 21. Change the status quo.

We are a community of programmers producing quality software through deeper understanding.

Originally inspired by Casey Muratori's Handmade Hero, we have grown into a thriving community focused on building truly high-quality software. We're not low-level in the typical sense. Instead we realize that to write great software, you need to understand things on a deeper level.

Modern software is a mess. The status quo needs to change. But we're optimistic that we can change it.

Latest News

Ryan Fleury

Handmade Network is different from other software development communities. We promote philosophies and projects that care deeply about software craftsmanship. We criticize common dogma within the software industry that has produced a computing world that is far too sluggish, too bloated, too poorly-designed, and too unwilling to change. We stand for a better computing world.

In the past 4 years, we've done some big things with Handmade Network. The community has grown dramatically, with thousands of (active!) users on the Discord server (where a bulk of Handmade communication happens). We started a podcast. We've had multiple Handmade-themed jams. We transformed the Handmade Network website into a larger repository of Handmade projects and showcase content, to serve as a bastion of Handmade ideas, and concretely demonstrate how Handmade can improve us as builders of software.

Back in 2018, Handmade Network began a new chapter. I took over for Abner Coimbre as the lead of Handmade Network. I was joined by Ben Visness and Asaf Gartner, and together we replaced the original Handmade Network admin team. At that time, Handmade Network had established itself as a large and self sustaining community. It was the new team's job to continue to foster the community, and to take it to new places. The original team was ready to move on to bigger and better things, and they entrusted the keys to the community with myself, Ben, and Asaf.

Today, Handmade Network begins another new chapter. I have decided to step down from my role as Handmade Network lead, with Ben Visness taking my place. Ben has been a great staff member since the beginning. He led an initiative to rewrite and dramatically change the Handmade Network website into what it is today (writing blogs is a lot easier now). He and Asaf are responsible for all of the technology that allows the Handmade Network website to collect amazing showcase material from the Discord server, allowing the website to serve as both personal and project content repositories (in addition to the functionality that the website offered before). Handmade Network would simply not be what it is without Ben, and I know that moving forward, he'll do an outstanding job of leading the community.

I love being a part of Handmade Network, and I will remain a member. It has been an incredible resource to have as I've grown up. I joined Handmade Network in high school as a young and naive programmer, and the community was instrumental in transforming me into a much more capable and responsible engineer. I've decided to step down because I believe that it will be best for both myself and the community. I have found myself preoccupied with work, life, and some of my other personal projects and initiatives. For this reason, I think it will be most productive - not only for me personally, but for the computing world - for me to give undivided attention to those things, and hand the reins over to Ben to ensure that Handmade Network can be given the time and attention it deserves. Ben will be a strong force in continuing to grow, foster, and shape the community, and increasing its impact as a force for change in software.

It has been a thrill being a staff member, and I can't wait to see what the community will do next. Let's all keep going. Let's continue to build new projects, publish new educational material, do new research, and rethink old assumptions. Through all of those efforts, we can change the computing world into something a little better than what it was before.

-Ryan

Around the Network

New forum thread: Key press isn't registered
smoke
Shastic
x13pixels

I have been migrating all of my code from GitHub to my self-hosted Gitea instance.

My Gitea instance has been mirroring my GitHub code when it changes. In the next week or so, I will be deleting my code outright from GitHub.

Here's article that pushed me to finally do it: Give Up GitHub: The Time Has Come!

I am doing this for several reasons:

• I don't want my code plagiarized by Copilot. (Although, writing code in Cakelisp makes that a non-issue!)
• The master fiasco. Any way you swing on any issues, I don't want politics showing up on my code hosting site.
• I don't like how the youtube-dl takedown was handled. While nothing I write does anything "illegal", I don't want a corporation having that kind of power over my work.
• I want to avoid centralization on services I don't control. It's the reason why I set up macoy.me, and have been migrating to it.
• Microsoft. Enough said.

Even though I am moving my code to my website, I am still interested in collaboration. If you want to work with me or contribute in any way, please email me at macoy at macoy dot me.

If you are also interested in moving your code off GitHub, check out Gitea. Overall, I am quite pleased with my experience with it.

In other news

I did an informal game jam with a coworker of mine a few weeks ago. I'll be posting screenshots and/or video of the resulting game soon. Cakelisp was used as the build system. The rest of the game was written in C so that my coworker was familiar with the main language.

It turned out to be a good project because it tested Cakelisp and C interoperability. There were a couple things I needed to tweak, but overall it went smoothly. The Mac platform caused some troubles. I wasn't surprised because I don't have a Mac for testing, so it's understandable that it isn't a seamless experience.

I have been focusing on distributed-automation, my continuous integration solution written in Cakelisp. I ported over the self-update code I wrote for Machsearch which allows the workers to be told to download and run the latest version. This allows me to start to have workers running on various machines without having to be "done" with the system. Once I make a new feature, I can simply tell the master to instruct the workers to update themselves. I couldn't use a package manager for this because I have workers running natively on Windows, and I don't really care much for package managers anyways.

Not invented here

At this point, the Cakelisp project involves a significant amount of things people would call you crazy for building:

• A language
• A continuous integration system
• The code repository not being on GitHub

I'm sure there will be more to come. I'm learning a lot. I do still use a fair amount of third-party software.

I think that being willing to tackle these things is a good attribute. If everyone always buys instead of builds, the whole industry falls into complacency and mediocrity.

Guntha
Christoffer Lernö

As previously discussed, it might be possible to do implicit imports so using Foo would implicitly do it. In C3 due to the overall rules, this leads to few ambiguities (go back to the blog post to review how it works)

After using this for quite a while, I ended up concluding that full implicit imports are bad. You want enough high level importing to feel that there is some documentation of what is included to hint at the possible origin of types.

An example is when read some code that relies on an external graphics library and you encounter a type like Point or Vector2. Because at that point you can't be sure whether this is a type from the external library or from some obscure part of the standard library. Same with something like Socket or Connection: is that Socket from a standard lib networking library, or is it from some external imported library? If the standard library is big enough then you can't know for sure – and finding out is not easy.

So you want at least a high level import, but possibly not import std::net::socket granularity, but rather something like import std::net or import raylib at the top of the file – enough to make it easy to find the types and functions.

So the new updated scheme has wildcard inclusion by default (so import std::net would include all the sub modules).

In addition, I've also made modules implicitly import any other module with the same top domain. So code in std::net::socket would see the code in std::net::http without the need for an explicit import.

This means that if you start a project with some top module, for example mygame, then in the module mygame::gameloop you'll automatically import mygame::maths and mygame::data.

There are some issues with the latter. In particular, all of the standard library modules would see all other standard library modules! It's quite possible to address that, but first I want to make sure it's a problem in practice. Even completely implicit imports "almost worked", so maybe this isn't much of a problem.

Luolamies
Mārtiņš Možeiko
Simon Anciaux
clivi
Simon Anciaux
Mārtiņš Možeiko
clivi
Simon Anciaux
New forum thread: Win32 Wait For Window Focus
clivi
XP1
XP1
BlitzCoder
Simon Anciaux

I have several projects written in Cakelisp that I have been chipping away at.

File Helper

I haven't made much progress on File Helper, but I do find myself reaching for it and hope to revisit it.

I want to create a command-line interface for creating an index of files on systems I have which aren't graphical. I can then tag and visualize the file system on my work station.

Machsearch

My newest application does indexing full-text search. It's much faster than ag, grep, or any other non-indexing full-text search.

It's so fast that you can search as you type, and it scales very well to large codebases thanks to its index.

I implemented a self-update feature for Machsearch which I think will come in handy on many of my previous and future applications.

There isn't much competition in the indexed file search space, but there are three main products out there:

• Google Zoekt: Google originally made Codesearch, which is what powers Machsearch. Now, they seem to have moved to this new platform which is a client-server model rather than a CLI application.
• Sourcegraph is a company whose chief product is a code navigation suite. It is at least in part built on Zoekt, judging by their open-source fork of it.
• Microsoft Visual Studio 2022 is adding an indexed file search.

I think there is still room for Machsearch in this environment, for three reasons:

• Machsearch is a single executable. There's no server or heavyweight IDE needed. There are fewer things which can go wrong with this.
• No project file is necessary: the only required step is selecting which directories you want to index.
• Machsearch's Custom Commands feature makes it trivial to follow up with additional processing using other command-line tools. The other offerings are either not running on your machine or editor-centric.

Distributed automation

My most recent project has been a continuous integration system, distributed-automation. I am building it to fit my needs exactly, and do not expect it to be of interest to others.

Workers on various different machines communicate with a master server and do work.

I decided to build this rather than "buy" existing CI products like Jenkins or BuildBot for two reasons:

• These systems have relatively complex configurations. I tried to set up BuildBot, but their getting started tutorial almost immediately failed with no error and no logs to help me debug it. If the "happy path" doesn't even work, I don't feel confident exploring further.
• I haven't done any programming with networking or sockets, so this automation system gives me valuable experience with this kind of API.

I will take more time setting this up, but in the end I will have a perfect fit for my needs (and no more!) as well as gained knowledge with network programming.

I plan on using this system to automate all of my builds, especially multi-platform builds and releases. This will make it easier for me to create binary releases of all of my projects. It will also make it easier for me to detect platform compatibility and regressions for Cakelisp and GameLib.

While somewhat unusual for a CI, I am planning on using it for automating my backups as well.

There is a significant amount of incidental complexity and cruft involved with linking. It can be pretty uninteresting and frustrating to deal with.

Cakelisp

Cakelisp has been very stable. I had to make a few changes to fix relative paths recently, but that's about it. I'm very happy with how little I need to work on the language.

I have been considering building a basic IDE for Cakelisp, similar to what Beef did. I would do this primarily to ease the transition from "I'm on the home page of Cakelisp and want to try it" to "I wrote/modified and executed Cakelisp successfully".

Thanks to work on File Helper and Machsearch, as well as some prototypes I have made, this IDE would not take much more than a few weeks to put together, and would substantially lower the barrier to entry.

GameLib

GameLib is my collection of modules for various 3rd-party dependencies as well as useful pure-Cakelisp utilities. Here is a list of some relatively new additions:

• Network.cake for basic socket-based networking on GNU/Linux and Windows
• AutoUpdateApplication.cake for handling application self-updating
• VersionedData.cake for data serialization versioning. This is very minimal for now, but enough to handle my existing application user configuration demands.
• XML.cake, which cleanly generates XML.
• Various 3rd-party libraries: Raylib, curl, miniz, Oniguruma, and FreeType. These integrations allow for easy importing of these libraries without requiring a wrapper that would quickly go out of date.

Summing up

As you can see, I have many different projects I'm working on, all happily written in Cakelisp. The projects drive the language's development, and the language's ecosystem continues to grow. It's still just me using Cakelisp for now, but I'm okay with that.

Blog comment: Torch Passing, Part 2
Jason
Blog comment: Torch Passing, Part 2
Simon Anciaux
Blog comment: Torch Passing, Part 2
Abner Coimbre
New blog post: Torch Passing, Part 2
Ryan Fleury

Handmade Network is different from other software development communities. We promote philosophies and projects that care deeply about software craftsmanship. We criticize common dogma within the software industry that has produced a computing world that is far too sluggish, too bloated, too poorly-designed, and too unwilling to change. We stand for a better computing world.

In the past 4 years, we've done some big things with Handmade Network. The community has grown dramatically, with thousands of (active!) users on the Discord server (where a bulk of Handmade communication happens). We started a podcast. We've had multiple Handmade-themed jams. We transformed the Handmade Network website into a larger repository of Handmade projects and showcase content, to serve as a bastion of Handmade ideas, and concretely demonstrate how Handmade can improve us as builders of software.

Back in 2018, Handmade Network began a new chapter. I took over for Abner Coimbre as the lead of Handmade Network. I was joined by Ben Visness and Asaf Gartner, and together we replaced the original Handmade Network admin team. At that time, Handmade Network had established itself as a large and self sustaining community. It was the new team's job to continue to foster the community, and to take it to new places. The original team was ready to move on to bigger and better things, and they entrusted the keys to the community with myself, Ben, and Asaf.

Today, Handmade Network begins another new chapter. I have decided to step down from my role as Handmade Network lead, with Ben Visness taking my place. Ben has been a great staff member since the beginning. He led an initiative to rewrite and dramatically change the Handmade Network website into what it is today (writing blogs is a lot easier now). He and Asaf are responsible for all of the technology that allows the Handmade Network website to collect amazing showcase material from the Discord server, allowing the website to serve as both personal and project content repositories (in addition to the functionality that the website offered before). Handmade Network would simply not be what it is without Ben, and I know that moving forward, he'll do an outstanding job of leading the community.

I love being a part of Handmade Network, and I will remain a member. It has been an incredible resource to have as I've grown up. I joined Handmade Network in high school as a young and naive programmer, and the community was instrumental in transforming me into a much more capable and responsible engineer. I've decided to step down because I believe that it will be best for both myself and the community. I have found myself preoccupied with work, life, and some of my other personal projects and initiatives. For this reason, I think it will be most productive - not only for me personally, but for the computing world - for me to give undivided attention to those things, and hand the reins over to Ben to ensure that Handmade Network can be given the time and attention it deserves. Ben will be a strong force in continuing to grow, foster, and shape the community, and increasing its impact as a force for change in software.

It has been a thrill being a staff member, and I can't wait to see what the community will do next. Let's all keep going. Let's continue to build new projects, publish new educational material, do new research, and rethink old assumptions. Through all of those efforts, we can change the computing world into something a little better than what it was before.

-Ryan

Dawoodoz
Dawoodoz
Unknown description

Community Showcase

This is a selection of recent work done by community members. Want to participate? Join us on Discord.