6 ms·
Nowdays, it's impossible to do modern programming without relying on millions of lines of other people's code. It's frameworks and libraries all the way down.
by pubby 9y ago
Nowdays, it's impossible to do modern programming without relying on millions of lines of other people's code. It's frameworks and libraries all the way down.
On the NES however, every line of code is yours. There's no such thing as libraries, operating systems, or frameworks. They don't exist. It's refreshing.
One of the big problems of modern programming is how easy it is to add complexity. As Charles Moore once said:
>"Simplify the problem you've got or rather don't complexify it. I've done it myself, it's fun to do. You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the problem that you actually had."
It's easy to add complexity on modern systems, but it's hard on the NES. The programming too clunky; it's too much work to anything but simple things. For that reason, it's far more common to simplify the problem and reduce features rather than add them. It's a wonderful thing.
- vages 9y agoI also adore old programs for their simplicity. However, I've come to terms with "unnecessary" complexity as a necessary cost of growth and abstraction. Each part of a bacteria, relative to its mass, may be more cost effective than that of a mammal. I'd much rather be the latter.
- TeMPOraL 9y agoIt's true insofar you also count in the evolutionary, worse-is-better nature of software development. I.e. there's lots more of complexity than it's necessary for the level of abstraction and capabilities you want, but that complexity was accrued as people developed and iterated on every layer, mostly leaving it be as it got good enough, and moving on to something else.
- digi_owl 9y agoFunny because at least over in the Linux world i feel the complexity has come as people had started hunting for "perfection". Where before you had a GUI part talk to a CLI part via pipes, now you have them talking to each other via a XML based bus mediated by multiple daemons (one for the bus, one to uphold a fine grained security layer again using XML and JSON).
- gdubs 9y agoSteve Woz in his autobiography said a similar thing about growing up in the Apple II era vs the kids he teaches today; there’s a lot more you can do today, but what you miss is the insight and power that comes from understanding the system as a whole, and being able to leverage all of its parts.
- pjmlp 9y agoNot necessarily, there are hundreds of embedded devices that can be programmed just like in the old days. Arduino, ESP286, ESP32, <pick your own flavour>. And since we are in the context of games and Nintendo, something like Arduboy. https://arduboy.com https://arduboy.com
- falcrist 9y agoEven worse than that, people still use legacy devices like 8051 MCUs in modern products. I'm currently working on an assembly codebase for a SiLabs part. Like... Please move to an ARM MCU with a C codebase.
- pjmlp 9y agoWell, if it is an ARM MCU, Basic, Pascal, Java, C++, Oberon, Ada and Rust are also possible options. :)
- pkaye 9y agoThere is C available for an 8051. The Keil 8051 compiler (now owned by ARM) was pretty good and it had a nice GUI environment. The 8051 is pretty good for certain tasks but when you push it beyond the limits, your effort switches from solving the core problem to managing memory and micro optimization to make things work. Meanwhile with an ARM MCU you don't have to worry about a lot of things. I once spent a couple days optimizing a 32-bit divide for an 8051 to squeeze a couple % improvement in product performance.
- magduf 9y agoAn ARM might be overkill (and a bit expensive) for something that can be done with an 8051. A better choice might be something like an Atmel AVR or Microchip PIC(16 or 32 probably). Those are dirt-cheap, and specifically designed for microcontroller applications with features like on-board ADCs, comparators, timers, GPIOs, etc.
- morio 9y agoI hear this argument a lot in the EE community. Yet, the cheapest 8051 part in single quantities on DigiKey: $0.43. Cheapest ARM Cortex-M0 part on DigiKey: $0.47. I'll take the ease of development and features on ARM for $0.05. You can develop without proprietary development environments. I do my development with a basic gcc+make setup. Of course you can pick up old parts which fell off a truck for cheaper but I'd rather not do that when I depend on these parts for many years to come.
- digi_owl 9y agoEspecially now that every damned language comes with their own custom package manager, with node.js as the posterboy: https://medium.com/@caspervonb/the-internet-is-at-the-mercy-of-a-handful-of-people-73fac4bc5068 https://medium.com/@caspervonb/the-internet-is-at-the-mercy-...
- coding123 9y agoThe graphic on there is brilliant.
- fenwick67 9y agoThey couldn't bother to cite the image apparently but it's from a web comic called Gunshow
- freedomben 9y agoYes it is from Gunshow, and that isn't the full comic. It's even better when you see the whole thing: http://gunshowcomic.com/648 http://gunshowcomic.com/648
- khedoros1 9y agoThose two panels are well-known as a meme image, over probably the past 4 years. Memes tend to transcend their original source; that's probably why the image wasn't properly cited.
- egypturnash 9y agoBecause clearly nobody working on the web as an artist deserves to get credit for their work once it passes a certain threshold of popularity. That said, when K C Green ran a Kickstarter for a plush This Is Fine dog it took in more than ten times what he was asking for; how much of that went into his bank account as profit, I dunno.
- khedoros1 9y ago
- derefr 9y ago> On the NES however, every line of code is yours. There's no such thing as libraries, operating systems, or frameworks. They don't exist. It's refreshing. I would say that there’s still “other people’s code” that you rely on—that code is just reified into ASICs you drive with control messages over IO ports, rather than being OS system-service daemons you drive with control messages over IPC. Also keep in mind that, despite the lack of a forced OS or BIOS on the system itself, Nintendo’s SDKs included snippets or code samples (or sometimes complete small libraries as modifiable assembler source), and developers shared others around when they came up with them to solve a particular problem. (Later on, in SNES/N64/GameCube era, Nintendo effectively handed you a whole library exokernel worth of precompiled, static-linkable libraries for you to use, too. The NES was too small for that, though.)
- corysama 9y ago> On the NES however, every line of code is yours. I once stuck my nose into Game Boy Advance homebrew and was happy to find it can be the same there. Every piece of the hardware is memory mapped. That means, given a reference of the mapped addresses and struct definitions, you can do whatever you want with the machine without any magic, black-box external code.
- zokier 9y agoGBA was the very last of the "old-fashioned" consoles, and as such one of the best targets for homebrew.
- drewying 9y agoI agree with you in general, but I think it's worth pointing out that programming the NES's PPU is actually very similar to programming with a 2D graphics library today. NES games never wrote their own scrolling logic, or there own graphics logic. They wrote tile values into a background table and then told the NES how much to scroll the playing field, and the NES rendered and scrolled everything automagically. NES games never drew their own sprites. They just said "Hey NES, write the sprite at this x and y location" and the NES did it. Audio worked the same way. Honestly, coding for the NES would be similar to working with a simple 2D graphics library. So I don't know if it would be accurate to say "every line of code is yours" on the NES. It's more just that the "libraries" used were implemented in hardware instead of software.
- marshray 9y ago> NES games never drew their own sprites. They just said "Hey NES, write the sprite at this x and y location" Yeah, but the hardware is so limited with weird corner cases that writing a bitblt might be easier. For example, some games have to reconfigure their sprites at the beginning of every horizontal scan line to overcome the hardware limitation on simultaneously displayed sprites (8).
- klodolph 9y agoWhich games? To my knowledge this is at best exceptionally rare because there are only ~114 CPU cycles in a scan line. The reports I've heard are that if you do any OAM changes mid-frame, you get something like four lines of glitches. More common is to just do a full OAM DMA during vertical blank, at least from the ROMs I've seen.
- marshray 9y agoI can't find the original link where I read about this, it may have been more theory than about specific games. These links seem to be relevant: http://wiki.nesdev.com/w/index.php/Sprite_overflow_games http://wiki.nesdev.com/w/index.php/Sprite_overflow_games http://forums.nesdev.com/viewtopic.php?t=16299 http://forums.nesdev.com/viewtopic.php?t=16299