The handmade hero community is wonderful. It is a portal to a lot of knowledge transfer. If you're looking to approach C/C++ in a welcoming environment and/or love getting closer to the metal, I highly recommend the community.<p>I also recommend the handmade video series.<p>Casey Muratori has been live streaming himself build the same game for the past few years. He try's to build everything from scratch, which is entertaining and quite the brain dump.<p>Also, the video archive and live chat is searchable. I can't count the number of times I<p>- searched for some keyword or phrase, like "CPU"<p>- was greeted by a link that read something like this<p><i>"Day 025: Finishing the Win32 Prototyping Layer (01:38:59) Isn't the CPU Memory bandwidth only valid for on-die memory?"</i><p>- clicked the link to receive 3-10 minutes of extremely dense but well-explained information on a topic.<p>- spent the next hour or so googling technical terms and subjects that filled massive holes in my knowledge.<p>If you love learning, treat yourself to jumping around the video archive :)<p><a href="https://guide.handmadehero.org/" rel="nofollow">https://guide.handmadehero.org/</a><p>Two favorites of mine from the archive
Undefined Behavior: <a href="https://guide.handmadehero.org/chat/chat011/" rel="nofollow">https://guide.handmadehero.org/chat/chat011/</a><p>Modern x64 Architectures and the Cache: (<a href="https://guide.handmadehero.org/chat/chat017/" rel="nofollow">https://guide.handmadehero.org/chat/chat017/</a>)<p>P.S. Its worth mentioning that you can buy the game hes building and get access to the source code. I'm not associated with handmadehero.org or Casey Muratori in anyway. The community just led to me becoming a better programmer over the past 5 years. I hope someone reading this finds the value I did in rabbit-holing for hours and laughing at the rants of a seasoned game dev.<p>*edit: formatting
Hey! I organized this community a few years ago; it's under great leadership. Trivia points:<p>1. The manifesto author was barely 18 when he wrote this; representative of a new, younger cohort interested in this stuff.<p>2. Handmade is into low-level understanding, but certainly a few people stick to high-level projects, and simply peek behind the curtain when they <i>need</i> to. Low-level thinking translating into high-level wins.<p>3. Someone mentioned my conference, Handmade Seattle [0]. This is part of an effort to expand into the mainstream, and to inspire the next generation of compiler writers, kernel developers, game engine programmers etc.<p>We're not saying <i>everyone</i> has to be into this. We want to carve out our place, let those who care flourish, and not be caricatured for "reinventing the wheel."<p>[0] <a href="https://www.handmade-seattle.com" rel="nofollow">https://www.handmade-seattle.com</a>
Why is that we praise hand-crafted objects in the real world while at the same time deriding such hand-crafted code as a quaint curiosity that can only make sense as a hobby of the hopelessly romantic?<p>Do we compare your local carpenter with IKEA, or that delicious, nutritive and healthly meal you cooked with McDonald's, in terms of pure (developer) performance?<p>Do we obsess over how a handmade jewelrer can't scale operations to five continents?<p>Why do we copycat every process or idea from tech behemoths but laugh when someone tells us that maybe a chat client shouldn't gobble up gigs of RAM?<p>In the real world, both craft workshops and assembly lines have their place. Maybe that should be true for the digital world as well.
What people don't realize is that modern, high-level languages and abstractions give you much more than just speed of development.<p>If you use a garbage collector, you don't have to do manual memory management, which is amazing for security. You also don't need to worry about buffer overflows and weird pointer exploits.<p>If you use web tech, you get a lot of important stuff, like sandboxing, handling of esoteric keyboards, RTL languages and screen reader accessibility almost for free. If you use some extremely fast, small and lightweight GUI framework, you will probably not implement those, as they seem boring, and who needs that anyways.<p>If you go the handcrafted, lightweight and fast route, you're sacrificing a lot of features, possibly without even being aware of what you lose until it's too late.<p>I will happily shelve a few more bucks for RAM and wait a few more seconds to get an accessible, secure Messenger, instead of one that is going to steal my bank details the moment some stranger sends me a malicious GIF.
I've been writing C code for more than 30 years, C++ for 27. I've written code at every level of "the stack", from kernels of several nix-related operating systems to application GUIs. I've worked on "plumbing", on libraries, and on applications.<p>And here's the thing: I understand, at a very very deep level, precisely why my application is slow to start up. I understand it at every level from the semiconductor gates in silicon up to the color specification lists used by the GUI toolkit. But none of that helps me make it as fast as the handmade community thinks things should be.<p>Why? Because I know that the slow startup is caused by substantial amounts of code that all add useful functionality for at least some of my users. Do I want to get rid of i18n? Shall I skip checking for new versions? How about forcing plugin scans to be initiated by users and never doing them automatically (don't even <i>think of</i> suggesting doing them in another thread, and don't ask me why)? Shall I skip the ability to handle RTL text? Should we drop human readable and editable configuration files in favor of some faster and less resource-eating format? How about a scalable GUI, is that really useful for most? How about a themeable GUI, given that it's not actually that themeable anyway?<p>And so on and so forth. Each one of the above (and lots more) contributes just a little bit to the slow startup. For most users, all but one of them will likely seem not very important. So which ones do we drop to get back to the sort of startup times that the handmade community seems to expect?<p>Because let's face it, xterm can put a window on the screen before my finger is off the return key. So why not a DAW (or an IDE or an editor or a vector graphics app or an image editor or a browser or a circuit emulator or whatever your thing is) ? Just which features do you want to cut to accomplish this?
While "handmade" code may be faster, it's also a big time sink and as a developer your job is to make tradeoffs.<p>For most software, you should probably focus on architecture instead of the lower level of your code. Sane code and architecture solves most performance issues. This includes technology decisions, like using web tech for applications instead of the native platform.<p>For example, Apple has had a lead of at least five years over Android when it comes to performance and user experience, because their system and apps were all built in native environments, instead of the JVM abstraction layer. It took at least five years for Android to catch up, and it took quadcore CPU's to do it. Around then, Apple carefully started using dual-core CPUs.<p>Meanwhile, companies like Facebook and Twitter spent dozens of work-years on trying to make web technology feasible in native apps and never really cracked it.<p>If they had just focused on building good native apps they wouldn't have wasted so much time.<p>Caveat / Aside: IIRC Facebook is having / has had massive issues with having too much code / classes / files in their app(s), on both iOS and Android. Which is (I believe) one of the reasons why they split off Messenger into its own app at the time.
It reminds me of <a href="https://suckless.org/" rel="nofollow">https://suckless.org/</a><p>Also the set of projects is somewhat similar:<p>window manager (dwm) -> game engine library (raylib)<p>terminal emulator (st) -> IDE template (4coder)<p>web browser (surf) -> video browser (motionbox)<p>+ tools and libs...
“Why does it take your operating system 10 seconds, 30 seconds, a minute to boot up? Why does your word processor freeze when you save a document on the cloud? Why does your web browser take 3, 4, 10 seconds to load a web page?”<p>Bloat !!!
The Handmade metaphor masks a key difference between software and physical goods. IIUC, mass-produced physical goods are inferior to their handmade counterparts because of the trade-offs that enable profitable mass production. So we have a strong emotional attachment to handmade things being better, and the Handmade movement plays on that emotional attachment.<p>But the metaphor breaks down if you think about it. A carpenter making a single piece of furniture can tailor it to the person who will be sitting on it. A cook making a meal for one person can tailor it to their dietary requirements or tastes. But software of any non-trivial scale is rarely written for one person. Even when it's developed according to the ideals of the Handmade movement, it will be mass-distributed.<p>I actually think that, contrary to our intuition about handmade things, Handmade software tends to have compromises compared to software that builds on well-established components. I won't repeat miki123211's top-level comment [1]. I'll just add here that it's precisely the economics of large-scale software distribution that allow concerns such as internationalization and accessibility to be addressed, while a solo Handmade project will probably not have these important things.<p>So, while slinging JavaScript code with no regard for performance and packaging it with Electron is certainly not the ideal, I strongly believe that the Handmade approach isn't either. As is so often the case, we need a middle ground.<p>[1]: <a href="https://news.ycombinator.com/item?id=24186711" rel="nofollow">https://news.ycombinator.com/item?id=24186711</a>
Damn, this place looks amazing, it looks like El Dorado in a sea of despair, for someone being used to make the same points than this manifesto and being looked as a weirdo in response.<p>Sadly they block Tor users, because they use Cloudflare. Maybe we're not that much on the same page after all.
TL,Dr : knowledgeable, skilled programmers writing semi-confidential software in C for mostly a single OS, by themselves, with total control of the feature set and release schedule, can produce pretty fast binaries.<p>Which is great ! I just don't know how to transfer that to building software as a team with multiple skillsets, unknown feature set (because market feet is still searched for) aggressive schedule, (We don't know what we want to build , but we need it in six months), large target audience ("what do you mean they have to install stuff ? Where is the link I can paste in an email so they open it in IE6 ?") , and,let's be honest, less knowledgable and more lazy developers.<p>(To be clear : I'm <i>not</i> criticizing the network or project. I just find it interesting that they had a goal - making fast software - and that, to the ebest of my knowledge and without a rigorous analysis - it seems that most projects converged on a very particular kind of software. Which just happens not to be the kind most of us will ever be working on, but it does not matter. Go them !)
So the bottom of the linked article says 2016, which made me immediately think 'old!'<p>It makes complete sense for the manifesto to be timestamped, but the surprise was that I didn't realise I was reading the manifesto rather than this actually being the normal landing page... there's no title or anything and HN usually links to homepages.<p>But a quick glance at the forum and the homepage shows there's activity there still!<p>Clicking around, this seems really interesting :)