Slashdot Mirror
What Today's Coders Don't Know and Why It Matters
jfruhlinger writes "Today's programmers have much more advanced languages and more forgiving hardware to play with — but it seems many have forgotten some of the lessons their predecessors picked up in a more resource-constrained era. Newer programmers are less adept at identifying hardware constraints and errors, developing thorough specifications before coding, and low-level skills like programming in assembly language. You never know when a seemingly obsolete skill will come in handy. For instance, Web developers who cut their teeth in the days of 14.4 Kbps modems have a leg up in writing apps for laggy wireless networks."
they aren't trained to engineer software, and the industry hasn't incorporated good engineering practices.
The Kruger Dunning explains most post on
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - Donald Knuth
Most developers will never need for their apps to run in constrained environments, and most employers don't want to spend money to eek out performance when average performance is perfectly fine.
Too many programmers get caught up in trying to make something the fastest, or most memory efficient, or makes the best use of bandwidth. When most of the time, it just doesn't matter. Such things are expensive, and in the long run it's cheaper to be fast and sloppy than slow and lean.
If you need web hosting, you could do worse than here
I do agree with you. I'm new to programming myself, but I've always felt the need to learn more about the computer than just the high-level language. That's why I want to take up PERL. Apparently, there's still a strong Ruby community out there, so I might take that up as well. On top of that, I like to plan out my programs. I like to know exactly what it will do before I do it, which may require writing out the code first. I'm only two years into programming, so I still have a long way to go. I just want to make sure that what I do is very efficient so that all my future supervisor has to do is sit back and trust me.
we had to code uphill in 10 feet of snow on an abacus using roman numerals.
PocketPermissions Android Permission Guide
That lib requires cooperative event handling in the kid class. I much prefer the longer, but deterministic form:
if ( $myLawn->getContents()->filter({type: kid})->count() > 0 ) {
$myShotgun = new Shotgun()
$myShotgun->loadAmmo();
$myLawn->getOwner()->wieldObject($myShotgun);
for( $i = 5; $i>0; $i--) { sleep(1000); }
while ( $myLawn->getContents()->filter({type: kid})->count() > 0 ) {
$myShotgun->fire();
}
}
-Billco, Fnarg.com
the worse code, yes
But that runs fast on old/not so fast hardware
Example http://en.wikipedia.org/wiki/Fast_inverse_square_root
how long until
Some old-school developers prematurely optimize for things we no longer need to optimize for (and shouldn't). From an older post of mine:
He was optimizing for resources that were no longer constrained, and consequently pessimizing for the resources we actually cared about. RAM? Dirt cheap, at least for the dataset sizes involved in that project. Much more expensive was all the extra disk and CPU load he was creating on the company-wide database server (which is sufficiently powerful to serve the entire company when it's not being deliberately assaulted).
I'm not "anything goes" by any means, and I'm the guy responsible for making sure that lots of processes can peacefully coexist on an efficiently small number of servers. But for all intents and purposes, most of our apps have unlimited resources available to them. If they want to use 100% of a CPU core for 5 minutes or 2GB of RAM for half an hour a day, so be it. I'd much rather run simple, testable, maintainable code that happens to use a lot of server power than lovingly hand-mangled code that no one but the original programmer can understand and which interacts with the rest of the network in entertainingly unpredictable ways.
Dewey, what part of this looks like authorities should be involved?
I'd submit the game development industry is still one place where tight, fast-running code really matters. But the trick is, writing efficient code is extremely slow and expensive to develop. At my company, our game engine is written in C/C++ like most places, but we still write most of our tools in C# or Python (and from what I understand, that's also becoming the norm). We well understand that we're trading efficiency of execution for efficiency of performance in those cases. Both types of coding certainly have their place.
I get a little annoyed at zealots on both sides that claim that "C++ is dead" or "C# is too slow", blah, blah... If you ask a carpenter what is "best tool" is, he might ask you "for doing what?" Programming is no different. People who cling to a single language or paradigm are just missing the big picture, IMO.
Irony: Agile development has too much intertia to be abandoned now.
Having developed on old platforms and new ones and back to old one. You actually get much better quality out of the new stuff. We look back at the old software with pride on how well it runs, forgetting the decades of errors and problems it had in the past, and the years of effort it took to get them run at that level.
The old stuff seems to run faster but not really. Old word perfect, no realtime spell check, no fonts, bold and italics were the big features, along with multi-column and margins. The display was 80x25 and still the app crashed and you lost all your work. And took minutes to load off your floppy.
Can new developers write tighter code. Sure they are not stupid. But how much can you loose from doing it? Getting in too late in the market? Loss of multi-platform support? Hard to maintain? Vulnerable to hacking?
I just heard a report that the high frequency trading systems are easy to hack into because they have been developed for all speed... Leaving room for hacking in. As anyone has done coding knows it takes 10% to get the program to do what it needs to do and the rest to make sure humans don't cause it to do something else.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Your phone has 200MB of memory, so when a stupid app uses all 200MB ... then what? You don't run your other apps? Being wasteful is stupid regardless of where you do it, in your home, or in your code.
(computers did have double digit RAM at some point, right? My history of computer hardware isn't that great)
http://www.atmel.com/dyn/products/product_card.asp?part_id=4605&category_id=163&family_id=607&subfamily_id=791
If you're too lazy to follow the link:
The high-performance, low-power Atmel 8-bit AVR RISC-based microcontroller combines 512B ISP flash memory, 32B SRAM
That '32B SRAM' is actually shared with the 16 general purpose registers, so if you take those out, you have 16 bytes of ram. With those 16 bytes and the rest of the IO and other functions built in you can easily control 3 servos from a single input line, which takes feed from a larger motor. That chip is capable of driving stepper motors with interpolation for a CNC machine, again taking position information from somewhere else, not processing the command tree itself. The chip is used to handle input from several glass breakage detectors and performing false positive checks to avoid triggering because the cat knocked something off that didn't actually break an external window.
In short, the modern world is built on devices with tiny ass amounts of ram. Do you wear a digital watch? They're getting rarer now days, but thats another example.
Its not history were that stuff mattered, its right now today, you just aren't aware of it. Nothing about the concepts used then is bad today, they STILL provide massive benefits if you know them and follow them. You're basically saying 'gasoline is cheap, just burn more to get more done' and ignoring the fact that there are clear physical limits to computing, a given amount of mass, regardless of how its configured, can only store so much data and performing so many computations. Eventually you'll have devices which simply can't meet the demand being put on them ... because people thought ram/processing power was cheap and we no longer need to worry about those old guys.
Locality of reference, cache hits, pipeline stalls ... all these things that you know nothing about, yet drastically affect how your shitty little app runs. Sigh, I swear at some point in the past people actually took pride in 'doing it right'.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager