I've recently started to think about covering some advanced topics like compilers, databases, interpreters. Do u know any good oss repos where I can learn and build them from scratch on my own
Build a Database in 3000 Lines with 0 Dependencies
41–50 of 59 posts
Re: Build a Database in 3000 Lines with 0 Dependencies
#42Earlier quoted context omitted.
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 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 wi…
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.
Re: Build a Database in 3000 Lines with 0 Dependencies
#43Man I got the first edition of this book and it was so bad. Hopefully this is better…
Can you elaborate on why it was so bad?
Re: Build a Database in 3000 Lines with 0 Dependencies
#44Earlier quoted context omitted.
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…
If I were to do that (for sqlite), I'd start with main() and re-type stuff needed to run CREATE TABLE/INSERT/SELECT...
Re: Build a Database in 3000 Lines with 0 Dependencies
#45A tiny database under 256 lines of C: https://gitlab.com/danbarry16/u-database
The idea in mind was to use it for something like an RSS feed reader.
Re: Build a Database in 3000 Lines with 0 Dependencies
#46Earlier quoted context omitted.
This makes me wonder. Is anyone practicing TDD with genAI/LLMs? If the true value is in the tests, might as well write those and have the AI slop be the codebase itself. TDD is often criticized for being slow. I'd seriously like to compare one vs the other today. I've also heard people find it challenging to get it to write good tests.
TDD suffers from being inflexible when you don't fully understand the problem. Which on software is basically always. Everytime I've tried it for something I make no progress at all compared to just banginf out the shape that works and then writing tests to interrogate my own design.
Happy that it's not just me. I tried it a couple of times, and for small problems, I could make it work, albeit with refactorings both to the code and tests.
But for more complicated topics, I never fully grasped all the details before writing code, so my tests missed aspects and I had to refactor both code and tests.
I kinda like the idea more than the reality of TDD.
Re: Build a Database in 3000 Lines with 0 Dependencies
#47Earlier quoted context omitted.
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 t…
Just to add to your point, both Mozart and Chopin were known to hand copy JS Bach's well tempered clavier preludes and fugues
Re: Build a Database in 3000 Lines with 0 Dependencies
#48Earlier quoted context omitted.
This makes me wonder. Is anyone practicing TDD with genAI/LLMs? If the true value is in the tests, might as well write those and have the AI slop be the codebase itself. TDD is often criticized for being slow. I'd seriously like to compare one vs the other today. I've also heard people find it challenging to get it to write good tests.
I'd sort of invert that and say it's better to use LLMs to just generate tons more test cases for the SQL DBs. Theoretically we could use LLMs to create 100s of Thousands (unlimited really) of test cases for any SQL system, where you could pretty much certify the entire SQL capability. Maybe such a standardized test suite already exists, but it was probably written by humans.
At that point, you'd get a ton more value from doing Property Testing (+ get up and running faster, with less costs).
If I'd had to have either code or tests generated by a LLM, I'd manually write the test cases with a well-thought out API for whatever I test, then have the LLM write tests that implements what I thought up, rather than the opposite which sounds like a slow and painful death.
Re: Build a Database in 3000 Lines with 0 Dependencies
#49Earlier quoted context omitted.
TDD suffers from being inflexible when you don't fully understand the problem. Which on software is basically always. Everytime I've tried it for something I make no progress at all compared to just banginf out the shape that works and then writing tests to interrogate my own design.
Happy that it's not just me. I tried it a couple of times, and for small problems, I could make it work, albeit with refactorings both to the code and tests. But for more complicated topics, I never fully grasped all the details before writing code, so my tests missed aspects and I had to refactor both code and tests. I kinda like the idea more than the reality of TDD.
I think in general people tend to overdo TDD if they do TDD, aiming for a 100% test coverage which just ends up doing what you and parent mentions, solidifies a design and makes it harder to change.
If instead every test is well intentioned and focus on testing the public API of whatever you test, not making assumptions about the internal design, you can get well tested code that is also easy to change (assuming the public interface is still OK).
Re: Build a Database in 3000 Lines with 0 Dependencies
#50Earlier quoted context omitted.
TDD suffers from being inflexible when you don't fully understand the problem. Which on software is basically always. Everytime I've tried it for something I make no progress at all compared to just banginf out the shape that works and then writing tests to interrogate my own design.
Happy that it's not just me. I tried it a couple of times, and for small problems, I could make it work, albeit with refactorings both to the code and tests. But for more complicated topics, I never fully grasped all the details before writing code, so my tests missed aspects and I had to refactor both code and tests. I kinda like the idea more than the reality of TDD.
TDD is supposed to teach you that refactoring of both the code and tests are "normal": iow, get used to constant, smallish refactors, because that's what you should be doing.
Now, the issue with badly defined problems is not that it's just badly defined, it's also that we like to focus on the technical implementation specifics. To do TDD from scratch requires a mindset shift to think about actual user value (what are you trying to achieve), and then go for the minimum from that perspective. It's basically an inverse from common architecture approach, which is design data models first, and start implementing next. With TDD, you evolve your data models along with the code and architecture.
And it is freaking hard to stop yourself from thinking too far ahead and letting tests drive your architecture (code structure and APIs). Which is why I also frequently prototype without TDD, and then massage those prototypes into fully testable code that could have been produced with TDD.