handmade.network » Forums » Documenting a project that is not "purely handmade"
9 posts
#12311 Documenting a project that is not "purely handmade"
1 year, 9 months ago Edited by sharazam on July 1, 2017, 5:40 p.m.

Hi. I have been following the handmade hero scene for a while.

My idea was to make a vector editor using Rust and OpenGL and document it in a Handmade-Hero style way with video streams. The goals are:

- Introduction to Rust from a C++ perspective
- PDF reading / parsing without libraries (aka how to write parsers), most time will be spent here
- Manual UI handling / UI construction from scratch, callback functions, etc.
- SIMD in Rust, multithreading, batched rendering
- 2D line drawing, 2D triangulation of polygons using 2-line loops & trapezoid method
- Gradient drawing functions
- Rest will be probably UI programming, state management and so on.
- Debugging Rust using GDB, benchmarking and writing unit tests

But here is the thing. I want use libraries. Mostly for stuff I do not care about for teaching - window construction, image loading, flate compression, json loading, etc. I can show how to set XWindow atoms. I may even have to (for popup windows, and so on). But I don't want to waste all my time on it when I can teach more interesting things.

What I have learned over time is that if you can program, you can figure out these things by yourself and you don't even need my tutorials. With decent documentation, a good programmer doesn't need my videos in order to figure out what he needs to do. OpenGL is heavily documented, as is de-/ encoding. I have no doubt that I could create encoding algorithms on stream. But the thing is that it's boring reinventing the wheel over and over again. Plus, since Rust is a compiled language and I have looked into the source of the libraries that I am using, I won't be doing a much better job than the libraries already can provide. So what's the point of making the xth tutorial on how lzw encoding works or how to write and read bytes from a file?

This is different with PDF. There are no tutorials aimed at PDF developers, I had to search three weeks in order to figure out how to encode fonts. There's also nobody telling you how to create UIs from scratch, everyone hacks together libraries, or how to write maintainable parsers.

The whole point of Rust is to make programming less of a pain and the integrated build system makes it easy to use libraries with 100% reproducible builds. Meaning, once something runs, it runs and can be put in a library and it won't suddenly go away or break like in other build systems. Which is why I like the language and its ecosystem - programming doesn't have to be a pain.

But I don't know if this would be acceptable in the handmade community. I can justify any performance costs and show what's actually going on, but I won't be making a JSON parser on stream if it has already been done.

If things are not well explained or not well documented (try reading the 1300 page PDF reference), sure, I get why you'd want to write it in a "handmade" way. But not for things that have hundreds of better tutorials and libraries elsewhere, I would be using libraries for those.

Not sure how this resonates with the handmade community, though. Thanks in advance for any feedback.
Anton Swifton
30 posts / 1 project

PhD Student in Math at the University of South Carolina.

#12332 Documenting a project that is not "purely handmade"
1 year, 9 months ago

Handmade is not as much about doing everything from scratch as it is about not being dogmatic, and that includes not being dogmatic about never using libraries. Of course, you can use libraries, if it seems to be reasonable.
Colin J. Mills
2 posts

Web developer by day. C programmer by night. Sorta like batman but with more segfaults.

#12353 Documenting a project that is not "purely handmade"
1 year, 9 months ago

Please do this. It sounds awesome! Handmade is more of a philosphy then anything else. I mean look at Abner's fractal streams, he uses a cJson and curl etc.

void* life;