I’ve always taken Yak shaving to mean “A chain of small tasks that you had to do in order to do the main one you set out to do.” Like when you set out to fix this bug, but then you realize a change to one part of the system requires changes in other parts too.
What is laid out in the article sounds more like procrastination.
I think of yak shaving as the intersection of that kind of chain of tasks and procrastination. The chain of tasks by itself is just…normal software development.
It’s usually a trade-off though. Of course that’s something you tend to optimize for, but it can go against other goals you have, like performance, simplicity, etc. Quality is really abstract and tends to need a context. And while overall of course it is a goal to keep things easy to to adapt there is always the situation where you actually want to rewrite stuff. Think about having a simple tool that to copy files, the cp command on unix systems. If your use case of copying files would be to move across the network you could go with scp or use nfs, but would it make sense to change the file copy to be able to connect to the network?
Another example of “without having to change stuff” going wrong is if you end up just effectively copying your functions all over the place, because you wanna be able to change them without needing to change parts that might depend on it. When that is sensible and leads to better quality code really much depends on the context.
So I would argue that the quality is defined by making the right decisions for the job and the actual use case among other circumstances. It’s usually also the thing where experience of the programmer comes in the most.
To be fair, I feel like way too little projects are made with a certain project in mind, resulting in catch-all languages, frameworks, libraries that just add every feature they can think of and people using them doing things that might not be the best idea simply because it’s possible.
Of course that’s not anti-flexibility, but usually bigger projects have to make certain design decisions and later bending the whole project to also fit that other use case or have that feature that looks nice on paper or simply is “in fashion” these days tends to result in a mess after the next thing is hyped, causing lot of deprecated, unmaintained code people still have to support for some very specific use case that people in one way or another depend on, maybe without evening knowing.
So kudos for sticking with actually implementing a project. Certainly speaking for the language. :)
I originally made this language with roguelike games in mind, so I optimized for that. Ironically, I realized over the years that roguelike games are so broad in their requirements and needs, that I ended up accidentally also optimizing for the best general purpose language!
Still, it’s always been my dream to make a roguelike game in my own language, so now I’m just using roguelike games as a litmus test and convenient testing suite. At least, that’s what I tell myself. I really just wanted to make a roguelike game, I think.
This might be one of the most productive yak-shaves since the time Knuth wrote a type-design program so he could create typefaces for a typesetting language he created to typeset his Art of Computer Programming books.
Oh, so you’re the author of Vale. I had no idea that you were making it to build a game (engine to build a game) - what an incredible yak-shave. Vale has some very neat ideas, and seems to improve on Rust in some ways (e.g. better ergonomics around lifetimes) - props to you!
I’ve always taken Yak shaving to mean “A chain of small tasks that you had to do in order to do the main one you set out to do.” Like when you set out to fix this bug, but then you realize a change to one part of the system requires changes in other parts too.
What is laid out in the article sounds more like procrastination.
I think of yak shaving as the intersection of that kind of chain of tasks and procrastination. The chain of tasks by itself is just…normal software development.
IMO the design quality of an engineering system is reflected in how easily changes to one part can be made without having to alter other parts.
It’s usually a trade-off though. Of course that’s something you tend to optimize for, but it can go against other goals you have, like performance, simplicity, etc. Quality is really abstract and tends to need a context. And while overall of course it is a goal to keep things easy to to adapt there is always the situation where you actually want to rewrite stuff. Think about having a simple tool that to copy files, the cp command on unix systems. If your use case of copying files would be to move across the network you could go with scp or use nfs, but would it make sense to change the file copy to be able to connect to the network?
Another example of “without having to change stuff” going wrong is if you end up just effectively copying your functions all over the place, because you wanna be able to change them without needing to change parts that might depend on it. When that is sensible and leads to better quality code really much depends on the context.
So I would argue that the quality is defined by making the right decisions for the job and the actual use case among other circumstances. It’s usually also the thing where experience of the programmer comes in the most.
To be fair, I feel like way too little projects are made with a certain project in mind, resulting in catch-all languages, frameworks, libraries that just add every feature they can think of and people using them doing things that might not be the best idea simply because it’s possible.
Of course that’s not anti-flexibility, but usually bigger projects have to make certain design decisions and later bending the whole project to also fit that other use case or have that feature that looks nice on paper or simply is “in fashion” these days tends to result in a mess after the next thing is hyped, causing lot of deprecated, unmaintained code people still have to support for some very specific use case that people in one way or another depend on, maybe without evening knowing.
So kudos for sticking with actually implementing a project. Certainly speaking for the language. :)
Thanks =)
I originally made this language with roguelike games in mind, so I optimized for that. Ironically, I realized over the years that roguelike games are so broad in their requirements and needs, that I ended up accidentally also optimizing for the best general purpose language!
Still, it’s always been my dream to make a roguelike game in my own language, so now I’m just using roguelike games as a litmus test and convenient testing suite. At least, that’s what I tell myself. I really just wanted to make a roguelike game, I think.
This might be one of the most productive yak-shaves since the time Knuth wrote a type-design program so he could create typefaces for a typesetting language he created to typeset his Art of Computer Programming books.
Oh, so you’re the author of Vale. I had no idea that you were making it to build a game (engine to build a game) - what an incredible yak-shave. Vale has some very neat ideas, and seems to improve on Rust in some ways (e.g. better ergonomics around lifetimes) - props to you!
Thank you for the kind words!