Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

The 7 most vexing problems in programming

Peter Wayner | Nov. 8, 2016
Here be dragons: These gnarly corners of the coding world can be formidable foes, even for seasoned pros

Closures

Somewhere along the line, someone decided it would be useful to pass around functions as if they were data. This worked well in simple instances, but programmers began to realize that problems arose when functions reached outside themselves and accessed other data, often called “free variables.” Which version was the right one? Was it the data when the function call was initiated? Or was it when the function actually runs? This is especially important for JavaScript where there can be long gaps in between.

The solution, the “closure,” is one of the biggest sources of headaches for JavaScript (and now Java and Swift) programmers. Newbies and even many veterans can’t figure out what’s being closed and where the boundaries of the so-called closure might be.

The name doesn’t help—it’s not like access is closed down permanently like a bar announcing last call. If anything, access is open but only through a wormhole in the data-time continuum, a strange time-shifting mechanism that is bound to eventually spawn a sci-fi TV show. But calling it a “Complex Stack Access Mechanism” or “Data Control Juggling System” seems too long, so we’re stuck with “closures.” Don’t get me started on whether anyone needs to pay for the nonfree variables.

Too big data

When RAM starts filling up, everything starts going wrong. It doesn’t matter if you’re performing newfangled statistical analysis of consumer data or working on a boring, old spreadsheet. When the machine runs out of RAM, it turns to so-called virtual memory that spills out into the superslow hard disk. It’s better than crashing completely or ending the job, but boy does everything slow down.

The problem is that hard disks are at least 20 or 30 times slower than RAM and the mass-market disk drives are often slower. If some other process is also trying to write or read from the disk, everything becomes dramatically worse because the drives can do only one thing at a time.

Activating the virtual memory exacerbates other, hidden problems with your software. If there are threading glitches, they start to break much faster because the threads that are stuck out in the hard disk virtual memory run so much slower than the other threads. That only lasts a brief period, though, because the once wallflower threads get swapped into memory and the other threads hang up. If the code is perfect, the result is merely much slower. If it’s not, the flaws quickly send it crashing into disaster. That’s one small example.

Managing this is a real challenge for programmers who are working with big piles of data. Anyone who gets a bit sloppy with building wasteful data structures ends up with code that slows to a crawl in production. It may work fine with a few test cases, but real loads send it spiraling into failure.

 

Previous Page  1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.