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."
Experienced people have experience in things they have experienced
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 don't miss the days of my PDP-8 programming. OTOH, I do a lot of embedded stuff as a hobby these days, and it's incredible to think that a lot of the newer programmers think you need huge resources to do even minor tasks. I sometimes choke at the megabytes of dependencies sucked into a small piece of code... Anyway, it's a bit of "Get off my lawn" and a bit of "when the car starts skidding, you really do need to understand oversteer, understeer, and torque steer to keep from getting wrapped around that light pole." And yes, I do know that torque steer has little to do with the first two. :-)
but other than that I fail to see the outrage. I also don't see a lot of value in learning things you won't likely need to use. Whats the cost/benefit to learning and mastering assembly if you aren't going to need it? Building software as if you have low resources is fine, so long as you aren't compromising quality to make sure it will run on an archaic hardware. Making things as lean and fast as you can is always plus... if you have the time. Which is another thing today's programmers deal with more: insane deadlines. Expectations are growing and deadlines are getting shorter, and today's programmers (unfortunately) cut a lot of corners and don't get the chance to truly optimize something, just so they can get it out the door.
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.
One of those interviewed in the article complained about the fact that modern day programmers try to solve the problem through an IDE or debugger, instead of putting in statements which change the output of the program. They wanted printf debugging. While I do value a good tracing subsystem, I for one, am grateful for modern debuggers which let me view the state of the system without having to modify/redeploy the code.
we had to code uphill in 10 feet of snow on an abacus using roman numerals.
PocketPermissions Android Permission Guide
Yeah, that was my first thought. I'm pretty long in the tooth myself, but for the most part, if something has been forgotten, it's because it is no longer of use.
Sure things come back (the mobile app market is a good example), and this becomes a great opportunity for the older generation to pass on information to the younger. But I'm not going to miss the days where you had to figure out how to handle your data set when you couldn't use more than 64k of consecutive memory.
Thing is, a lot of the stuff that was required knowledge and isn't now is probably unlikely to come up very often any more. So knowing it internally isn't as important as it can just be looked up for a one off use. Sure, maybe a basic overview understanding of some of the potential issues may be useful, but details of something that you might use once and not again that can be looked up isn't.
I think my phone has a bit over 200MB of memory, so any code optimisations for a computing device with less than that aren't as important as they would have been back when computers had less RAM (computers did have double digit RAM at some point, right? My history of computer hardware isn't that great)
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.
Oblig.: A Bunch of Rocks. :D
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
One of the first things I learnt when troubleshooting problems is that it is probably a problem with your code, and not the hardware or external software libraries (apart from rare cases).
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.
We still use straight C, sometimes even intermixed with assembly. We know all about resource constraints, given that our microcontrollers sometimes only support a few kB for instructions and data RAM. As far as debugging goes, I'll see your debug-with-printf and I'll raise you a debug-with-oscilloscope-and-GPIO-toggling.
:(){
I prefer "less code"*.
I find
- it is usually easier to manage less code
- has very little depencies
- is usually easier to debug
- is usually more efficient
I have a feeling some people just don't even check anymore what dependencies they suck into it.
Just recently, I had to look at Microsoft Exchange, a database had a problem. And the commandline tool to fix it didn't work anymore either.
I took depends.exe and looked at it. The commandline tool to fix the Exchange database files indirectly depends on Internet Explorer. I copied a dll in the directory from an other machine and now the commandline tool works again.
Some people really are crazy.
* Not to the extreme ofcourse.
New things are always on the horizon
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
I'm glad you added "not to the extreme". Some people like less code, so they have everything in one big function with variables such as "q" and "mm".
I prefer more code: many small functions with readable names. Then again, I use auto-completion so I don't get too tired.
Even modern operating systems are largely written in HLLs
I guess you consider C a High Level Language. I think a LOT of people would seriously disagree with you.
I don't care what OS you are using. Those are written in C and Assembler. Look HERE for yourself.
You are not going to find any php, python, java, perl, ruby etc. etc. there, not a line of it.
Mostly your comments are pointless. Most really "good" HTML is still written by hand. It may get spewed from some content management system, but who do you think wrote all the HTML and CSS for those? Do you think JOOMLA magically coughed it up?
You are seriously clue impaired.
Hey KID! Yeah you, get the fuck off my lawn!
But these are still in use. Forget mobile phones, those are massive computers. When you're on a device with a max limit of 1M RAM then you need to worry, or even if one of the processors only has 256 BYTES of RAM, then you seriously need to worry. When the CPU runs at 1MHz or less with one instruction per cycle then you have to worry about what's efficient code and what isn't. This is stuff people have had to worry about this year, not in the 1980s.
This applies on the high end too. Maybe you've got 4GB of memory but you're using all of it, then you're resource constrained again. Or you have a CPU bound algorithm and efficiency matters again. Or you're doing databases and optimizing the access keeps the web site visitor from waiting needlessly. At some point you just can't be naive and say "we'll just get more memory and next year's cpu".
A big change I see overall is that in the past the kids who went into computing used to be really interested in how computers work, they didn't shy away from assembler or schematics, the operating system was something that you dove into and tried to understand at the lowest levels, and so forth. Today though the newcomers seem to be interested in doing web stuff and applications and while leaving the computer and OS as black boxes that they don't want to understand.
Every once in a while I read an article on Slashdot about how the current generation of programmers churn out only the shittiest of code; how they have no idea how a computer works; how they could never program without a fully-featured IDE with Intellisense that renders instantly. As an undergrad in a CS/ECE discipline, this has always surprised me-- I can only speak for the curriculum at my school, but I can assure you, these mythical 'lost programming skills' are alive and well. Most of the supposed missing skills are addressed in the following mandatory courses, required for graduation from CS/ECE at my school:
Yeah, sure, the some folks at the bottom of the class may be shitty programmers who scraped by with a "barely passed" in the mandatory courses. But surely they existed 10, 20, 30, 40 years ago as well. I'm not sure where people are getting this idea that new coders have no skills. What do they think we do for four years, set up MySQL and write PHP for it?
When the critical mass of programmers just don't worry about efficiency you get this sort of behavior of the type that makes other engineers cringe. Software right now is sort of like the auto industry in the 50's, we're all about adding cool looking tail fins while sticking a cast iron engine block up front.
I have seen people recite the mantra of "don't optimize prematurely" when I can tell that they think it means to never optimize.
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?
Over the last few years the most disturbing trend I have seen is programmers that do not have the ability to ship a product. You can talk all the shit you want about architecture, cute technology, methodology but if you don't ship product you don't count.
Got Code?
My own experience has born out much of what the author states -- yet he really doesn't go far enough. The problem is less with the new coders and more with the system and what University's and Computer Science departments are teaching (or NOT teaching, as the case may be).
Even since as far back as 25 years ago far too many programs have been aimed at theoretical computing models and don't teach practical design methods -- especially for embedded applications. At the company I used to work for, we specifically would not hire anyone with a Computer Science degree unless they came on board as a contractor for 6 months first (until we could see if they actually had a clue) -- EE's and ECE's we would usually hire outright (though we sometimes regretted it).
The emphasis on people not understanding hardware interfacing in the article is spot on -- I deal with programmers quite often who have absolutely no clue what happens when the code they have written actually runs and tries to talk to hardware (and they have equally poor understanding of assembly code and how compiler theory applies to the translation between a high level language and what actually gets executed).
If you are dealing with Windows or OS X apps that have what amounts to unlimited memory space and an insanely fast processor, this is borderline acceptable (though it still yields horrendous code that is often far more bloated and slower than it needs to be.
To those who say that it is a bad idea for a company to allow their programmers to "waste time" writing good or optimized code, I say, "it all depends on your target market" -- and whether or not you have to support the product into the future.
I personally have worked on a project where we had 3 high level engineers spend 4 months to re-architect code in such a way as to allow us to eliminate a single IC that cost about $0.25. In essence, we spent a man year of effort to eliminate a part that cost less than a quarter -- and it was an EXCELLENT investment and made perfect financial sense. This IC was on our display processing board and went into basically every item we produced (TV sets), on multiple production lines and across basically every screen size. This same design was used (with slight modification) over almost 6 years. In each average year, over 1.5 *MILLION* of these boards were produced and sold -- which means that eliminating that part saved us around $375,000 *per year* (and probably close to $2.5M over the life of the design).
Similarly, I actually spent almost 3 months hand optimizing Keil C code (and hand-coding some routines into assembly, as I can generally do a far better job than the compiler) to allow the code to ship in a micro with one size smaller embedded ROM (at a savings of several DOLLARS per part). We shipped our initial production run with the larger part to meet schedule and then shifted over to the smaller one as production continued.
Other things that current software engineers I run across are completely ignorant of is that there ARE errors in hardware and that there ARE differences between different manufacturers devices -- and they often have to be treated quite differently. I primarily write low level embedded device drivers for a living -- and let me tell you, the number of glitches I see in hardware are legion. So are the differences in parts that are "theoretically" identical from different manufacturers. A good case in point would be when our purchasing department decided to sub a Xicor 24C series I2C EE for an ST 24C I2C EE. They are supposed identical parts, with identical specs, with identical memory capability, etc -- but the Xicor part handled the internal voltage pump differently for consecutive rewrites across blocks of memory cells than the ST part did. The end result was that while the part initially worked, they began failing in the field within a few months -- where some of the original ST parts are still working to this day. There was nothing wrong with the Xicor part, per se, and once we ch
Funny, the "demo scene" link mentions how the old-timers are frustrated by the newcomers.
If you want to learn something to an extreme and have it be relevant 20 years later, become a carpenter or a stone mason, stay out of software.
And to be clear, I am not ripping on carpenters or stone masons, just that if you get into software, understand that 90% of what you know at any point in time is going to be useless 20 years later.
Take an expert in DOS interrupts, BIOS minutae, 80386 code optimization, utilizing EMS and XMS memory from 1991 and transport him through time to today. He could very well be immediately unemployed for a significant amount of time. And of course, if smart and adaptive that person can learn new things.
My point is, you can't stick a pole in the ground and say, "this is it, MASM, Visual C++ 1.5 and MFC, thats it! I don't have to learn anything else! Time to start memorizing the instruction set!"
Now I am not saying not to learn something to an extreme either, just don't expect relevancy 20 years hence.
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.
Your missing the fact that the development machine that was used to develop this code probably had 64k or less of RAM - "pointer_to_the_structure_containing_the_information_about_xy" could result in the code not compiling due to memory constraints on the build machine.
I agree with what you're saying - a variable named "q" is probably a good example of somebody who's not a good coder and it could have been renamed to something like "ptr_xyInfo" and not blow the build machine.
myke
Mimetics Inc. Twitter
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.
I think "don't optimize prematurely" implies that the code should have reasonable efficiency in the first place, and "optimization" work that sacrifices clarity for further efficiency should not be done prematurely. Some people write code that is very ugly and slow, and such code needs more optimization that tends to make it even uglier.
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
If you ask a carpenter what is "best tool" is, he might ask you "for doing what?"
Most likely, he'll say "my brain".
First to declare interest, I'm 60 pre-internet and generation COBOL/Assembler, get off my lawn generation too!
That said, there's a great many good reasons for doing things economically, concisely and elegantly, Occam's razor, optimal use of resources [a financial matter too], no constant upgrades and server/desktop refreshes. No endless addition of extra storage because stuff is duplicated everywhere. By the way, if someone starts a project to de-duplicate the web down to a 'safe' evel [only ten copies of each thing not 2K] , I'll sign up.
I also resent, mainly government who send me half a dozen self-congratulatory jpegs with each email. You're wasting bandwidth and blocking up the pipes, you folks.
So, if we pay a little attention, we won't need the sprawling power-hungry data centres that all the big players seem to be building. WE won;t need the constant hardware refreshes [admittedly a lot of those are Windows 'upgrades'].
Anyways, don't listen to me, I'm old and grumpy, but take a look at this: http://en.wikipedia.org/wiki/Green_computing especially Product Longevity.
On y va, qui mal y pense!
That's often what it means, and not by accident. "Don't optimize prematurely" means don't optimize until there is evidence that you need to optimize, and then only optimize what there is evidence that you need to optimize. In practice, that means (for many components) never optimizing many aspects that could, in theory, be optimized, because optimization never turns out to be the change that offers the most value for the effort.
Don't optimize prematurely ultimately is just a special case of "do the one thing that delivers the most value for the effort, and repeat as needed". Until optimization od the code for any particular characteristic (whether its speed, memory consumption, or something else) is that one thing, doing it is a waste of resources.
The ability to consistently code cleanly with small functions is great, You basically build application based on well proven code, over time you most likely have blended functions together and optimized them. What you are doing is what we did back in the day's with index card's and floppies, you had a stack of code that you used over and over again, made smaller and better. it's the quality of your functional libraries that make you a success in the industry and keeps you employed.
if you see me, smile and say hello.
Yes, there really are micros much smaller and cheaper than that. $2 in production quantities can get you 128k of Flash and 16k of SRAM on something with a CPU decent enough to run sloppy C code. You're thinking much too large; think $0.30-$0.40 for the cheapies. Google around for the Atmel Tiny4, Tiny12, or the Microchip 10F family for starters...
You are correct about the quantities of scale, but remember that if that electric toothbrush is $40 at retail, the company probably didn't spend more than $8-$10 in materials to build it. At those prices, $0.50 makes a big difference when you are shipping 100K or 1M each month.