4 ms·

It's worth researching the demoscene[0] and how demos that looked very complex were made with as few lines of code as possible. Every byte was accounted for and

It's worth researching the demoscene[0] and how demos that looked very complex were made with as few lines of code as possible. Every byte was accounted for and nothing went to waste. This is a common thing in games and Super Mario even re-used the cloud sprite for the bushes[1] Now we have to deal with gargantuan Electron apps that hog your PC's resources for housing what essentially is a lightweight webapp. [0] https://en.wikipedia.org/wiki/Demoscene https://en.wikipedia.org/wiki/Demoscene [1] https://www.todayifoundout.com/index.php/2010/01/the-clouds-and-bushes-in-super-mario-bros-are-the-same/ https://www.todayifoundout.com/index.php/2010/01/the-clouds-...

tluyben2 5y ago
A lot of time and complexity went into inventing those simple things. If you ever made something 'large' in a very constraint environment (like a mcu with 24kb for all including the drivers and the OS) which is what old home computers and consoles had in common with that and demo programming in another but similar way (getting every ounce from the system which has (artificial or real) limitations, you will have noticed that this is hardly comparable with what the author is saying. You are mixing glue and other code and try to sometimes mix them into one thing (stuff a hardware driver inside the business logic) etc. In the modern demoscene potentially more (depending on the allowed size of the end result), but in the other cases the end result will have far less resemblance of something that called be considered and architecture. Or something you want to work with afterwards. The code fits in your head and you understand every byte; that does not scale to much more than indeed these examples. Not something the author is targeting or referencing besides line count. And we are indeed talking line count then k/j or code golfing would fit with different degrees of readability of the end result, just like your examples and most embedded code (not talking rasberry pis; talking what runs in your dishwasher).

tluyben2 5y ago

A lot of time and complexity went into inventing those simple things. If you ever made something 'large' in a very constraint environment (like a mcu with 24kb for all including the drivers and the OS) which is what old home computers and consoles had in common with that and demo programming in another but similar way (getting every ounce from the system which has (artificial or real) limitations, you will have noticed that this is hardly comparable with what the author is saying. You are mixing glue and other code and try to sometimes mix them into one thing (stuff a hardware driver inside the business logic) etc. In the modern demoscene potentially more (depending on the allowed size of the end result), but in the other cases the end result will have far less resemblance of something that called be considered and architecture. Or something you want to work with afterwards. The code fits in your head and you understand every byte; that does not scale to much more than indeed these examples. Not something the author is targeting or referencing besides line count. And we are indeed talking line count then k/j or code golfing would fit with different degrees of readability of the end result, just like your examples and most embedded code (not talking rasberry pis; talking what runs in your dishwasher).