Hacker News new | past | comments | ask | show | jobs | submit login

Nowdays, I make the distinction between maintainable programs and hackable ones, the later of course being, imo, way better. What I mean by that is essentially that the ratio # by-design features over simplicity of code of the hackable program is considerably higher than the maintainable program (but there is no method to write a hackable program, you either have the sensibility for that or you dont, from my own observation - I'll be happy to discuss the nuances of that statement).

I don't know today but blizzard used to write its game in the hackable way - which is both a feat and rare. Take WoW for example, do you know how the 3d engine basically work? It's so simple and so powerful, you are not going to believe it. WoW is made of levels that are connected by portals. That's it. A level will have portals that will get you to other levels which in turn will have portals which lead to other levels. For example, when you are "outdoor" (with quotes because the engine doesn't know outdoor actually, it knows levels!), you may find a portal that leads you into a tavern for example. Once you are in the tavern, the program can ignore the rest of the world and focus the whole computer resources on the tavern, just like that, by-design. So you'll have taverns as detailed as all of what you can see in the exteriors. Better, you can have landscape in each and every level. (note when the player is in the air, say on a gryphon, some portals are ignored.)

This is both incredible simple and powerful. Remember the game run on early-2000 PCs. Imagine what you can do with that. Caves? Done. Houses that leads into catacombs? Done. Incredibly detailed cities? Add walls and portals, done. Texture streaming? Well, d-o-n-e. Buildings that leads to indoor landscape? Done.

I wouldnt make a game engine differently today.

As a comparison, I'm working on one of the most played game in the world atm which is a maintainable program. You have no idea the pain in the ass in comparison just to add simple features. Oh yeah the code is readable. You can fix bugs. But features, just forget it, it takes a shit load of money to get one done.




If I may ask, I would love to hear your perspective about the fuzzy, squishy reasons why hackable turns into maintainable from a management perspective.

I think I understand what you mean about the two. I know embarassingly little about electronics despite being interested in it for a long time, and have boggled at how much a circuit schematic can differ from PCB layout. On a schematic you can just go "and here are 48 data lines and we'll just draw some dots to illustrate that they yeet all the way over there" but on a PCB you not only have to route them (possibly across multiple PCB layers) but maybe some of the lines have to have squiggly messes in them so they're all exactly the same length and the electrical impulses arrive at the correct nanosecond. The good electronic engineers are the ones who've learned to fluently translate between schematic and PCB layout in their heads, in exactly the same way someone might fluently translate between languages to the point that they forget which language they heard something in, their memory just encodes the meaning directly because the neural routing is that deep/strong/integrated.

A good programmer has learned to understand/accept/integrate(/resign themselves to) the fact that the "focal point" of almost every program is in the programmer's head, not on the screen, and that whatever's onscreen is instead ultimately just a giant pile of little pinball-paddle nudges that hopefully prompt the reader to go "OH" and have the program structure "pop" into focus. Once you have that, you're good to go: that distinct mental model is detached from this class structure or that naming convention or whatever pattern, and thus not bound by the mnemonic/interpretative/structural limitations of the proverbial puzzle pieces that constitute the methodology; it's the superset of all of that and all the machinery that hasn't been set into stone yet.

It is so, so weird how programming slams right up against the edge of design/engineering/bigger-picture-greater-than-the-sum-of-the-parts vs Management™.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: