The tutorials listed here can vary a lot in quality. For the text editor section for example, there is a very good tutorial in C which guides its reader through the development of a kilo-like text editor with buffer management and everything, and next to that a YouTube video claiming to teach how to build a text editor in Python but is actually a (poorly coded) simple GUI using the text editor component of the Tkinter library. Well, it can serve as a Tkinter tutorial, but not as a "build your own text editor" one.
I don't think this is necessarily a bad thing on its own - it's actually quite reasonable that one person's focus when "building a text editor" is going to be lower level along the lines of "how do I write a buffer and process key presses" while another person's focus might be "how do I embed a text editor in my app so I can add my own UI around it".
But it probably does warrant some kind of rating or explanation for each tutorial, especially for the less experienced developer.
I wonder if it'd be possible to update the listings with filters or ratings. Difficulty, hardcore-ness, ETA to MVP, whatever. Even some simple notes or emojis would help.
I was thinking of posting something along these lines, nice to see someone else also aware of this niche!
Software point of view, you'd like to use QMK or ZMK, and KiCad to design the hardware (PCBs). Reddit's r/olkb and r/ergomechkeyboards are great places to start!
Bonus: QMK supports trackpads and nipple-pointers too! (Not sure about mice though)
"Never roll your own cryptography", despite the ambiguity of its phrasing, means never use uncertified crypto in production unless you're willing to take the risk. It doesn't mean to never build cryptography without an expert's permission. Everyone who has ever published world-class cryptography has rolled their own crypto.
My apologies then. I've seen this phrase repeated ad nauseam even when its not warranted and I want to point out that it shouldn't be followed blindly.
People absolutely should. The best way to understand how something works is to build it.
What that phrase means is you shouldn't use hobby crypto libraries for any important production services. But that's also not the point behind "Build Your Own" type projects. So your advice isn't correct in this scenario.
if you need expert opinion on your library order a security audit. otherwise even expert-designed systems have failed and most people know that it is very unwise to give security guarantees to devices that have so many moving parts
Interesting, this page has been around for a while and did not used to belong to codecrafters.io. I guess they bought the original repo so it would redirect here? Or maybe the original author started codecrafters.io? Indication of change here: https://github.com/codecrafters-io/build-your-own-x/commit/6... when the (non)copyright changed a week ago.
One advice: for any of these topics take a tutorial directed at language X and implement the solution in language Y. This will prevent you from mindlessly copying the code and will force you to understand what you are doing.
* a clone of React.js and Vue.js in <1K bytes minified
* a web-based code editor and office suite
* a chess engine
* a TCL interpreter
* a two-step verification client
* a simplified C compiler
Surprised to see 2 of my blog posts on there. Both about building search engines. Oddly missing the posts that I would consider a lot better about the subject. Rather flattering though.
I remember The Great Code Club (https://www.greatcodeclub.com), started by Marc-André Cournoyer. It was a wonderful idea and it provided me hours of fun and learning. If you are into this sort of thing, you will love it.
A Merkle-tree data structure + an append only log with checkpoints + a command processor would provide a basic foundation.
Your data can be represented in a Merkle-tree. You provide operations add-node, delete-node, move-node etc., on the Merkle-tree and build a command processor that takes as input a checkpointed Merkle-tree snapshot (could be empty when you start) and a log of operations (essentially an sequence of operations). The command processor then applies the series of tree operations in the log to build the final state of the tree. The special checkpoint operation saves a snapshot of the Merkle-tree.
This basic set of operations should allow you to do unlimited undo/redo/transaction playback capabilities.
Simple. For every operation performed by the user, you push a function to the end of a list that undoes that operation. When the user presses undo, you pop the function from the end of the list and call it.
Emacs’s undo system is quite frankly amazing. Not only can you recover any state through an arbitrary number of undo and redo operations, but you can also localize the undo/redo operations to a selected region of the buffer.
It’s the number one feature I miss when I’m using another editor.
Am I missing something or would it just need to be a doubly linked list? It really depends on your program state being… stateful (so you can navigate forwards and back consistently)
If you store the total application state for each step then it's simple, but consumes lots of memory.
If you want to store something more like a diff, there are choices. For example, you could have code to undo each operation, but you can also implement undo by going back to some checkpoint and then recomputing all operations between the checkpoint and now. Latter consumes more CPU, but comparable memory and a lot less code surface for bugs.
If you use persistent data structures, you can store the total state, and you'll get deduplication of the common parts, which brings down the memory usage to a more reasonable amount. This is what git does essentially, which gets you O(1) checkout to arbitrary steps in the future/past. This also means you don't need to design/pick a diffing algorithm, which you would be locked into (since changing the diffing algorithm would mean you couldn't consume old diffs).
Git does store deltas when packing objects because storing all distinct objects as-is would be too inefficient for large repos. This isn't the same text diffs as shown to the user but there is still a diffing algorithm that all future git versions need to support (well, at least the patch counterpart).
I’ve had this list bookmarked for years and love referring back to it for ideas. It’s also one of the first things I send to new(er) programmers so they can make cool tangible stuff & avoid tutorial burnout.
It’s hilarious that you would say this, because this repo is a lead generator for a YC backed company - CodeCrafters. They’re hoping you click through and sign up for their $800/year service which teaches you how to build these things.
This is advertising, pure and simple. That’s not a bad thing, but it’s funny that you praised it as being the exact opposite.
Which propaganda? Would you mind referring to a recent example?
This submission is indeed really great, but I don't see HN as being such a bad platform as you're suggesting it is. There's really a lot of value being shared here.
