I quite enjoy the spirit of the article, and I believe joy in programming has become even more important in the AI agent coding age we're leaving.
However, am I the only one finding those time estimates way too short?
I'm not the fastest programmer on Earth, but I'm not the slowest either, and I think most of those projects would take me a lot more time than those estimates, specially if I'd be working only 2-3 hours per day.
I feel most of those projects would take significant time researching and learning about the subjects, before even starting to code.
Example: recently I replaced my Pelican blog by my own hacky static site generator written in Odin, working 2-3h per day, it took me 2 weeks -- and this is a simpler project than many on that list.
Your project is vastly more specified than a toy project, because it has a real customer (you) who will expect it to work after it ships. That expectation is what separates toys from real tools.
I bet you could write a word processor in an hour. It might only add or delete one character at a time (no selections). It might persist only to a hard-coded "output.txt" filename. You might have to kill the process because there's no quit operation. But that would suffice for a toy word processor.
Fair point, my example was indeed "shipped to production" and may not compare a throwaway static generator toy project.
I still think those estimates are off, because I think many of those projects would need significant research and learning time, possibly more than actually coding -- not to mention time spent troubleshooting when something goes wrong.
For me, one of the enjoyable aspects of toy projects is that there is no schedule to meet. Which means that I can take my time. And yes, that means I take much more time than the article implies. As an examine, I've been polishing my PEG-based Turing complete language (which features both AOT-to-C and a fully featured repl) since COVID was a daily aspect of life.
When I use dynamically typed languages, it's not necessarily the lack of types that make me write code quicker, it's the fact that I can call anything from anywhere with a complete disregard for whether I should.
When I'm working in statically typed languages, esp. those with explicit error handling (Go, Rust, Haskell, Odin, Zig etc), I find myself spending a lot of time thinking about edge cases, bugs etc because I am forced to do so and find myself thinking in terms of engineering rather than exploring.
I mean, all of those depend on how much was imported as third party dependency, how much was not addressed at all, and what was actually solved manually.
They're all doable if you focus on the core problems. He's got a github with many of the examples up, it's instructive on how to keep things small.
And I think it's important that (based on the code) he had a solid understanding of the problem space before starting to write code. You don't write that tight when you explore a new space.
As far as I have explored the subject, the support for playing with the computer keyboard will probably be restricted to "simple plucking" (no support for "press and hold", and no velocity).
For keyboard expression, it will be simpler to just use MIDI input.
Not just yet, MIDI input is the next big feature I want to add! =)
("dang it!" protested a voice "i wanted this to be a surprise!! now, you've ruined it, announcing on HN...", "rhoo, it will be fine!" reassured another)
Lombok is kinda bigger commitment than attrs, because it interfaces with Java compiler internals (last time I used it, it was only possible to compile with sun/oracle jdk).
attrs seems lesser risk IMO, it's just a plain Python library, no other deps.
If you like Lombok, I'd expect you'll love attrs. :)
reply