Comment by andai
1 year ago
I looked into this at one point, I was typing out entire codebases for didactic purposes: SQLite 3 was 120,000 lines of code, but SQLite 2 was 12,000.
So for a bit more effort you get a battle tested real world thing!
1 year ago
I looked into this at one point, I was typing out entire codebases for didactic purposes: SQLite 3 was 120,000 lines of code, but SQLite 2 was 12,000.
So for a bit more effort you get a battle tested real world thing!
The proprietary test suite for SQLite3 is much much larger still. The battle-testedness comes in great part from that.
Is that where the 10x more lines came from? Writing more "testable" code?
Oh no, SQLite3 is a lot more featureful than SQLite2. The proprietary test suite is what makes SQLite3 so solid.
14 replies →
Really puts the auto- in didact! Very curious to hear how this worked for you; it’s almost directly the opposite of the copilot approach.
I learned assembler by typing in listings from magazines and hand dis-assembling and debugging on paper. Your approach seems similar in spirit, but who has the times these days?
I learned this from Zed Shaw's Learn X The Hard Way books. He says this approach is mainstream in other disciplines, like music, languages, or martial arts.
I also heard the philosopher Ken Wilber spent a few years (in what kids today call Monk Mode) writing out great books by hand.
The main effect I noticed is that I rapidly gain muscle memory in a new programming language, library or codebase.
The other effect is that I'm forced to round-trip every token through my brain, which is very helpful as my eyes tend to glaze over — often I'll be looking right at an obvious bug without seeing it.
Just to add to your point, both Mozart and Chopin were known to hand copy JS Bach's well tempered clavier preludes and fugues
I program in neovim with no plugins, no autocomplete and no syntax highlighting. I type everything myself (though I will use copy and paste from time to time). There is a discipline to it that I find very beneficial. As a language designer, it also makes me think very carefully about the syntactic burden of languages that I design. It keeps my languages tight. One of the nice things about typing all of my own code without suggestions is that it eliminates many distractions. I may get some things wrong from time to time, but then I only have myself to blame. And I never waste time messing around with broken plugin configs or irritating syntax highlighting nits.
It's not for everyone but I love it.
I program most languages like this, in emacs.
Yeah these features are overrated. You can still autocomplete based on existing words in the same file by pressing Ctrl+N, but otherwise just typing it out or copying is totally OK.
I've also experienced autocomplete in NetBeans IDE so slow that it was just faster to type it out.
I quite value syntax highlighting though. Back then I used Turbo Pascal 5.5 on PC XT because it was way faster and less demanding than Turbo Pascal 6.0, but I remember not having a syntax highlighting was quite worse experience. You could get used to do without though.
But it also depends on the language. I've seen some Lua code without syntax highlighting and it was just a soup of words, very unreadable. Whereas something like C with symbols is OK.
Wait you took a repo and started typing it into the IDE? Could you please expand on what benefits you noticed and how it affected your understanding of the language? It sounds like a fascinating way to force attention to the code simply reading it wouldn't.
Yeah I just open two panes in Sublime Text, with the source on the right and then I type it out verbatim on the right.
I make an effort to keep the line numbers synced. Sometimes I skip long repetitive blocks or comments. But I do type out like 80% of the actual characters in the file.
It's about 500 lines per hour fot me, so I can estimate reasonably well how long it'll take.
It's not necessarily an efficient thing to do — you'd get way more bang for your buck just poking around, asking questions, trying to make small changes. But for reasonably small projects, you can type it out in a few hours, or a day or two. Then you've "round-tripped" every single token through your brain (though sadly not with a meaningful amount of conscious reflection) -- unless you pause and ask questions along the way.
See also my other comment above.
Not to offend you, and you've already pointed out the better way to do it, but I don't think there is too much to gain from this approach. When I was learning Vulkan for example, the only thing this helped me learn was which functions they were calling from the API. Their variable names and ifdefs and wrapper functions were completely useless to me. I was able to get their 5000 lines down to just 1000-- and that was for a single untextured cube with direct memory management and simple surface handling. Imagine if it had been more complex? 20,000 lines of typing for little reason. My neck aches thinking about it :)
Instead of a book club, have a code typing club, DuoTypo
It would be funny to type it until it builds, and then type it until the tests pass.
If I were to do that (for sqlite), I'd start with main() and re-type stuff needed to run CREATE TABLE/INSERT/SELECT...
>I was typing out entire codebases for didactic purposes
I've read about an author who did this (I can't remember their name right now), writing down the works of another author they wanted to learn from.
Hunter S. Thompson copied The great Gatsby on his typewriter: https://news.ycombinator.com/item?id=24696790
can you elaborate on typing out for didactic purposes, please?
It's a new iteration on the ancient form of learning by copying. I've only ever seen people copy stuff when writing by hand when wanting to memorize something though, I imagine with a keyboard the memory-enhancement effect of writing by hand is lost, but it's probably more effective than just reading alone.
one does not simply type out 120 000 lines of code..
Number of lines does not matter anymore.