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."
So your particular skillset has fallen out of vogue for a while; it happens. If this stuff is useful, it'll come back. For instance, a lot of the hardware related skills mentioned are still around, they're just considered to be a specialisation these days, in most situations it's safe to assume that the hardware either performs within spec or that the lower layer (OS etc) is dealing with any irregularities.
"Welcome to our world. We are the wasted youth. And we are the future too." Yes, I know these are stupid lyrics.
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
No, it clearly demands a combination of the observer pattern with the command pattern: You observe your lawn, and if you see kids, you command them to get off it.
The Tao of math: The numbers you can count are not the real numbers.
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.
(emphasis mine)
This possibly the most hysterically unintentionally funny thing I've read in a long time.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
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
You need to wait until the shit is done, then profile it. You suck at knowing what needs to be optimized, no I don't care how good you think you are. Ask the experts, like Knuth or Abrash.
So if the speed matters, or the RAM usage, or whatever you write the program, then you profile it, in real usage, and see what happens. You then find where spending your time is worth it.
For example support you find a single function uses 95% of all the execution time. Well, until you've optimized that, it is stupid to spend time optimizing anything else because even a small gain in that function will outweigh a massive gain elsewhere. You need to find those problems spots, those areas of high usage, and optimize them first, and you can't do that until the program is written and profiled.
That is also pretty common too, the "Couple areas that use all the resources," thing. It is not usual for it to be spread across all the code. So you need a profiler to identify those and you then need to focus your effort. You can then break out the ASM hackery for those few lines that have to be super fast, if needed, and you'll achieve most if not all of the result you would from doing the whole thing low level.
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?
No, software right now is turning from a craft into an industry, which means that artisans are being replaced by minimum-wage drones and automated code generators. Of course quality is going to suffer as a result.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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.
Less code does NOT mean smaller file sizes.
I write (in general) smaller amounts of code than any of the other 4 developers I have to work with, but I also document my code as I write it, the doxygen info for a function or methods is fully written out before I start writing the function. I document then write. My files are always larger because my documentation and commenting is far more complete.
Using shorter variable names does not mean you're writing less code, you're just using less text to do the same thing. That also generally means you're writing unreadable code. Disk space and IO for files used in a compile is irrelevant for any reasonably sized project. If your project is so big that the size of your variable names makes a noticeable difference in your build times ... then you need to reorganize your project.
Good code is self documenting, but being that most of us can't write code that beautiful, proper documentation makes the code suck less for the next guy.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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