4 ms·

> Don't like one of Hancho's defaults? It's only 500 lines - hack it up however you like. It's fascinating to think of this as a deliberate approach or paradig

> Don't like one of Hancho's defaults? It's only 500 lines - hack it up however you like. It's fascinating to think of this as a deliberate approach or paradigm rather than a shortcoming. The antithesis to the inner-platform effect [1]. Instead of digging an ever deeper rabbit hole of options and configuration, encourage customization via forking. You can't beat the flexibility. And lots of projects have well over 500 lines of build system configuration anyway. With that kind of competition, forking a 500-line build system may well yield the more comprehensible end result. Not to mention that when facing a problem outside of a given build system's anticipated set, I'd much rather have Python to solve that with than a special build system language. [1]: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect

teaearlgraycold 3y ago
I’m a big fan of copy-pasting code. When you are just learning to program you learn all of the common abstractions, for loops, functions, modules, etc. to reduce code duplication. This leads too many devs to think duplication is a bad thing to be avoided at all costs. I’ve seen a ton of terrible libraries out there that aim to end code duplication. Please, I can handle needing to copy/paste a couple of lines of code around my code base. But I can’t handle your bad abstractions.
- nine_k 3y ago
  Copy-pasting is fun when you add code, and a pain when you subsequently have to alter it. So it's easy to sell to a beginner or a hobbyist, and it also works well in projects which do not live long, like most games and many websites.
  - smilliken 3y ago
    It can go either way. If you duplicate code, but the two copies need to stay in sync, then you've made it a bit harder and more error-prone to maintain. But the worse offense is if you have some code that serves two conflicting sets of requirements, but you keep the code together with increasing complexity to thread the needle of satisfying all the requirements. The latter is the worse offense because it's much harder to decouple two systems than it is to notice a similarity in two bits of code and to extract the commonality.
    - nine_k 3y ago
      Exactly. If you have to care about this for any prolonged time, do yourself a favor and structure your code carefully, think about the right abstractions, etc. If you only need to release it before Christmas no matter what, and sales will wane anyway in 6 months, then even worse crimes against maintainability may find a justification. The problem is, of course, is that even code that was intended as throwaway tends to live much much longer than expected, if it actually works.
    - SoftTalker 3y ago
      Yep years ago I worked on a web application that was made with "classic" Active Server Pages. Each page was a self-contained .asp file. To make a new page, you copied another page and changed it around. This meant that when you wanted to change something on all pages, it was a PITA but not always terrible because tools like grep, sed and awk exist for Windows also. The nice thing was, you could make a change on any page and know that it would only affect that page and had no (or very little) chance to introduce bugs anywhere else in the system. I wouldn't recommend the approach, but it wasn't all bad.
- Brian_K_White 3y ago
  I think of it instead as the code is just a more expressive config file. Smetimes you don't want that but sometimes you do, and it's a counter-productive mistake to only ever go one way or the other in all situations instead of identifying what best serves different situations.
SoftTalker 3y ago
This is sort of the suckless approach. Most (all?) of their projects are customized by editing the source and recompiling. From their window manager, dwm: dwm is customized through editing its source code, which makes it extremely fast and secure - it does not process any input data which isn't known at compile time, except window titles and status text read from the root window's name. You don't have to learn Lua/sh/ruby or some weird configuration file format (like X resource files), beside C, to customize it for your needs: you only have to learn C (at least in order to edit the header file). https://dwm.suckless.org/ https://dwm.suckless.org/
dmz73 3y ago
Problem with python based "systems" of any sort is that they break over time without constant maintenance. make from 2000 will still work with makefile from 2000. Python script from 2015 will not work today unless you have maintained it over that time. Every time I try to use any Python script for anything I follow the posted instructions and end up with an error. Something somewhere has changed and the script no longer works...if it ever did, there is no way to know or go back to the working version. So for me anything more than 10 lines of Python can be considered broken and unmaintainable.
- nerdponx 3y ago
  It's possible that you experienced the end of the 2->3 transition. My Python scripts from 2015 all still work, except the ones that used the then-experimental async framework, which was widely documented as experimental and subject to change.

teaearlgraycold 3y ago

I’m a big fan of copy-pasting code. When you are just learning to program you learn all of the common abstractions, for loops, functions, modules, etc. to reduce code duplication. This leads too many devs to think duplication is a bad thing to be avoided at all costs. I’ve seen a ton of terrible libraries out there that aim to end code duplication. Please, I can handle needing to copy/paste a couple of lines of code around my code base. But I can’t handle your bad abstractions.

nine_k 3y ago
Copy-pasting is fun when you add code, and a pain when you subsequently have to alter it. So it's easy to sell to a beginner or a hobbyist, and it also works well in projects which do not live long, like most games and many websites.
- smilliken 3y ago
  It can go either way. If you duplicate code, but the two copies need to stay in sync, then you've made it a bit harder and more error-prone to maintain. But the worse offense is if you have some code that serves two conflicting sets of requirements, but you keep the code together with increasing complexity to thread the needle of satisfying all the requirements. The latter is the worse offense because it's much harder to decouple two systems than it is to notice a similarity in two bits of code and to extract the commonality.
  - nine_k 3y ago
    Exactly. If you have to care about this for any prolonged time, do yourself a favor and structure your code carefully, think about the right abstractions, etc. If you only need to release it before Christmas no matter what, and sales will wane anyway in 6 months, then even worse crimes against maintainability may find a justification. The problem is, of course, is that even code that was intended as throwaway tends to live much much longer than expected, if it actually works.
  - SoftTalker 3y ago
    Yep years ago I worked on a web application that was made with "classic" Active Server Pages. Each page was a self-contained .asp file. To make a new page, you copied another page and changed it around. This meant that when you wanted to change something on all pages, it was a PITA but not always terrible because tools like grep, sed and awk exist for Windows also. The nice thing was, you could make a change on any page and know that it would only affect that page and had no (or very little) chance to introduce bugs anywhere else in the system. I wouldn't recommend the approach, but it wasn't all bad.
Brian_K_White 3y ago
I think of it instead as the code is just a more expressive config file. Smetimes you don't want that but sometimes you do, and it's a counter-productive mistake to only ever go one way or the other in all situations instead of identifying what best serves different situations.

SoftTalker 3y ago

This is sort of the suckless approach. Most (all?) of their projects are customized by editing the source and recompiling. From their window manager, dwm: dwm is customized through editing its source code, which makes it extremely fast and secure - it does not process any input data which isn't known at compile time, except window titles and status text read from the root window's name. You don't have to learn Lua/sh/ruby or some weird configuration file format (like X resource files), beside C, to customize it for your needs: you only have to learn C (at least in order to edit the header file). https://dwm.suckless.org/ https://dwm.suckless.org/

dmz73 3y ago

Problem with python based "systems" of any sort is that they break over time without constant maintenance. make from 2000 will still work with makefile from 2000. Python script from 2015 will not work today unless you have maintained it over that time. Every time I try to use any Python script for anything I follow the posted instructions and end up with an error. Something somewhere has changed and the script no longer works...if it ever did, there is no way to know or go back to the working version. So for me anything more than 10 lines of Python can be considered broken and unmaintainable.

nerdponx 3y ago
It's possible that you experienced the end of the 2->3 transition. My Python scripts from 2015 all still work, except the ones that used the then-experimental async framework, which was widely documented as experimental and subject to change.