Hacker News Reader

Comment by ythn | Hacker News Reader

Sometimes I wish we had more constraints because I fear we've all forgotten how to write fast and lean code in favor of semi-fast but very bloated code.

I remember back when I first used Windows 95, opening programs was very snappy and I was impressed. I imagined Windows of the future being even snappier, but somehow the opposite has happened. Now every application takes a long time to boot up, check for updates, etc just because they use orders of magnitude more resources. I long for apps with instantaneous startup times, no loading screens, and small footprints

View on HN

I've often thought it would be useful to encourage developers to make at least one project for an old computer or games console before they make anything more modern, just so they learn about the importance of constraints and what not. Maybe after that they might stop trying to throw resources at problems to make them go away and start thinking how their code actually works.

I also believe game designers/developers should work on at least one retro game or mod for similar reasons. Teaches them how to actually design levels without thinking about the artistic side, and (thanks to some brutal moderation requirements on the sites hosting this stuff) forces them to get better at game design rather than just walk through Steam/the app store's non processes.

This came up in the RachelByTheBay thread the other day[1] about how she got started... My computer progression started with a Vic-20 (3kB of RAM), followed by an XT (640kB), followed by a Pentium 133 (16MB of RAM). While the Vic and the XT really taught me a lot about how to write lean & mean code, the Pentium really acts like my baseline for what a resource-constrained GUI system can actually accomplish. I could surf the web and talk in multiple IRC rooms quite comfortably (woo mIRC!), probably with ICQ running as well. The fact that Slack is currently idling with an RSS of 1.3GB is bloody offensive in that lens. 81x the memory footprint of the entire machine I used to do all my web browsing on.

I really like your idea of encouraging people to try getting code running on older machines. I really understand that someone who didn't cut their teeth on a 3kB RAM machine won't have the same appreciation for constrained memory computing, and I think your suggestion is a great way to introduce them to it.

Thanks for the thought!

[1]http://rachelbythebay.com/w/2018/04/04/learn/

On a related note, video games today seem to take forever to load. Plus you have to go through several menus to customize your experience before playing. For the NES Mario, you simply power on, start.

We haven't forgotten, we choose to put our time and energy into features rather than performance because that's what end users care more about (at least, it's what they vote with their feet for).

"tragedy of the commons"

I as a freelance developer sometimes make releases whose sole purpose is to refactor/slim down/increase performance with no new features. Yeah, some of my users are disappointed I didn't prioritize X feature they wanted, but it helps mitigate tragedy of the commons a little.

Individually the users are well-meaning with their feature wants/needs, but collectively all the different feature requests can turn your app into a bloated monstrosity if you aren't careful.

Some things have been lost, though, and I'm not even referring to the usual claim about constraints facilitating creativity. Games of the 8- and 16-bit console generations, as well as all arcade games up until that point, were written with CRT monitors in mind and often used 'racing the beam' techniques. This resulted in games with extremely low latency, something you never find in a game of any sort today.

The difference can be felt when comparing a game like Super Mario Bros running on an emulator with a typical LCD screen to running on original hardware with a CRT monitor. The emulated version is so sluggish it feels like you're playing underwater!

> Games of the 8- and 16-bit console generations, as well as all arcade games up until that point, were written with CRT monitors in mind and often used 'racing the beam' techniques. This resulted in games with extremely low latency, something you never find in a game of any sort today.

The techniques haven't been lost - if anything there are probably more people who know how to do those things today than there were in the past.

Typical LCD monitors are undeniably worse in many ways than the CRTs they replaced, but again, most customers turned out to prefer the convenience of the LCD on the whole. Nowadays with the rise of 144Hz monitors those rare users who care a lot about gaming latency do have an option.

This article [1] has been posted on HN before but not everybody has read it so I thought I'd mention it here. If you scroll down there's a paragraph where Dan talks about 144 Hz gaming monitors. Shocker of Shockers (not surprising to me, actually) the Apple ][ has far lower latency than a modern PC, even with one of these monitors. When actually measured with a high speed camera, a CRT refreshing at 60 Hz still has lower average latency than a 144 Hz gaming LCD.

I would expect the NES to perform similarly to the Apple, since it has the same CPU (6502) and also uses a CRT display.

[1] https://danluu.com/input-lag/

Right, I remember advanced 3d software fitting on a floppy. But now a simple Android app can be over 50mb.

No you don't need a video on your login screen.

Define "bloated code".

It's a dying art because now even the cheapest SoCs are capable of running full Linux with a big stack like Node. The Pi Zero is $5 and capable of all these things.

Perhaps the last refuge is battery-powered microcontrollers.

Not necessarily, when you need to have something that will last 5 years on battery power and not cost more than $1 per piece, a Pi Zero won't do.

But even then, if they have up to 512 KB, is like having the same tooling as on the Amiga, Atari, PC (MS-DOS) on a needle size CPU.

For younger generations, you can check on YouTube what we managed to do with 512 KB on those systems, even when using higher level languages.

Depending on the market you can save millions in production picking a cheaper, less powerful mcu. Sure it takes some extra work to squeeze in more features in less flash and every cycle counts, but on runs of millions of devices, this is easily paid back by the extra profits.

Reply on news.ycombinator.com