I saw this shared in a different forum, and I have been interested in learning Zig, so I’ve been going through and porting it (slowly). I’ve found it to be a good learning exercise because of the small iterations, it’s easy to see the mapping between the two languages’ semantics, and it’s a chance to explore the Zig stdlib. Put it up on GH if anyone is interested: (and definitely not purporting it to be idiomatic Zig, feedback welcome)
Zig has a strong family resemblance with C that makes porting relatively straightforward. The things that make Zig fun are the more predictable semantics of the language itself and some of its modern features like slices, and stuff in the stdlib like ArrayList, which is super useful and you normally build yourself in C over and over (stretchy buf, etc.)
This is excellent! I personally find this style of incrementally showing changes to be among the best ways of teaching. I wonder how viable it is to apply such a technique to larger-scale projects, ones with many files and more complicated histories.
It seems as though each step is generated from a commit diff. It wouldn’t be that hard to handle multiple files in the same manner. However, are there situations in which a “change” is better understood by viewing the result of a series of commits, rather than one at a time? Does the order in which you present changes from a single commit matter? Is there extraneous information to be scrubbed, even if it occurs in the diff?
I’m thinking of, say, demonstrating a moderately sized refactor. If there are a lot of mechanical changes, perhaps you don’t want to pollute the reader’s mind with each and every one of them. The diff doesn’t seem to provide that much control.
This tutorial was my first stint into C and it is really great.
Starting small with 1 project and building that up helped me a lot.
Lots of Tutorials or books only show small parts of code that is encapsulated - you don’t get any “ambient” code, so really using 1 bigger project gives some kind of understanding how all the small parts can be put together.
I’m a couple chapters into this and I’ve already learned a ton about how terminals work and why escape codes are the way they are. Very very interesting.
I saw this shared in a different forum, and I have been interested in learning Zig, so I’ve been going through and porting it (slowly). I’ve found it to be a good learning exercise because of the small iterations, it’s easy to see the mapping between the two languages’ semantics, and it’s a chance to explore the Zig stdlib. Put it up on GH if anyone is interested: (and definitely not purporting it to be idiomatic Zig, feedback welcome)
https://github.com/paulsmith/texteditor-zig
Looks very interesting. How was your experience porting this from C to Zig? Would you prefer Zig over C?
Zig has a strong family resemblance with C that makes porting relatively straightforward. The things that make Zig fun are the more predictable semantics of the language itself and some of its modern features like slices, and stuff in the stdlib like ArrayList, which is super useful and you normally build yourself in C over and over (stretchy buf, etc.)
This is excellent! I personally find this style of incrementally showing changes to be among the best ways of teaching. I wonder how viable it is to apply such a technique to larger-scale projects, ones with many files and more complicated histories.
It seems as though each step is generated from a commit diff. It wouldn’t be that hard to handle multiple files in the same manner. However, are there situations in which a “change” is better understood by viewing the result of a series of commits, rather than one at a time? Does the order in which you present changes from a single commit matter? Is there extraneous information to be scrubbed, even if it occurs in the diff?
I’m thinking of, say, demonstrating a moderately sized refactor. If there are a lot of mechanical changes, perhaps you don’t want to pollute the reader’s mind with each and every one of them. The diff doesn’t seem to provide that much control.
Thank you for sharing!
I recently stumbled upon a Rust port/fork of this, in case anyone’s interested: https://www.philippflenker.com/hecto/ - I have it high on my list of things to play with Next Time When I Try Again To Learn Rust™, together with https://bevyengine.org/learn/book/getting-started/
This tutorial was my first stint into C and it is really great. Starting small with 1 project and building that up helped me a lot. Lots of Tutorials or books only show small parts of code that is encapsulated - you don’t get any “ambient” code, so really using 1 bigger project gives some kind of understanding how all the small parts can be put together.
I’m a couple chapters into this and I’ve already learned a ton about how terminals work and why escape codes are the way they are. Very very interesting.