>>> When I finished school in 2010 (yep, along time ago now), I wanted to go try and make it as a musician. I figured if punk bands could just learn on the job, I could too. But my mum insisted that I needed to do something, just in case.
Amusing coincidence. I also wanted to be a rock star, or at least a successful working musician. My mom also talked me out of it. Her argument was: If there's no way to learn it in school, then go to school anyway and learn something fun, like math. Then you can still be a rock star. Or a programmer, since I had already learned programming.
So I went to college as a math major, and eventually ended up with a physics degree.
I still play music, but not full time, and with the comfort of supporting myself with a day job.
Luckily you can still pursue being a musician without all the pressure having to be successful. On this road, one day you are free to declare your own success to yourself
I like this philosophy. It's interesting to me that the author writes about trying deno, specifically out of curiosity for compiling binaries with it, because that is something that's been specifically tickling the back of my mind for awhile now, but I've had no real reason to try it. I think this gave me the motivation to write some "stupid" code just to play with it.
Maybe you don't read much, but it's obvious they weren't making some universal statement about code. They are referring to the code you write when you are just experimenting by yourself, for yourself. The point is to not let irrelevant things like usefulness, quality, conventions, etc. limit just tinkering and learning.
I think the people who think there is no stupid code don't actually ever witness truly bad code. The worst code that they come across is, at worst, below average. And since that's the worst they see, it gets mentally defined as bad.
I've had the rare privilege of experiencing deliberately bad code. It was fucking awesome. Still have no idea what it did and it keeps me up at night 5 years later. It was so expertly terrible we still call each other up once in awhile to reminisce.
And reading the Linux kernel mailing list would allow him to... do what exactly? And by when? Compared to writing simple, working, usable apps in TypeScript, immediately after reading about how Deno/TypeScript/etc. work?
I feel like people should be writing stupid code, and in the case where its a compiled language, we should ask compiler or the language for better optimization. The other day, I was writing a check of a struct that have certain structures (protobuf probably have something like this)
struct S { int a; int b; int c; int d; int e; /* about 15 more members */ }
so I wrote
const auto match_a = s.a == 10;
const auto match_b = s.c == 20;
const auto match_c = s.e == 30;
/* about 15 more of these */
if (match_a && match_b && match_c) { return -1; }
Turns out compilers (I think because of the language) totally shit the bed at this. It generates a chain of 20 if-else instead of a mask using SIMD or whatever. I KNOW this is possible, so I asked an LLM, it was able to produce said code that uses SIMD.
I get more done by writing the stupid code, and fixing it, than junking the old code... but every now and then I can see clearly a structure for a rewrite, and then I rewrite, but its rare.
I'm working on in-kernel ext3/4fs journalling support for NetBSD. The code is hot garbage but I love it because of the learning journey it's taken me on: about working in a kernel, about filesystems, etc. I'm gonna clean it up massively once I've figured out how to make the support complete, and even then I expect to be raked over the coals by the NetBSD devs for my code quality. On top of that there's the fact that real ones use ZFS or btrfs these days, and ext4 is a toy; like FAT, by comparison, so this may not even be that useful. But it's fun and lets me say hey Ma, I'm a kernel hacker now!
Ext4 is most certainly still in use and not a toy. Its trusted. It takes a lot for folks to adopt a new file system.
I worked on a research topic in grad school and learned about holes in files, and how data isn’t removed until the last fd is closed. I use that systems knowledge in my job weekly.
A tip. Kernel development can be lonely, share what you are working on and find others.
>>> When I finished school in 2010 (yep, along time ago now), I wanted to go try and make it as a musician. I figured if punk bands could just learn on the job, I could too. But my mum insisted that I needed to do something, just in case.
Amusing coincidence. I also wanted to be a rock star, or at least a successful working musician. My mom also talked me out of it. Her argument was: If there's no way to learn it in school, then go to school anyway and learn something fun, like math. Then you can still be a rock star. Or a programmer, since I had already learned programming.
So I went to college as a math major, and eventually ended up with a physics degree.
I still play music, but not full time, and with the comfort of supporting myself with a day job.
Luckily you can still pursue being a musician without all the pressure having to be successful. On this road, one day you are free to declare your own success to yourself
I like this philosophy. It's interesting to me that the author writes about trying deno, specifically out of curiosity for compiling binaries with it, because that is something that's been specifically tickling the back of my mind for awhile now, but I've had no real reason to try it. I think this gave me the motivation to write some "stupid" code just to play with it.
I'm reminded of the quantity vs. quality groups in a photography class:
https://sebastianhetman.com/why-quantity-matters/
Do stuff, and you learn stuff. Go play.
This reminds me of the (excellent!) book by Jamie Buck: https://pragprog.com/titles/jbmaze/mazes-for-programmers/
They write a maze algo in any new language they learn just to learn bits of the language.
Where did you study games? Seems like we have similar trajectories.
I appreciate the sentiment, but "There is no stupid code" is the dumbest sentence I've ever read.
Maybe you don't read much, but it's obvious they weren't making some universal statement about code. They are referring to the code you write when you are just experimenting by yourself, for yourself. The point is to not let irrelevant things like usefulness, quality, conventions, etc. limit just tinkering and learning.
He will counter with "There are no stupid sentences"!
Yeah, I think he’s trying to equate it to something like “there are no stupid questions.” That’s a pretty silly analogy, but you get the idea.
Stupid code is fine. Make it work/exist first, you can make it good later.
I think the people who think there is no stupid code don't actually ever witness truly bad code. The worst code that they come across is, at worst, below average. And since that's the worst they see, it gets mentally defined as bad.
I've had the rare privilege of experiencing deliberately bad code. It was fucking awesome. Still have no idea what it did and it keeps me up at night 5 years later. It was so expertly terrible we still call each other up once in awhile to reminisce.
That’s a charitable interpretation. The other more pessimistic one is that they only see stupid code, which cannot be made any stupider.
> Fast forward to today. I’ve been doing a dive on JavaScript/TypeScript and different runtimes like NodeJS and Deno,
That's why. If all codes in a project are stupid, there's no stupid code indeed relatively.
Go read Linux kernel mailing list.
And reading the Linux kernel mailing list would allow him to... do what exactly? And by when? Compared to writing simple, working, usable apps in TypeScript, immediately after reading about how Deno/TypeScript/etc. work?
It would allow him to brutally roast anyone who submits a sub-optimal merge request.
Today its vibe stupid code.
The Kernighan law says debugging code is twice as hard as creating it.
Therefore, if you push yourself to the limit of your abilities to create the most clever code you can, you won't be able to debug it.
> The Kernighan law says debugging code is twice as hard as creating it.
> Therefore, if you push yourself to the limit of your abilities to create the most clever code you can, you won't be able to debug it.
If only advocates of LLM-based code generation understood this lemma.
I feel like people should be writing stupid code, and in the case where its a compiled language, we should ask compiler or the language for better optimization. The other day, I was writing a check of a struct that have certain structures (protobuf probably have something like this)
struct S { int a; int b; int c; int d; int e; /* about 15 more members */ }
so I wrote
const auto match_a = s.a == 10; const auto match_b = s.c == 20; const auto match_c = s.e == 30; /* about 15 more of these */ if (match_a && match_b && match_c) { return -1; }
Turns out compilers (I think because of the language) totally shit the bed at this. It generates a chain of 20 if-else instead of a mask using SIMD or whatever. I KNOW this is possible, so I asked an LLM, it was able to produce said code that uses SIMD.
I get more done by writing the stupid code, and fixing it, than junking the old code... but every now and then I can see clearly a structure for a rewrite, and then I rewrite, but its rare.
I'm working on in-kernel ext3/4fs journalling support for NetBSD. The code is hot garbage but I love it because of the learning journey it's taken me on: about working in a kernel, about filesystems, etc. I'm gonna clean it up massively once I've figured out how to make the support complete, and even then I expect to be raked over the coals by the NetBSD devs for my code quality. On top of that there's the fact that real ones use ZFS or btrfs these days, and ext4 is a toy; like FAT, by comparison, so this may not even be that useful. But it's fun and lets me say hey Ma, I'm a kernel hacker now!
Ext4 is most certainly still in use and not a toy. Its trusted. It takes a lot for folks to adopt a new file system.
I worked on a research topic in grad school and learned about holes in files, and how data isn’t removed until the last fd is closed. I use that systems knowledge in my job weekly.
A tip. Kernel development can be lonely, share what you are working on and find others.
This is a particularly bad mobile layout. Fix your margins.