5 ms·
Necessity is the mother of invention and memory/resource scarcity is the mother of quality code A lot of junk and spaghetti code gets written (or copied/pasted
by roymurdock 8y ago
Necessity is the mother of invention and memory/resource scarcity is the mother of quality code
A lot of junk and spaghetti code gets written (or copied/pasted together) today because there are few hardware-based constraints in much of modern app and system dev
I work with a lot of embedded engineers and have the utmost respect for those that work on safety-critical, legacy systems
- emiliobumachar 8y ago"resource scarcity is the mother of quality code" I don't know, your mileage may vary with this one. I have had to make code less readable to make it more efficient more often than I've been forced to find a more elegant way because the clever hack was too slow.
- drabiega 8y ago> memory/resource scarcity is the mother of quality code My experience with Legacy code has been the exact opposite of this. I've seen some really well written and documented legacy code but almost never in resource / performance sensitive areas. People inevitably seem to accept trade-offs that sacrifice readability and maintainability for efficiency.
- C1sc0cat 8y agoWell I recall writing Fortan 77 for a billing system and we had nicely structured code (our team leader was a genius) but we did do some specific stuff eg reading in data in chunks the size of a disk sector.
- maxxxxx 8y agoAnd it was perfectly normal to do stuff like this.
- Pamar 8y agoCanonical example: https://en.m.wikipedia.org/wiki/The_Story_of_Mel https://en.m.wikipedia.org/wiki/The_Story_of_Mel
- carrigan 8y agoI don't believe that hardware constraints have anything to do with code quality. Running your code on a microcontroller will require your algorithms to run in a smaller RAM footprint and potentially come with timing requirements, but do not dictate that you write quality code to do so. You can solve those problems with thousands of lines of uncommented assembly efficiently, but that does not mean it is quality code. I have worked for a significant time in my career as both an embedded engineer as well as a backend engineer, and in general I find that the backend code is way easier to read, maintain, and extend. Embedded code is seldom properly tested and most of it is written in C where people can abuse a library's contracts or the preprocessor. It is not uncommon to find functions that are over a thousand lines in the embedded world. Compare this to Rails where there are a ton of standards, short and succinct functions, and good support for testing. I guess it depends on your definition of "quality code". If you mean code that is dependable and will do one thing well on one platform for the rest of time, then embedded code could be considered high quality. I would debate that these items have more to do with the binary than the code though. If you mean code that conveys how a program works well to other programmers, is under test, and follows some standard structure, I would pick modern app development as typically being much higher quality.
- pjc50 8y agoI don't know where this got a downvote from because it's correct - it's quite hard to build sensible automatic integration tests for embedded code unless you have the luxury of a full system emulation. The only thing that resource constraint forces is less code, especially less dependencies, because you run out of space. The Toyota "unintended acceleration" court case was a flagship example of bad embedded code, that we rarely get to see.
- jacobush 8y agoThe Toyota computer is like a super computer compared to old mainframes. IIRC the Toyota program had 10k global variables updated by spaghetti C code. So you had a lot of space, enough to shoot yourself with C code. Old mainframe code in contrast often operated on records in a batch fashion, with a pretty clear input and output. Of course, the antipattern on enterprise code comparable to thousands of global variables in C code, is to have thousands of columns in hundreds, or thousands even, of database tables, all intertwined and used only God knows where.
- SilasX 8y ago>A lot of junk and spaghetti code gets written (or copied/pasted together) today because there are few hardware-based constraints in much of modern app and system dev Maybe in the general case, but there are so many exceptions they're almost the rule. Apps like JIRA and Electron constantly have slowdown from bloat that pretty clearly is swamping the hardware constraints and would be avoided with better coding. Also, I see classic games that are emulated or transformed on "fast" hardware that nevertheless have input lag. I've seen this one the Wii console for SNES games, and on inflight emulator that ran Pac-Man. Plus, TVs that upscale make Dance Dance Revolution have too much lag to be playable.
- bbatha 8y agoI wish that were true. I’ve worked on a lot of old FORTRAN code bases (including a couple that started life as punch cards) and it just doesn’t bear out. Remember FORTRAN comes from an era we’re people we’re concerned about the overhead of a function call. Programmers also worried about he memory overhead of comments in their editor! Most FORTRAN is a mess of gotos, common blocks, implicit types and other relics that should be left to the past. This code doesn’t age well either, optimizers don’t do well with gotos and the lack of function calls means that there are copy and pasted snippets of what my coworkers and I called “fassembly” that were untranslatable. One time I spent days translating one of these functions only to realize that it was an fft, I swapped it out with one from a library that had be optimized for decades the code was easier to read and 100x faster. I’m not even going to discuss any code base that was unfortunate to need any kind of string manipulation. To cap it off FORTRAN 77 doesn’t even allow variables with names longer than six characters. That all said, modern FORTRAN is entirely pleasant language. Just stay away from the legacy.