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."

Comments

Newsflash

[Anonymous Coward]

Experienced people have experience in things they have experienced

Re:Newsflash

[canadian_right]

newsflash - many schools no longer teach low level programming.

If you want to get good, truly good, you'll have to learn some of this on your own. And in the good old days all you had to do was count up clock cycles and you were done. Modern processors with multi-stage pipe-lines and out of order execution are much harder to hand optimise. When a pipe-line stall is very expensive you don't worry so much about clocks.

tl;dr

[itchythebear]

tl:dr - "Get off my lawn"

Re:tl;dr

[cptdondo]

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. :-)

Re:tl;dr

[coolmadsi]

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)

Re:tl;dr

[maxwell demon]

What people consistently forget is that today there are generally many applications running at the same time. Also, it makes a big difference in performance if the data you are about to access is still in the cache.

Re:tl;dr

[sqlrob]

Depends what you mean by "double digit".

I cut my teeth on a computer with 5K RAM. If you want to go true single digit, I think there were some with 16 byte.

Re:tl;dr

[50000BTU_barbecue]

VIC-20 represent! I built a 16K memory expansion from plans in 73 magazine and chips I bought with money from collecting return deposit bottles!

Re:tl;dr

[Lennie]

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.

Re:tl;dr

[Lennie]

While I'm making lists, I should have added:
- easier to read code
- easier to understand code
- done faster reading the code

Re:tl;dr

[somersault]

(computers did have double digit RAM at some point, right? My history of computer hardware isn't that great)

*sob*

Re:tl;dr

[queazocotal]

In addition, most app programmers test their application on their comparatively fast machine, while not running other stuff in the background.

If developers were forced to test their app on 4 year old hardware, then it would improve general performance lots.

Re:tl;dr

[Darinbob]

Get off my lawn because it is resource constrained you bloated juveniles!

Re:tl;dr

[obarel]

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.

Re:tl;dr

[Darinbob]

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.

Re:tl;dr

[Darinbob]

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.

Re:tl;dr

[Darinbob]

However even today we have countless devices that are vastly more constrained. The phone is a bad example since it's a relatively large device with lots of horsepower and memory. There are more embedded devices in use today than there are computers and smart phones combined! There is software in your microwave, your smart meter, your automobile's ignition system, your elevator, your wristwatch, your router, and so on. And your smart phone isn't just apps, there is some extremely resource constrained software in it to manage the networking and phone calls and audio handling. Writing DSP code is done by people who are constantly worried about resource constraints and optimization.

Re:tl;dr

[maxwell demon]

A variable named "q" is exactly as much code as a variable named "pointer_to_the_structure_containing_the_information_about_xy".
Code is not measured in characters.

Re:tl;dr

[Ihmhi]

I disagree here.

This is hugely anecdotal, but computers are generally getting faster. We have faster processors, faster RAM, faster hard drives, etc. And yet a lot of software today runs like molasses. Why? I think programmers have too large a margin of error.

Take a look at the amazing stuff the Demo Scene can do - they can create a beautiful work of visual and auditory art that is squeezed into a few kilobytes. Nowadays we have quad core 3.0 GHZ processors and programmers have a larger margin of error. They can make something that is an inefficient pile of garbage and the sheer speed of the computer can pick up the slack, but we suffer when things get bogged down.

The fastest computer I've ever used was an Amiga with less processing power and RAM than most cheapo cell phones on the market today. They had very little to work with and they did some of the fastest, most efficient programming I've ever seen.

I really wish there were highly notable awards for excellence in programming, especially with relation to efficiency.

The only place where resource efficiency is king is Wall Street, where a few milliseconds faster means making a lot more money than the competition.

Re:tl;dr

[Anonymous Coward]

Our strategy for this is to have developers test on virtual machines that receive an artificial memory/CPU limit. You can give the developer a machine that screams through the compiles and enables him or her to have tons of windows/applications open and yet see how the app performs on a machine that's not capable of doing half the stuff the developer needs to do. It's also a great solution for testing against different platforms.

Re:tl;dr

[mattack2]

I think everybody (especially HI) should have to _use_ the lowest capability machines for day to day use.. (But have the fastest machines possible for building & debugging.)

Unfortunately, that would probably lead to machines being unsupported by new releases even more quickly.

Re:tl;dr

[jakartus]

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.

Re:tl;dr

[ultranova]

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.

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.

Re:tl;dr

[Dutch Gun]

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.

Re:tl;dr

[mykepredko]

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

Re:tl;dr

[jellomizer]

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.

Re:tl;dr

[sqlrob]

No, I was talking the Vic-20. 5K, 3583 bytes usable, IIRC.

Re:tl;dr

[r6144]

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.

Re:tl;dr

[BitZtream]

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.

The reason you found it long in the tooth and then followed that statement up with 'its forgotten because its unused' just shows exactly how little experience you have.

First and foremost, an assembly language programmer whos been dealing with 1k or 256 bytes or even 64k can pick up just about any language and whip your ass with it, regardless of how long you've been doing it if you don't have the same sort of experience.

Every single thing you learn doing low level embedded code applies to ALL programming. When you get stupid and start spewing shit like 'ram is cheap' you're the exact type of idiot who not only wastes ram, but ends up with slower lookup times for the required data as well, due to your shitty wasting of memory.

Using ram isn't the problem, its making statements like

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.

'

that reenforce the fact that you don't get how important those lessons were.

You may write code for a living or for fun, but you are not any sort of software developer or engineer. You are more or less exactly what the full article describes.

Re:tl;dr

[BitZtream]

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.

Re:tl;dr

[BitZtream]

And a too descriptive variable name also means you can't repurpose a variable, for example price_per_unit *= number_of_units won't work, cause then the variable will be lying.
cost *= units, on the other hand, works fine.

Repurposing a variable like that is very bad form, it generally makes your code far more complex for the next guy who has to read it. The compiler will deal with the fact that you used two variables instead of one just fine, it'll optimize it down to the same code (well, GCC might not, but any respectable compiler will)

Re:tl;dr

[BitZtream]

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'.

Re:tl;dr

[BitZtream]

He could very well be immediately unemployed for a significant amount of time.

If you find a true 'expert' then I can think of several businesses that would hire him in an instant, a few government organizations as well.

'experts' don't lose their value very quickly, people who think they are experts generally do. There are plenty of places that want experts in old tech to just get them through daily operations.

You know you're a young'en when you talk about not being able to find a job as a dos expert ... have you heard of COBOL? THATS the example language you use for making the point you're trying to make ... of course, COBOL 'experts' are snapped up in an instant still today.

You really don't get it.

Re:tl;dr

[maxwell demon]

(well, GCC might not, but any respectable compiler will)

What is it that you felt the need of adding some GCC bashing here?

Re:tl;dr

[BrokenHalo]

If your code is that performance critical, you should be able to optimise it yourself.

Re:tl;dr

[maxwell demon]

The fact that GCC is notoriously bad at optimisation?

The general quality of GCC's optimization is completely irrelevant for this thread.

Re:tl;dr

[BrokenHalo]

If you ask a carpenter what is "best tool" is, he might ask you "for doing what?"

Most likely, he'll say "my brain".

Re:tl;dr

[Joce640k]

If 'q' is a variable with a short lifespan/scope (eg. one small function) then short is better.

If it's a global variable in a program with thousands of lines ... not so much.

Re:tl;dr

[Joce640k]

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.

If you transport him through time, sure. If he's been keeping up to date over those years he's going to kick serious ass compared to today's college kids.

Re:tl;dr

[dzfoo]

Or a hammer. Here, let me show you, lets compare.

            -dZ.

Re:tl;dr

[onepoint]

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.

 

Re:tl;dr

[Lonewolf666]

Interesting that such extremely tiny microcontrollers are still being made. I'd have expected things to start at something like the ATtiny85 (just googled at http://www.atmel.com/dyn/products/product_card.asp?part_id=3612). Still small at 8 kByte Flash and 0.5 kByte RAM, but it gives you a bit more to work with. The price difference is size and money is small. 8 pins vs. 6, and the first online store where I found it charges $2.40.

Unless you are planning some mass produced, really cheap product that needs a microcontroller, I'd say optimizing your code to fit in the ATtiny4 comes under "premature optimization".

Which does not mean I disagree with pride in 'doing it right', but in most cases finishing the product might be more important than squeezing another dollar out of the production costs.

Re:tl;dr

[CptNerd]

"q" is a bad variable name, just as "i", "j", "k" etc. are bad for counters. That's why I was taught to use "qq" or "ii" or "jj" as variable names. Easily grepped for and found, and still short enough not to interfere with variables that need to be better documented with descriptive names.

Re:tl;dr

[Tenebrousedge]

What is a headers? Help! What is a car??

Re:tl;dr

[Terrasque]

variables such as "q" and "mm".

Guilty :/ In my (terrible) defense, I use them consistently for the same type of things in every function:

q = query : storing data from a query to an external resource, or data to be sent to external resource (depends a bit on size of query and what the data is planned for). Database / soap and similar.

r = Result - the result to send back from the function.

x, y, z = temp variables in for loops, when what it is is obvious and the loop is small (fits in half a screen)

r* = temp variables to store data for the final result (list of data to be hammered into a string, for example)

c = counting variable, used for counting in loops mostly

qr = query result, when q is the data to send for querying.

other (more seldom used ones):

a = user input. Yeah, very seldom used, because 90% of the time, I use a proper variable name for this.

n = also counter, but not used in loops.

u = unicode string, mostly to remove RSI when banging together / tweaking large amounts of text line by line. Not unusual to see 5+ lines of "u = ...." and then at end you see "proper_variable = u"

s = bytestring equivalent of u

d = dict equivalent of u

l = list equivalent of u

So yeah, at first glance it looks like a Crazy Man's code (which, I won't deny it, it basically is), but it does have its internal logic, and once you pick up on that it's quite readable :)

Re:tl;dr

[MichaelSmith]

Where I work a short loop could be a couple of hundred lines long. And yeah I know that is the real problem. Thats what happens with large scale systems which are maintained over several decades and continents.

Re:tl;dr

[obarel]

Just remember your poor colleagues trying to understand your inner logic when you're away and they have to fix a bug while customers are complaining and they've got ten other things to finish by yesterday.

When time is short and you've got to dig in someone else's code, you appreciate every bit of help. "q" for "query" is not so bad if it's consistent, but the brain reads "query" a lot faster, even if it takes more time to type. Every abbreviation is something that the brain has to juggle, whereas there's no extra burden when you use words such as "result" or "query".

And please, please don't use the abbreviation "cnt" for counter.

Re:tl;dr

[Terrasque]

no worries mate, they are all perl / php heroes, and think functions, code reuse and splitting logic in different files are something scary and exotic. And I'm even using *classes* in my programs. They won't touch it with a 10 foot pole.

Sometimes I think I'm the only sane man there, which have to be an illusion, on account of the company still being there.

Re:tl;dr

[Anonymous Coward]

"Of course quality is going to suffer as a result."

Is it? I dunno about you but I remember the days of having software far more buggy on average than we have now.

I can go months without seeing a fatal crash in an application or the OS nowadays, it used to be a daily or at best weekly occurance many years ago.

Usability has improved dramatically, and sure my software may not be "hand crafted" in assembly, but it doesn't need to be, because any improvement that would make would be outweighed by the instability, the longer time to market, and the fact that compilers are good enough now that I wouldn't even notice the sub-millisecond speed boost. On the contrary to the article - I think developers have learned from their predecessors - they've learnt that it's better to leave the fiddly dangerous stuff to computers that can do it better, and focus on actually getting software written. If anything it's the old folks who still think assembly is relevant in anything other than an absolute tiny minority of applications that haven't learnt from the problems their own generation's software suffered that are the real problem.

There are two types of older developer, those who have kept with the times, and those that haven't. The former types are busy being top selling authors in computer books, or working at companies like Google, and Microsoft etc. pouring out genuinely interesting new tools and research, or heading up highly succesful software development teams. The latter type are the ones who write articles that basically say:

"Youngsters today just don't know how easy they have it, when I was a kid we had to walk 10 miles to school in the snow whilst programming in assembly language. Kids today wouldn't know their MOV from their NOP!"

Yeah, okay grandad. Shut the fuck up, or get with the times. We don't care about how you managed to get away with writing the buggy PoS you used to that was less stable than a Syrian dictatorship and still managed to be allowed to ship it. Yes I live in awe of some of the old school programmers, and the tricks they used to pull off with assembly, but if you think they're relevant or can even benefit what 99.9999% developers need to do then it's time to retire- you're past it.

Personally I find math to be a more useful underlying skill than low level computing nowadays. Applications of things like graph theory to to write useful algorithms are far more important than being able to hand optimise in assembler.

Re:tl;dr

[xouumalperxe]

Good code is self documenting

No it's not. Good code can make it obvious how you're doing things, but it can never explain why.

Re:tl;dr

[wwphx]

On 4 year old hardware AND NOT WITH ADMINISTRATOR PRIVILEGES...

There, fixed that for you.

Re:tl;dr

[Ihmhi]

If you ask a carpenter what is "best tool" is, he might ask you "for doing what?"

My dad has actually been a carpenter for 45 years and I asked him this very question, and his answer was that at first. I added "If you had to choose one tool as the most important, what would it be?" He narrowed it down to two: a tape measure, and a pencil. "You can pound a nail with a brick or pry something apart with a stick, but without these things here everything would come out crooked."

Fashion

[funkatron]

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.

Re:Fashion

[snowgirl]

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.

I'm actually a youngin' who took interest in the lower layers, and developed my skill set around that. I'm kind of waiting for the oldies to retire/kick the bucket and open up more openings for people like me. I anticipate that I'll be one of the hawt shite programmers once the population of systems programmers starts dwindling...

Re:Fashion

[lgw]

Pretty much. There are very few comp sci programs these days that teach anything relevent to systems programming, and kernel jobs still pay nicely as a result. I stay away from the kernel stuff myself, as I find it quite tedious, but there are plenty of user-mode systems jobs around in Silly Valley - not so much elsewhere. (Stay away from embedded though, that field pays crap for some reason I've never grasped).

We're re-inventing the mainframe all over again, and that promises to be a lot of work.

Re:Fashion

[JonySuede]

You know what I use to think your way. I still remember how to write windows 98 vxd in MASM. I have hacked linux on two 486 with 16MB of RAM in 1998 to make a tunnel to play Diablo with my friends.
And you know what, I am now the senior Java architect at my place. Business software writing sucks, most of the time, but the job stability, the pay and the pension plan are way better.

Re:Fashion

[snowgirl]

You know what I use to think your way. I still remember how to write windows 98 vxd in MASM. I have hacked linux on two 486 with 16MB of RAM in 1998 to make a tunnel to play Diablo with my friends.
And you know what, I am now the senior Java architect at my place. Business software writing sucks, most of the time, but the job stability, the pay and the pension plan are way better.

I plan on the job security once I'm one of the only people who can actually do the work, lol. But yeah, I hear what you mean. I got used to writing Perl in my last job, and now I primarily think in perl first. I can still do my hardcore C, and my assembly, but I still think prototyping in perl.

Re:Fashion

[RotsiserMho]

I majored in electrical engineering with an emphasis on software. I didn't take any traditional CS classes other than a data structures class. However, we were taught all manner of practical things -- worked up from ASM to C++/Java. Saw bits flip on an o-scope. Took a class in x86 computer architecture. I taught myself best practices from well-regarded books. I'm 28 and I can say that in my position, in Central IL, embedded has been very VERY good to me. It's all people want around here and it's difficult to find decent candidates for all the open positions.

Re:Fashion

[TheRaven64]

You might take a look at compilers. Most university-level compiler courses are either dropped from the syllabus or so horribly out of date that they're irrelevant (I think UUIC may be an exception, but I can't think of anything else. The compilers stuff I learned at university was obsolete before I was born). There is currently a huge skills shortage, and a lot of interesting architectures appearing (GPUs, DSPs on SoCs) with really bad compiler support. Companies like ARM, Qualcomm, nVidia, and so on are hiring like crazy, and there's a lot of contract work floating around.

Re:Fashion

[MichaelSmith]

I'm actually a youngin' who took interest in the lower layers, and developed my skill set around that. I'm kind of waiting for the oldies to retire/kick the bucket and open up more openings for people like me.

A radar engineer I know mentioned the other day that most of the people out there doing hardware/software/tuning on radars are between 50 and 60 years old. The time to recruit the next generation is now. Its not an easy job to learn.

Re:Fashion

[darenw]

Now I know where in the country to direct my next job hunt... this is the good stuff that's been so hard to find open positions for the last few years!

Re:Fashion

[snowgirl]

You might take a look at compilers. Most university-level compiler courses are either dropped from the syllabus or so horribly out of date that they're irrelevant (I think UUIC may be an exception, but I can't think of anything else. The compilers stuff I learned at university was obsolete before I was born). There is currently a huge skills shortage, and a lot of interesting architectures appearing (GPUs, DSPs on SoCs) with really bad compiler support. Companies like ARM, Qualcomm, nVidia, and so on are hiring like crazy, and there's a lot of contract work floating around.

Well, I am already deeply into that topic as well. So... I suppose I have even more backup. Of course, I'm a bit like Larry Wall, in that all the linguistics that I know makes me develop complicated languages that grant far too much syntactic sugar than most programmers ideally would like.

those young whippersnappers

[sneakyimp]

They don't know that old trick from liblawn
Lawn::GetOffLawn(kid);

Re:those young whippersnappers

[Sarusa]

This obviously calls for a LawnFactoryFactorySingletonFactory pattern

Re:those young whippersnappers

[Desler]

I think you need an adapter included in their somewhere.

Re:those young whippersnappers

[billcopc]

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();
    }
}

Re:those young whippersnappers

[maxwell demon]

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.

Re:those young whippersnappers

[JamesP]

What?

it should be get_off(my_lawn), none of this modern 'object orientation' nonsense

or maybe

lea ax,[my_lawn]
call get_off

Re:those young whippersnappers

[MBCook]

You seem to have a small possible race condition that may cause you to need multiple Shotguns when you should only ever need one. Shouldn't Shotgun be a singleton?

Re:those young whippersnappers

[ChunderDownunder]

With operator overloading:

my_lawn - you

Re:those young whippersnappers

[Anonymous Coward]

for i in range(len(houses)):
    while not houses[i].getOwner.mad:
        houses[i].getLawn.jumpAroundAndGiggle()

Re:those young whippersnappers

[phoebus1553]

Depending on your jurisdiction and the implementation of $myShotgun->magazine, your while loop may lead to a condition where fire() fails due to insufficient resources in $myShotgun->ammo. To be proper you probably want there to be either a break (which is usually frowned upon) or another conditional on the while loop. Alternatively, or also, a call to $myShotgun->loadAmmo(); if $myShotgun->ammo == 0 wouldn't be a bad idea.

Just sayin... you need to be complete with your intentions.

Re:those young whippersnappers

[aztracker1]

I wish there was a-1 for use of PHP mod... ;)

Re:those young whippersnappers

[ibexsoftware]

Really what is the point of making something so complicated. We need to teach our programmers simple straight forward like the rest of the world.. This remind me of my writer friends, with their crazy words. Look at harry potter, it worked. Yes you can write great convoluted code (perspective) welcome to perl... I'd take a person who knew the problem and made it straight forward.... but hey what do I know

Re:those young whippersnappers

[maxwell demon]

No, you are observing the lawn, not the kids.

Re:those young whippersnappers

[TheRaven64]

That wasn't object orientation, that was just namespacing. You can kind-of do a cargo-cult version of object orientation in C++, but it's a bit painful. Oh, and object orientation comes from 1968, when Alan Kay was doing his PhD at Utah (it was the name he invented for the style of code he was writing). The first language designed for this style from the ground up was Smalltalk, which had its first pubic release in 1976 (borrowing some concepts from Simula '67). It required a machine with a 1MHz CPU and almost half a megabyte of memory to run a complete multitasking GUI system, with full introspection right down to individual pixels. So, if you think object orientation is too modern, then you probably shouldn't be allowed to use a compiler either, and you definitely shouldn't be allowed to use a GUI.

Re:those young whippersnappers

[Joce640k]

The overhead for "new Shotgun()" is immense, much better to:

$myShotgun = getShotgunFromCache();

Re:those young whippersnappers

[dzfoo]

Doesn't Object Oriented Programming mean "programming oriented toward objects"? If so, then the orientation is in the programming, not in the objects.

Whenever I hear "object orientation" it sounds to me like re-arranging furniture, which I guess is not at all what the term OOP is meant to imply.

          -dZ.

Re:those young whippersnappers

[MichaelSmith]

You are making me cry.

Re:those young whippersnappers

[MichaelSmith]

I am not sure that Shotgun is re-entrant. I am concerned that it may deadlock.

Re:those young whippersnappers

[TheRaven64]

Object orientation, according to the person who invented the term, means decomposing your program into subprograms that are simple models of (special purpose) computers, which communicate by passing messages. These simple models of computers are called objects. None of them needs to know anything about the implementation details of the others, just what messages it will respond to. In most implementations, message sending is implemented in terms of function calling (although in some, like Actor Smalltalk, it's a asynchronous).

Cargo cult object orientation is when you get obsessed by ideas like inheritance and polymorphism that happen to be implementation details of some OO languages.

Re:those young whippersnappers

[jeremyp]

Your filter on the while loop should test for live kids. As things stand, if you drop one with your first shot, such that it remains on the lawn, you will end up wasting an infinite amount of ammunition.

Re:those young whippersnappers

[dzfoo]

Hum, you didn't seem to get my point. The term "oriented" in "Object Oriented Programming" refers to the programming, not to the objects. As your comment suggests, it is a paradigm in which the programming is focused on, or oriented towards objects.

Saying "object orientation," although a common idiom, implies that the objects themselves are oriented, which is not what the term represents. My comment was that the idiom suggests the re-arranging of objects as furniture rather than the methodology of focusing on the object as the central point.

            -dZ.

The problem is

[geekoid]

they aren't trained to engineer software, and the industry hasn't incorporated good engineering practices.

Re:The problem is

[ADRA]

Coming from a legacy modernization project, just because people wrote programs 10, 20, 30 years ago doesn't mean that the code was good, or that the developers knew what they were doing. One would hope that decades of development experience would teach a well rounded set of skills and often it does.

To sum up, a 5 year out of school brat learning technology X is any less capable than a 5 year out of school brat learning technology Y in the 80's/90's.

Re:The problem is

[wrook]

There aren't good engineering practices in software. This is why I abjectly refuse to call myself an engineer (that and I'm *not* an engineer). Can you tell me with a known degree of certainty the probability that a software component will fail? What procedures would you put into place to give you that number (keeping in mind the halting problem)? What procedures would you put into place to mitigate those failures? Because I'm drawing a big gigantic blank here.

Look, I'm all for using "Software Engineering" practices. Personally, in my career I have championed TDD, peer review, acceptance tests written in advance by someone other than the programmers, etc, etc, etc. But this isn't engineering. The best I can tell anyone is, "Hey, it doesn't break on *my* machine. Yeah, I think the probability of it breaking on your machine is 'low'. No, I wouldn't like to specify a number, thank you very much." Why do you think software never comes with a warrantee?

I often wonder what we could do to actually make this an engineering discipline. For one thing, I think we really need to invest in developing stochastic testing techniques. We need to be able to characterise all the inputs a program can take and to test them automatically in a variety of different ways. But this is the stuff of research. There are some things we can do now, but it's all fairly naiscent technology. Maybe in 20 years... :-P

Re:The problem is

[Have Brain Will Rent]

Most programmers shouldn't be worrying about optimization. What they should be worrying about is not putting bugs in their code. When they get to the point where they routinely write robust clear code that doesn't do stupid things like assuming a buffer is going to be big enough for whatever string is being written to it, then they can start worrying about optimizations.

I find it really instructive to read the descriptions that come with, for example, Ubuntu automatic updates to fix security (and other) holes... it tells you a lot about the kind of errors programmers are still making.

Re:The problem is

[aztracker1]

I think without terminal (one step at a time) input/output it's harder to be deterministic in terms of state. I think that functional languages tend to have a leg up here. I do feel that the next few years will get very interesting. One trend towards the highly parallel, and others towards the higher non-blocking IO throughput. It willbe interesting to see what platforms emerge as a result.

Re:The problem is

[TheLink]

Years ago people could already look at BIND, Sendmail and other "ISC goodness" and work out the probability that they would have at least one exploitable vulnerability a year (>90%) ;). http://www.isc.org/advisories/bind?page=8

The problem is many people (bosses, project managers, developers, etc) don't understand the big difference between "Software Engineering" and say Civil Engineering.

In Civil Engineering creating all the blueprints and plastic models necessary is typically 1/10th the cost of building the "Real Thing", and make up a smaller portion of the total cost.

For software, creating the source code (drafts, blueprints) costs more than 100 times the cost of "make all" (building the "Real Thing"), and form a large portion of the total cost.

So if "stuff happens" and you need to spend 50% more to fix the design, with Civil Engineering the bosses are more likely to agree (unhappily) to "fix the design", because nobody can afford to build the whole building a few times till you get the design right...

Whereas with "Software Engineering", the bosses are more likely to go "Ship and sell it, we'll fix it in the next release!".

And if you're a boss, you'd likely do the same thing ;).

So even if you could work out the probabilities of some software component failing, nobody would care. Because all you need to work out is: which bugs need to be fixed first, out of the hundreds or thousands of bugs.

That changes if you are willing to spend 10x the cost (in $$$ and time) of creating each internal "release". By the time the 10th (final) release is written and tested (specs remaining the same - no features added) the stuff should work rather reliably. But you'd be 5 years behind everyone else...

Re:The problem is

[omglolbah]

Mostly that is not in there because the software in question is not 'critical' and nobody wants to pay for the testing.

I do work in the oil/gas industry and for ESD (emergency shutdown) systems we now have to have SIL Certified controllers and software. This means libraries have to be SIL tested and certified along with all hardware used.

http://en.wikipedia.org/wiki/Safety_Integrity_Level

Is this the kind of failure rate and safety factoring you are referring to? :)

Re:The problem is

[TheRaven64]

It's there. I had to study this stuff as an undergrad and then was in a room full of people doing it in more detail for my PhD. If you really need software that is provably correct, then you can get it. Of course, that doesn't mean any more than it does in engineering: remember Tacoma Narrows? Specifications missing an important detail can still mean a disaster, even if the engineering is perfect.

The problem is cost. Several of the people in the verification group during my PhD were working with industry (companies like Rolls Royce, who actually do require this level of software for controlling jet engines, where a small bug can mean lots of people die). After three years, they'd have produced about as much code - working in a small team - as I could produce in a weekend of hacking. The difference is that you could confidently trust your life to their code.

As with everything else, it's a question of risk / reward. If a software failure can cost $1M, then spending an extra $10M verifying it probably isn't worth it. For something like a stealth fighter, where a glitch in the flight control system can cost you a $20B aircraft, plus a tactical advantage, it is worth it. The same is true of safety critical systems in commercial aircraft and for some medical applications. For anything else, it generally isn't.

It's also worth realising how much more complex modern software is than any physical object. If you build a bridge, you have a few thousand different types of component, interacting with maybe a dozen others each. This lets you model the global effects. With software, you can easily have tens of thousands of components all potentially interacting with hundreds of others. This is one of the main reasons for the drive towards modularity in software engineering: the desire to reduce the number of possible interactions. Unfortunately, then some idiot came up with the idea of exposing threads as an abstraction above the kernel and it all fell apart.

Re:The problem is

[TheRaven64]

And, speaking as a compiler writer, most of the programmers who do worry about optimisation are really bad at it. Half of the optimisations in a modern compiler are based around removing the 'optimisations' that programmers put in and returning the code to a state where the compiler can actually make it faster.

This...

[RobbieThe1st]

would explain why Runescape runs perfectly well over dialup or EDGE(4KB/sec) speeds, while most other games do not: The original creators probably had some experience that way.

Re:This...

[loufoque]

Game development is where you see the worse code ever.

Re:This...

[kiddygrinder]

wow works ok for 5 mans over dialup, as long as you don't go near a major city...

Re:This...

[JamesP]

the worse code, yes

But that runs fast on old/not so fast hardware

Example http://en.wikipedia.org/wiki/Fast_inverse_square_root

Re:This...

[cynyr]

but yet requires 50MS latency now... Even a 10th of a second is noticeable as melee dps mainly because you will end up dead.

Re:This...

[adamofgreyskull]

"Worst", but you're probably right. It doesn't seem like one of those domains where you get to spend as long as you want to get it perfect (with a few noticeable exceptions) so it's a case of hack it 'til it works, throw it over the wall and have our customers beta test it for us.

Re:This...

[RobbieThe1st]

Well, you're not going to be PKing in P2P on EDGE, but it's perfectly good for training etc.
I recently spent several hours playing while tethered and in the car, going down I5 at 60mph(No, I wasn't driving) and it worked pretty darn well for switching towers on the fly. Not the most responsive, but no worse than satellite.

1200 bps! Our c-64 had 300 Bps

[18_Rabbit]

...and we LIKED it!

Re:1200 bps! Our c-64 had 300 Bps

[arth1]

1200/75. Because no one typed faster than 7 characters per second anyhow.

Re:1200 bps! Our c-64 had 300 Bps

[TheRaven64]

300b/s, is about 30B/s (8 bits + 2 control bits per byte). At that speed, it would take 35 minutes to completely transfer the contents of the machine's RAM over the connection. For a modern machine with 4GB of RAM, you'd need about a 16Mb/s connection to transfer the total contents of RAM in the same time. So, relative to the computer, your 300b/s connection was actually faster than my 10Mb/s broadband connection. If you do the same calculation relative to the capacity of a C-64 tape or disk and a modern hard drive, the C-64 with the 300b/s modem does even better.

You can run Contiki on a C-64 and connect it to a much faster Internet connection, but getting data faster than the machine can process it isn't that useful.

Re:1200 bps! Our c-64 had 300 Bps

[obsess5]

Teletypes were 110 baud and the old army RTTY my brother interfaced to my 128-byte MEK6800D2 computer (similar to the 6502-based KIM) was about 45 baud, IIRC. And I actually had a colleague at work scoff at me for getting the 1200 baud modem for my C-64 since 300 baud was plenty fast enough for typing.

It doesn't matter.

[man_of_mr_e]

"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.

Re:It doesn't matter.

[jackb_guppy]

I love D Knuth and have read is sorting and searching book many time over, always finding good times.

SPEED does mater and so does SIZE and BANDWIDTH. It is important to design things right the first time versus loops and loops of daily optimization that must code is written in today. The understanding of record-locks, index optimization and other multiplexing methods are needed today. I see too much of sucking a 1+ million peaces into memory to find 1 item, "Because it is fast".

Yes this sounds like "get of my grass", but "fast and sloppy", is a waste on everyone's resources not just a single computer.

Re:It doesn't matter.

[man_of_mr_e]

Those are important... *IF* they are important. Duh. Most of the time, they are not. Thus, complaining that developers who don't need to write lean apps aren't writing lean apps is kind of pointless.

Re:It doesn't matter.

[DragonWriter]

SPEED does mater and so does SIZE and BANDWIDTH.

Sometimes, one or more of those matters, and sometimes it matters enough that an otherwise correct naive implementation will not suffice, but most of the time, focussing on correctness first and optimizing only where problems become apparent is better than building for speed, size, or other performance aspects first.

And if the problem analysis has been done well, you'll know the times when speed, size, etc. have critical inflexible constraints ahead of time, and know that you have to focus on one or more of those, and which one, and what the boundaries are.

It is important to design things right the first time versus loops and loops of daily optimization that must code is written in today.

Experience has shown that, as nice as that might sound, its really not true most of the time, and in fact most systems face flux in requirements over time such that its better to build small bits that produce correct results, and adapt -- either to optimize, to add new features, or to adjust behavior to meet changing requirements -- rapidly.

Re:It doesn't matter.

[Mitchell314]

You want spend the most effort to conserve the most expensive resource. And that is not the cpu, ram, or disk time. It's human time. Hell, even working for low wage, a person is expensive. Thus the most effort should be put in having them do the least effort. Unless you have a case where the hardware time is getting expensive, but that's the exception as hardware costs go down while salary doesn't.

And no, that's not an excuse to be sloppy. "Back in the ancient days" it was important to write good code for the limited resources. Now you still need to write good code, but the constraints are relaxed. But we still need code that is maintainable, dependable, extendable, flexible, understandable, etc.

Re:It doesn't matter.

[billcopc]

Is it truly cheaper to be sloppy ? Hardware keeps getting cheaper and faster, sure, but not matching the pace at which code is getting slower.

Just look at your average web server. Today's machines are over a hundred times faster than they were 10 years ago, and we're not doing anything significantly different. Serving up text and graphics, processing forms, same old b.s. So then, why aren't we serving 100 times more pages per second ? Apache keeps getting fatter, PHP seems to do a "sleep(100)" after each line, and don't even get me started on Ruby.

There was a time, not so long ago, when I would spend an hour tweaking an oft-used assembler loop, and the end result was a 3x speedup or more. I'm not saying we should rewrite everything in assembler, but I think we're become so far removed from the actual machine, relying on the compiler to "do the right thing", that people don't even have the slighest clue how to distinguish fast code from slow. How often do we use benchmarks to test different solutions to the same problem ? Almost never! People bust out the profiler only when things go wrong, and even then they might say "just add CPU/Ram/SSD" and call it a day.

Or, if we must motivate the hippies, call it "green optimisation". Yes, faster code finishes quicker, using less power to complete the same job. If we're dealing with web servers, faster code would require less cluster nodes, or maybe free up some CPU time for another VM on the host, and those 60A circuits aren't cheap either. If spending an extra day optimizing my code could save me $2000 / mo off my colo bill, I'd be a fool not to invest that time.

Re:It doesn't matter.

[Anonymous Coward]

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.
-----------
No.

Performance problems can seriously affect software development during application testing.

Performance problems can affect batch processing operations that must complete within a time window.

Performance problems can affect the usability of desktop applications.

If these problems are not addressed early they can become unfixable. We know some practices are broken. And not doing the wrong thing very often has zero cost.

Re:It doesn't matter.

[Anonymous Coward]

The thing is people use that quote to be *LAZY*. Yeah most of the time it doesnt matter. But guess what when it does you may find yourself rebuilding an entire framework because you made just plain stupid mistakes and LOTS of them.

For someone who understands what optimizations are available vs your code jockey who just whips up some code the difference is miles different.

I used to think the same way. "It doesnt matter much" but then I realized it does matter. It matters a lot. Think if all of your programs started up 10 seconds faster. Now multiply that by the millions of times programs are run every day.

Individually on single runs it doesnt matter much. But that time debt builds up.

Think about this. Take the standard crt function printf. One of the more used functions out there. What if it ran 2x as fast. What sort of impact in the world would that make?

Re:It doesn't matter.

[Anonymous Coward]

And all those users sitting waiting 5 minutes for the page to load, for the data to completely draw, or whatever?

You do read thedailywtf.com, don't you? Plenty of stories where a 'quick app' becomes mission critical, and can't handle slightly (?) larger datasets.

Well, those aren't _our_ users.. their time is _free_. And they can _leave_ if they don't like it. ....

Re:It doesn't matter.

[antifoidulus]

It all comes down to scale ultimately. It's rare in the computer science field to see code that runs x% slower than a more optimized version, at both very small and very large scales. Coders that don't know how the hardware and lower level software interfaces work tend not to write very scalable code because they have no ideas how the computers actually work, and even less of an idea of how a lot of them work.

As an example, consider a database with very poorly designed primary and secondary keys. This choice will either:

a) not matter in the least because the tables are so small and queries so infrequent that the other latencies(e.g network, hard disk etc) will dwarf the poor key choice or

b) Will quickly make the entire database unusable as the time it takes for the database software to search through every record for things matching the given query takes forever and just kills the disk.

I've seen plenty of (b), largely caused by total ignorance of how databases, and the hard disks they live on, work. The indices are there not only for data modeling purposes, but also to minimize the amount of uber expensive disk I/O necessary to perform most queries. And while you may be in situation (a) today, if your product is worth a damn it may very well get bigger and bigger until you end up in (b), and by the time you are in (b) it may end up being very, very expensive to re-write the application to fix the performance issues(if they can be fixed without a total re-write)

Anyone who codes should have at least a fundamental grasp of computer architecture, and realize what computer hardware is good, and bad at. That isn't "premature optimization" as you seem to think it is, it is a fundamental part of software design. "Premature optimization" in this context means things like changing your code to avoid an extra integer comparison or two, that kind of thing. It is not,"lets just pretend the computer is a magic device and ignore performance concerns because it's easier".

Re:It doesn't matter.

[maxwell demon]

You seem to have this mental model that more efficient code must take longer to develop. But not making bad decisions may take up exactly zero time if you are in the habit of making good decisions.

A simple example is the ordering of loops. Exchanging the order of loops after the fact may take extra time, but writing the loops in the right order from the start doesn't take more time than writing them in the wrong order.

Re:It doesn't matter.

[Mitchell314]

You seem to have this mental model that more efficient code must take longer to develop.

I did not say, claim, or imply that. I was talking about factoring in developer time as a resource.

Re:It doesn't matter.

[Mitchell314]

I do read it, and my last statements in both paragraphs was to address that issue.

Re:It doesn't matter.

[tombeard]

So to save one developer day we sacrifice 5 user minutes per day X 250 days per year X 100000 users? I know I have been the victim of this.

Re:It doesn't matter.

[Have Brain Will Rent]

Such things are expensive, and in the long run it's cheaper to be fast and sloppy than slow and lean.

I bet you meant to say something else because it never pays to be sloppy in designing, coding or testing software. Never.

As far as the Knuth quote he is talking about intermediate and low level optimization - optimizations at the language level - I am sure he did not intend his net to catch optimizations like choosing the appropriate algorithm to solve the general problem at hand.

As far as intermediate and low level optimizations this is one of the benefits of experience - you learn to recognize situations where putting some extra work into a particular piece of code will have a pay-off, by whatever metric is relevant, big enough to justify the effort.

Re:It doesn't matter.

[RDW]

"We should forget about small efficiencies, say about 97% of the time".

But be sure to remember and apply them aggressively the other INT PI % of the time:

http://heavenly-dorks.livejournal.com/845375.html

Re:It doesn't matter.

[Darinbob]

But some times it does matter. And I have seen many many times when it does matter and the software team doesn't recognize that fact and ends up with something not quite good enough.

Re:It doesn't matter.

[Anonymous Coward]

Nobody is suggesting you optimise to shave off the odd byte or machine cycle.

However, you should optimise for the task in the sense of picking appropriate algorithms and structures.

What I've seen in industry is that a lot of developers pay attention neither to elegance nor efficiency. And this really bites you in the pants when the code meets real data.

Anyway, once you decide to ignore resource constraints in your engineering, what on earth is left that's challenging? Honestly, you might as well flip burgers for a living if you're going to do things that way.

Re:It doesn't matter.

[Capt. Skinny]

Software is written once, but it is executed many times. Spend the extra money on up-front costs (people) and you'll save on recurring costs down the line.

Re:It doesn't matter.

[greenbird]

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.

You have GOT to be in management. The vast majority of the cost of a software project go into the support. If it cost twice as much to do it right up front you will save 10 times that amount in support cost down the road. You can then spend that money evolving and improving your software rather than being forced to spend it trying to keep it going day to day. Attitudes like your's are the number one thing wrong with the software industry (well, besides software patients but that's another argument).

Re:It doesn't matter.

[Just Some Guy]

Or, if we must motivate the hippies, call it "green optimisation". Yes, faster code finishes quicker, using less power to complete the same job.

If I write an inefficient process that causes the CPU to dissipate an extra 10W 24/7, the additional local cost for that electricity would run about $0.60 per month. That works out to approximately 50 seconds salary. While Google-scale operations would probably consider that a worthwhile expenditure, for most small companies it'd be much cheaper (and a lot greener!) to not spend the programmer time to improve it.

Also consider that my desktop, extra monitor, office lights, and office air conditioning add up to a lot more than 10W. I like to eat sometimes, too, and I have to get back and forth to work somehow. It might not be green at all to invest more energy into the optimization process than we'd ever recoup.

If spending an extra day optimizing my code could save me $2000 / mo off my colo bill, I'd be a fool not to invest that time.

Maybe, unless the opportunity cost of deploying your application runs to more than $2,000/day. And will it cost more to maintain your optimized code than the (presumably) more straightforward equivalent?

Re:It doesn't matter.

[Vellmont]

Today's machines are over a hundred times faster than they were 10 years ago

The raw CPU power times the amount of cores is 100 times faster. How much faster is the I/O? Serving up web pages is mostly about I/O. I/O from the memory, I/O from the database, I/O to the end user. The CPU is usually a small part of it.

You actually sound like a perfect example of what the article is talking about. People who don't understand where the bottlenecks lie. Hell, it even mentioned the misunderstanding of the I/O bottlneck that exists today.

Re:It doesn't matter.

[lgw]

As a consequence, Efficient code makes little sense when writing one-off, or internal projects for small audiences in the consulting world, and a lot of sense when writing for 100k or 1MM customers in the shrink-wrap world.

Re:It doesn't matter.

[lgw]

I disagree a bit. You have to avoid terrible pitfals in the basic architecture, sure, because that's hard to change later. But for most day-to-day coding choices, it's better to write everything in whatever way is the simplest and most maintainable, and only com back later to optimize proven hot spots.

But as you say, it comes down to scale, and scalability and performance are different (and sometimes conflicting) goals.

Re:It doesn't matter.

[Just Some Guy]

The indices are there not only for data modeling purposes, but also to minimize the amount of uber expensive disk I/O necessary to perform most queries.

For historical reasons, one of our largest tables stores a person's name as "Last, First" instead of using separate fields. I wrote a PostgreSQL functional index like UPPER(SUBSTR(name,1,STRPOS(name,','))). According to "explain analyze", that reduced searching for the last name "Smith" from 1628ms to 79ms.

I know the importance of indexes isn't your main point, but I felt the need to brag.

Re:It doesn't matter.

[ausrob]

..and that's the attitude for failure after success. I understand what you're trying to say, but a general adherence to "be fast and sloppy" means a tonne of rewrite (most likely) if the product, service or web site ever became popular. Depending on the nature of the software, there needs to be some level of consideration for efficiency - what I take away from the OP's post is that modern technologies, hardware and architecture abstract the responsibility away from those who are practitioner of it.

Re:It doesn't matter.

[Kylon99]

"premature optimization is the root of all evil"

This is the quote and the relevant word is 'premature.' No one is arguing that we should never optimize. The problem is if we optimize thinking that 'we know best.' It's as if somehow, magically, we know where the slowdowns are without doing actual performance monitoring. "It's a O(n^3) loop, so it must be bad."

Optimizations frequently cause the code to be less maintainable. Optimizations can also take time to implement and document. Also, optimizations are only important in areas that we care about. If an optimization makes code run 5 milliseconds faster in an area where we don't mind waiting 10 seconds, then that optimization is not useful.

An O(n^3) loop is perfectly fine if: 1. it performs fast enough and... 2. it's allows for speed of implementation and code readability. However, if you perform an analysis and find that it is sucking up a bunch of time, then by all means, improve it.

But not until you've got the results of that analysis. And not a 'hunch.'

Optimizaion: Your Worst Enemy
http://www.flounder.com/optimization.htm
Joseph M. Newcomer

Re:It doesn't matter.

[drooling-dog]

Is it truly cheaper to be sloppy ?

It is, but only in the sense that cheaper, inexperienced coders are more likely to do it that way out of the box. But it's a mistake to assume that the software engineer who knows better is facing a tradeoff betwwen good (or reasonable) design and expeditious implementation. If you're good, you can deliver both.

Re:It doesn't matter.

[Weegee_101]

"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.

Do you even know what the full quote is, or what the paper Donald Knuth wrote that in is about?

Here is the full quote:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified." - Donald Knuth

So the quote you've used to back yourself up is completely and utterly against your argument. It actually makes a point for the skills that you say don't matter. I really can't even believe people modded this as insightful.....

Re:It doesn't matter.

[Amigan]

It all comes down to scale ultimately. It's rare in the computer science field to see code that runs x% slower than a more optimized version, at both very small and very large scales. Coders that don't know how the hardware and lower level software interfaces work tend not to write very scalable code because they have no ideas how the computers actually work, and even less of an idea of how a lot of them work.

I work in the HPC field where codes are constantly being ported from one OS/hw to another - it could be the same OS on different hw or a different OS on the same hw. Of course the weirdest port is when it's to a completely different OS and hw combination. Optimization in my case is efficient memory utilization along with fast performance - made even harder by hw constraints (32 bit v 64 bit) or the lack of Virtual Memory support in the OS - which constrains the application to the physical memory. Squeezing every "ounce" of performance is mission critical to the HPC application. Getting the right answer seconds/minutes/hours later than another platform makes slower platform non-competative. Hand optimization of certain codes may be able to get the "lost" performance back - but without understanding that compilers don't always generate the best code, and that scientists writing the code are generally not CompSci folks means that making an application run faster/better/more efficiently is generally possible, if the extra effort is applied.

Re:It doesn't matter.

[Teckla]

Today's machines are over a hundred times faster than they were 10 years ago

Wow, how did you overclock your CPU to 100 GHz?

Re:It doesn't matter.

[PBPanther]

I agree. The most important thing for code now is to be maintainable, and that means easy to read and understand. Also tests are important to take keep it from breaking. While it is good practice to write code that is not wasteful of resources, this is something that can be improved after the code and tests are written.

Re:It doesn't matter.

[arth1]

Think about this. Take the standard crt function printf. One of the more used functions out there. What if it ran 2x as fast. What sort of impact in the world would that make?

The best way to speed it up is to not use it.
In my estimate, a good portion of all printf() statements you see in typical code could be replaced with puts() or fputs().

Re:It doesn't matter.

[man_of_mr_e]

First, you're assuming that if the user finishes their job faster, they will be more productive. Chances are, they'll just spend that extra millisecond texting someone or posting to facebook.

What you're suggesting is the equivelent of claiming 9 women can make a baby in 1 month. Your logic is severely flawed.

Re:It doesn't matter.

[man_of_mr_e]

Dude.

If optimizing does actually save significant time and resources, then it should be done. But 97% of the time (Knuth's made up statistic) is that those optimizations don't matter, so doing them is a waste of time. You should be concentrating on the 3% where it does matter.

Re:It doesn't matter.

[man_of_mr_e]

The key word in your sentences is "can". As in, "in some cases". And in those cases, optimization is important because it's important to meet the requirements. There is nothing wrong with optimizing code that needs it in order to meet requirements. The problem is the 97% of the rest of the code that doesn't need to be optimized to meet the requirements, but programmers want to spend all their time on making it "perfect".

Re:It doesn't matter.

[man_of_mr_e]

The difference between a list and dictionary is huge, and both have situations where they are the right and wrong system to use. However, they can both do the same thing, and if you choose a dictionary instead of a list when a list is the better choice.. it won't matter if you only have 10 elements in it that are accessed infrequently.

So the choice of which algorithm falls down to "whatever works within the requirements", not "what is the most efficient".

Re:It doesn't matter.

[man_of_mr_e]

Not all apps need maintenance, or much of it anyways.

So let's say you spend 2x longer building the app, but there is never any maintenance done on it. You are now out 50% of the money you spent on it. What's worse, you may not even be in business because your competitor shipped 6 months before you did and cornered the market.

Re:It doesn't matter.

[man_of_mr_e]

I fail to understand your logic. My argument wasn't that all code should be slopily written. It's that writing "elegant" or "optimized" code does not need to be written for the vast majority of applications. Hell, it doesn't even have to be good code most of the time.

Knuth is exactly right. In that 3% case, it is critical to make the code the best it can be, but most of the time doing so is a waste of money.

Re:It doesn't matter.

[aztracker1]

Honestly, I agree to an extent, but there is a need for a deeper understanding. I'm more than happy to use generics or other higher language conventions, hell, I like JavaScript of all things... The flip side is, I see more poor performance issues because of lack of understanding as well as errant behavior because of misuse of static resources than I care to look back on.

I was working on the start of a multi-simulation engine meant to run server-side. The in-place developers were gearing towards each avatar having it's own thread... okay, now take 1000+ avatar processes per simulation (1 sim per user) for a thousand or so users, and see how well that works. The constraint here wouldn't be memory usage, but the swapping of resources for a million+ threads. Let alone the IO to data storage, and the interaction messages.

Understanding your platform, a bit of history and some lower level knowledge is very important to making better decisions to start with. Which isn't the same as premature optimization.

Re:It doesn't matter.

[mcrbids]

Hell, even working for low wage, a person is expensive. Thus the most effort should be put in having them do the least effort.

Yeah, but here's where it gets weird: Software is highly valuable because it allows a single person to do the same task a very large number of times.

Because of this, it's not like stacking logs or gluing tile. If you have sufficient leverage, you can spend a stupid amount of money getting everything just right and profit immensely from it. (See: Apple)

On the other hand, most software isn't leveraged nearly as much. Most software is "commodity" and doesn't represent a huge leverage of anybody's skill. And that's why, in some environments, egging out the last ms of performance out of an algorithm is critical, and in others it's a total waste of money.

The important part is to determine just how important the possible performance increase actually might be.

Re:It doesn't matter.

[aztracker1]

This is why I've been following NodeJS with great interest...

Re:It doesn't matter.

[major_fault]

In a way I find this kind of view contradictory. I agree that it is human time that is most expensive. Therefore computers should work as fast as possible to limit the time that people need to wait on them. Naturally it is questionable whether the time of the developer is more expensive or the time of millions of users. Especially since economically for a company the time of users does not cost almost nothing even if it sums up to millions of hours of wasted time each day. On the other hand, software might save millions of hours as well, if shipped earlier. So technically it would be incredibly great if it would be identifiable early, which case is it: Does earlier shipping give more return than savings of user time during software lifetime? Or is it possible to determine it at all?

Re:It doesn't matter.

[omglolbah]

Sadly the person signing the developer's time-sheet isnt usually the one incurring the cost down the line...

That kind of disconnect makes for shitty code and shitty efficiency overall :(

Re:It doesn't matter.

[TheRaven64]

You might want to look at the assembly your compiler generates. There is absolutely no speedup from doing this replacement if you are using a modern compiler, because the compiler will already be replacing all printf() calls with constant arguments with puts (or even putchar()). If you're interested, then look at LLVM's simplify libcalls pass. Search for printf in that file and you'll see the transforms it does there. It also simplifies a number of other libcalls. This means that it's fine to use [f]printf() everywhere - the compiler will transform it into puts(), putchar(), putc(), or fwrite() in cases where that is appropriate. Pretty much any modern compiler will do this. The behaviour of these functions is specified by the standard, so it's a safe replacement.

Re:It doesn't matter.

[strikethree]

You want spend the most effort to conserve the most expensive resource. And that is not the cpu, ram, or disk time. It's human time.

You are absolutely correct... however, it seems you are thinking of the wrong human here: The Programmer.

The Programmer's time is wasted once in writing and optimizing the code. The User's time is wasted each time that The User uses the program... but, it is even worse than that: There is typically more than one User... so multiply all of the time wasted for one User by the total number of Users. Now, let's compare that time (time == money) that was used by the Programmer vs the time that was used by the Users. Where is the majority of the money wasted?

But yes, you are absolutely correct: It is human time that is the most expensive.

Regards,
strike
(CAPTCHA is subsidy, ROFL)

Re:It doesn't matter.

[Joce640k]

...and the answer was that code which is 90% efficient doesn't take any longer to write, it just takes experience.

Code written by fresh-out-of-college-and-heads-full-of-latest-programming-fashions is only going to be 50% efficient (and far more likely to end up on the daily WTF).

(Numbers pull out of my ass but you get the picture...)

Re:It doesn't matter.

[Joce640k]

Sadly, if you have competition they can take your business if spend that bit extra on development to make their application feel more snappy than yours.

Re:It doesn't matter.

[Joce640k]

You're assuming you can't have both.

You can.

Re:It doesn't matter.

[Joce640k]

Bad initial design can bog down a program forever, no matter how well you optimize the inner loops.

Re:It doesn't matter.

[bug1]

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - Donald Knuth

But was he referring to designing software, or writing the code for the design ?

Very very hard to waste time at the design phase, much easier to waste time on the implementation.

Re:It doesn't matter.

[dzfoo]

That's not the point. The complaint is not that modern developers are not writing lean apps. The complaint is that modern developers are not instructed or experienced in lean development at all, and so they cannot learn from the lessons of the past.

What's more, the problem is compounded by their cockiness in stating things like, "those are obsolete techniques, they are all old timers, there is absolutely nothing of value that can be learned from them or their programs from 20 years ago." So they will not learn from the lessons of the past.

This results in the state of the (so called) art: lots of databases, applications, and web sites without security, large amounts of glue-code, and badly conceived infrastructure because someone decided that a particular service that works exceptionally well in a known and established environment, say, needs to be tunneled through HTTP and implemented in JavaScript.

But not only do they re-invent the wheel in JavaScript, they come up with a slightly oval wheel--can't pay attention to all those old wheels, they're obsolete, and absolutely irrelevant!. But it's OK because you just need to push it harder to run smoothly, so they just add an industrial power plant to it. It's all well, power plants are cheap nowadays.

Eventually, they all hit the same problems and have to deal with similar constraints, yet there is no memory of the past lessons.

That's the problem, and that's the complaint. It is not that people ignore what's irrelevant from the past, it is that people are ignoring the past wholesale with a misguided view that everything old must be irrelevant by definition.

          -dZ.

Re:It doesn't matter.

[MichaelSmith]

Bad initial design can bog down a program forever, no matter how well you optimize the inner loops.

And once you sell it you get a endless stream of revenue for maintenance.

Re:It doesn't matter.

[mortonda]

SPEED does mater and so does SIZE and BANDWIDTH

Yes, but they have trade-offs. Also included in there is development time. Unless you have actually measured the various part, you aren't ready to optimize, as you don't even know what needs attention. If you read stack overflow, it seems like like every week there's a variation on "Which is faster, .... or ....." Well, measure it! And they do... in a simple little test program that has no basis in a real world situation. So what if a billion iterations come out 5ms faster?

OTOH, you *do* need to know how to spot O() problems in code, and how to profile code to see where the real bottlenecks are.

(aside ... how stupid is it that to change my posting options, it reloads the page and loses what I've typed?)

Re:It doesn't matter.

[man_of_mr_e]

Why are you repeating yourself? Apparently, you didn't read what I said and made some other assumption.

That milisecond shaved off for one user is irrelevant because it can't be combined with other users in any meaningful way. It will likely be swallowed up by the users day to day activities and not returned to the universe. Like I said, you're suggesting that 9 women can make a baby in 1 month. Or in your case, a million users can make some statistically signifant productivity boost.

You're using math wrong. Just like the baby example.

Let's put this another way. Let's say it takes 5 seconds to start an app, and through lots of hard work you figure out a way to make that 4 seconds. Using your math, that would give years of productivity back to the world. Except no, it doesn't. When an app starts, most users don't instantly start doing work the nanosecond the app starts loading.

People, being people, have reaction times and they often do things like pause to consider what work they want to do. So, if the user pauses for 10 seconds after they've started the app, then all that means is that the app will be idle for an extra second before the user starts doing something. The user will pause 10 seconds regardless of whether the app loaded in 4 seconds or 5.

Most apps just don't benefit linearly from random optimization, and doing so just wastes time and money.

Re:It doesn't matter.

[man_of_mr_e]

Oh, it's VERY easy to waste time at the design phase. Haven't you ever heard of Analysis Paralysis? It's where you keep changing your mind and trying to design it better, and never quite seem to make it into production of the code.

Re:It doesn't matter.

[Terrasque]

Hey, birdie, sometimes optimisation and maintainability / stability are two opposite things.

More optimised in many cases also means less readable, and sometimes using unreliable "shortcuts" (What do you mean, $special_data_type / $special_api works differently on 64bit / windows_special_edition / $different_locale ?).

Also, less readable code in itself increase the chance of bugs popping up.

Re:It doesn't matter.

[warpuck]

On the i386/i486 I changed the mobo crystal to overclock the cpu.

Re:It doesn't matter.

[man_of_mr_e]

While i'm not disagreeing with you, I think it's a lot more complex than that. If you're talking commands in an app, then certainly there are times where effectively instant actions are beneficial, but when moving from app to app most people take a few moments to readjust themselves to a different UI and figure out how they're going to go about doing their task.

Let me give you an example. A company I worked at was complaining that their terminal based app (running on a Unix system) was too slow, and that it took too long after finishing a screen before they could move on to the next screen.

The company spent about $30,000 in hardware and software changes to get the screen take "near instant" time, and they found that the workers were no more productive. They did exactly the same amount of work in exactly the same amount of time.

The reason was that after they entered a screen, they had to shift their paperwork and move to the next folder of data. By the time they did that, the screen was finished updating and ready for the next work item. So in other words, wasted money.

Re:It doesn't matter.

[bug1]

Hmm, ive certainly done a lot of "Analysis Paralysis", but i dont see it as a complete waste of time.

During analysis, even if you feel you are getting nowhere, you are usually still defining the problem better, even if its only in your own head. It is much hard to measure progress during analysis, perhaps a lot of cases of paralysis are misdiagnosed.

I would be very concerned about following someone who had the opposite of "Analysis Paralysis", who came out with a design in quick time. I would be asking if they really understand the problem.

With design, you never completely start from scratch if you keep the same team. With code you can end up starting from scratch, but you can replace the team.

Re:It doesn't matter.

[hoyle]

I keep hearing this quoted over and over and while it's true, it misses the point. He wasn't talking about fast and sloppy vs. slow and lean. He was talking about correct and efficient vs. correct and inefficient. Broken code doesn't enter the picture. You can't optimize something that is broken, you can only optimize something that isn't working as well as it should be.

So, stop quoting that line and fix your stupid code. When it works, we can decide if it needs to be optimized further or not.

Re:It doesn't matter.

[benhattman]

I always felt people misunderstood this quote. Actually, I've had times where I suggested something be done way X instead of way Y because of 5 different reasons and only one of those was efficiency of execution. The other developers would literally respond, "oh well I'm not ready to optimize this yet". And I felt like screaming, "it's not optimizing if the other design is also safer, uses less code, and provides a cleaner interface!?!?!?!?!"

What people seem to miss is that there is a level of optimization that is appropriate at early phases of a project and then there are things that should be pushed off until/unless absolutely necessary. Writing a tight loop in assembly? Hold off. Modifying loops for compiler specific gains? Not unless it must be done. Notice you're doing some IO and it's taking significantly longer than it seems like it ought to? That I would investigate immediately and try to determine if a simple algorithm change (like using a better IO library or choosing a better buffer size) can make a large difference.

Re:It doesn't matter.

[billcopc]

You're right, 10 watts is pennies, but in my experience the inefficiencies are several orders of magnitude greater than that.

One example I encountered last week, involved an accounting tool that queried an entire table, created deep entities for each record, and then performed various trivial sums and sorts on the entire dataset. It ran "well enough" for years, until I added this one client whose member list is about twenty times larger than all the others. Then it didn't work at all, ate up all available memory (48 gigabytes!) and died, because it was using O(n^2) memory and time. So I very easily rewrote it with a simple iterator, such that it uses O(1) memory and runs in O(n) time. So even those "well enough" clients saw a tremendous speedup, and as a result I was able to shut off all but two reporting servers. The original programmer chose the wrong method to traverse the data, probably built the whole thing in half a day without much thought, and for years this company kept throwing more hardware at it. Since they like HP, we're looking at about 60k worth of servers invalidated by about ten minutes of my time, including testing! The power savings pale in comparison to the hardware itself, and by the time they grow again, this gear will be a few years old and largely obsolete.

This low-hanging fruit is pervasive in the enterprise I.T. world. The same client had a $15k MySQL server that was barely delivering 50 queries per second. So they bought five more and set up a master/slave cluster to spread out the reads. Then when the company grew, they kept adding more slave nodes. I logged into one box, noticed it was using 128mb of the 24gb installed, so I tweaked the config to match the hardware, and threw in a shell script ot "preheat" the cache. Surprise, now one box handles 1500 QPS, with plenty of headroom. The (former) network guy thought it was normal performance, that their critical business app was just heavy. Perhaps if he had some concept of how fast the servers "should" have been working, he might have thought to investigate the slowness. Perhaps he didn't even know there was room for improvement. This is the point I'm trying to make, a lot of coders and sysadmins today don't even know what is possible, so how can they possibly know where and when to look for easy optimisations ?

Re:It doesn't matter.

[Arterion]

A minor concern might also be wasted cycles in terms of power consumption. It may not seem like much, but if your software is going to be used by a lot of people, and it needlessly churns the processor, it could add up over time to electricity costs that are not negligible, and could justify some optimization.

Re:It doesn't matter.

[black soap]

I know programmers (retired now) who optimised to shave off the odd byte or machine cycle. They worked for the IRS. Apparently when you apply the same operation to to every tax return, those fractions of a second start to add up to real time, and the IRS didn't want to waste computer time.

Learn the basics

[countertrolling]

It's just like pilots should learn how to fly before being put at the helm of an airliner.

What Today's Humans Don't Know and Why It Matters

[Anonymous Coward]

Today's humans have much more advanced technologies and more forgiving world to play in — but it seems many have forgotten some of the lessons their predecessors picked up in a more resource-constrained era. Newer humans are less adept at identifying water sources in a forest, finding directions without a GPS, and low-level skills like starting a fire with two stones. You never know when a seemingly obsolete skill will come in handy. For instance, stone age humans who cut their teeth in the days of, well, stone age have a leg up in hunting wild beasts with just bare hands and stones.

Hi, my name is Bob!

[tulcod]

I am an electrical engineer. Here's some news for ya: us electrical engineers do learn these skills, so don't bother complaining about the state of the world because new students are taught these vital insights in computing every day.

Maybe having a conservative mindset helps..

[JeremyMorgan]

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.

Re:Maybe having a conservative mindset helps..

[loufoque]

Whats the cost/benefit to learning and mastering assembly if you aren't going to need it?

Less people master it, therefore it is more rewarding, both intellectually and financially.

Would you rather be a replaceable coding monkey, doing what anyone else could do, or be an expert software architect that your company relies on?

Re:Maybe having a conservative mindset helps..

[cheekyjohnson]

Well, first of all, that would depend on whether or not the company that you work at even needs someone with those skills to begin with. I'm sure there are many instances where the company you work at simply doesn't need them. Anyway, your point is moot if everyone starts taking your advice.

intellectually

Some people simply don't believe that trying to understand things that are useless to them is a worthwhile endeavor.

Re:Maybe having a conservative mindset helps..

[lgw]

Some people simply don't believe that trying to understand things that are useless to them is a worthwhile endeavor.

Very true. The opposite of that mindset is "intellectual curiosity", which seems to benefit mankind if a few (but not too many) are so afflicted.

awful article

[roman_mir]

well that was a waste of time, a terrible incoherent, lazily written article with very little anybody could actually use if they wanted to learn something if they cared to find out what it was they 'lost'. There are so many things that people have to deal with in projects today, that having to deal with limitations that are artificially imposed by ideology, which insists doing things the old way... it's just nonsense.

Why not then say everything should be done with a hard limit of 5MB hard drives or better yet, with throughput of punch cards?

If the author wanted to say something useful, he failed.

Sounds of failure, the zen way

[rippeltippel]

What is the sound of a pointer dereferencing to NULL?

Re:Sounds of failure, the zen way

[maxwell demon]

What is the sound of a pointer dereferencing to NULL?

I'm sure you mean dereferencing a null pointer. A pointer dereferencing to NULL would be a pointer pointing to a null pointer.

Re:Sounds of failure, the zen way

[Obfuscant]

A pointer dereferencing to NULL would be a pointer pointing to a null pointer.

That would be "a pointer dereferencing to a NULL pointer". A "pointer dereferencing to NULL" would be a pointer to a NULL value.

I learned 68000 and VAX assembly code when I learned C. The best way to learn what a C statement is actually doing (with all those & and * and [] and stuff) is to have the compiler dump the assembly and look at it. It's also a good way to see what optimizations the compiler is trying to do.

I have a feeling the main best use for people who know how hardware acts these days are 1) high performance computing specialists who need to worry about cache hits and row vs. column-wise data access, and 2) people porting an app from a large-capacity system to a low capacity one.

Yes, human time is important, but a software system that needs to keep up with realtime but it can't because the programming is sloppy is not worth much, and the savings of being able to use a smaller cheaper processor in 1,000,000 units of a consumer device can make up for it.

Re:Sounds of failure, the zen way

[maxwell demon]

A pointer dereferencing to NULL would be a pointer pointing to a null pointer.

That would be "a pointer dereferencing to a NULL pointer". A "pointer dereferencing to NULL" would be a pointer to a NULL value.

Since NULL is a pointer value, the only thing which can have this value is a pointer (and please, no nitpicking about null pointer constants being int; that's an artefact of the definition of C and C++; you wouldn't use NULL anywhere but in a pointer context). Therefore anything which dereferences to NULL must dereference to a pointer value, and thus to a null pointer.

Or to say in in code:

if (p == NULL)
  printf("p is NULL\n");
else if (*p == NULL)
  printf("p dereferences to NULL\n");
else
  printf("p neither is nor dereferences to NULL\n");

Good link

[ustolemyname]

Link in the summary is to the print page. Thanks jfruhlinger!

Stone Carving Skills

[paulsnx2]

I remember when bits were made of actual stone, hand crafted, and strung by hand into computational frames. Today's kids don't even understand that this is what we are referring to when we talk about "Frame Works" today. Those Frames were tons of work, let me tell you.

Computational systems used these frames so that sometimes you had to go through several of them to get to your goal (These were the early AND gates), and other times you allowed users to pick which one to pass through (OR gates). When you forced people into exclusive choices (such as gates to bathrooms) these frames were referred to as exclusive gates (use this one if male OR use this wone if female, or XOR gates).

We used simple trip wires in our frame works to implement inverters, Very effective at reducing time wasted with managers. (Generally once a manager has been inverted a few times, they leave you mostly alone.)

Knot gates were generally frameworks made from pine.

I could go on about heat sinks (Hot rocks used to warm water) and other early computational technologies. But all of this is lost on this young crowd who don't even remember Java used to be drunk black for a nickle.

Re:Stone Carving Skills

[garyebickford]

Oblig.: A Bunch of Rocks. :D

Re:Stone Carving Skills

[shagie]

So you've seen the great computer at Apraphul? I remember when that article came out and wished I could go see it too.

Lessons from the Old and Wise

[AirStyle]

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.

Re:Lessons from the Old and Wise

[garyebickford]

Or go the other way - toward Church instead of Turing - check out Erlang or Haskell or Ocaml. In fact I recommend learning at least one of the above (I personally like Erlang, but that's just me) just to get a different perspective on computation than any of the 'classic' imperative, memory-location-oriented languages.

Re:Lessons from the Old and Wise

[chthon]

Perl is nice, I program whole days in Perl, but my real productivity boost (with Perl) came from this book.

If you have finished it, you will never look in the same way at programming.

After you have finished it, you should be able to start with this book, which will still give you a deeper insight. Make the exercises, try especially to grasp the parts about writing a Scheme interpreter and the register machines.

IDE debugging really isn't that bad

[jader3rd]

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.

Re:IDE debugging really isn't that bad

[coolmadsi]

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.

Oooh, I remember printing out debug statements. When I was at Uni.

Tried doing it once while working on a massive program when I got a job after Uni, it was near useless due to the scale of the system. Figured out how to use a decent debugger properly (we might have been taught how to use a basic one at Uni) and haven't looked back.

Recently found out with the debugger I am using that I can change variable values mid execution - can't do that with print statements. You're right - modern debuggers are great.

Re:IDE debugging really isn't that bad

[DeadCatX2]

Not only can you change variables during execution, you can manually move the execution pointer around, you can recover from unhandled exceptions, and you can edit the source code during a breakpoint and then continue without having to restart your application.

You can also still direct things to the Output window in the IDE if you fancy the printf style statements.

Re:IDE debugging really isn't that bad

[maxwell demon]

No, they didn't complain about modern day programmers using an IDE or debugger. They complained about modern day programmers being lost without them.

Re:IDE debugging really isn't that bad

[wrook]

I didn't read TFA, but here are some thoughts to consider. printf debugging is only useful if you have an uncomplicated subsystem. You have to be able to quickly find the area where the problem may lie. You have to be able to easily identify and set up the scenario that is causing the problem. You have to easily be able to modify the code, redeploy and run it. I find that a lot of people will say, "My system is too complex for that". What they don't quite grasp is that their system is broken.

If you need a debugger to evaluate the system when it enters a broken state, your software composition is likely the fault. You should be able to write a quick script that sets up the circumstance that you are interested in. If you have to actually run the entire software to get into this situation, they you likely have serious coupling issues that you should resolve.

The same is true for tracing. Generally tracing is useful when you can't understand the code path that led to it arriving at a particular location. This probably means that either your interfaces are confusing, or you have poor cohesion. You may have issues where functions are doing more than one task, or you have many poorly factored methods that copy and paste similar code.

For me one of the biggest incentives to use a debugger is because the build system is broken. I can't set up scenarios to test because it takes an hour to build and deploy the system. Again, this could be due to coupling/cohesion problems in the software composition, but it is often just laziness when creating the build system. Having a continuous integration/build system is extremely helpful.

When you are working with a legacy system, sometimes there isn't much you can do. The pooch was screwed years ago and apart from rewriting the whole damn thing, you just aren't going to get there from here. The problem comes when the programmers don't even realise the inherent problems in their system. They have 2 million lines of horribly organised libraries and code copy and pasted all over the place. They have 200 line long (or more!) methods that duplicate functionality from a hundred other 200 line long methods. The debugger lets them do this and stay sane.

Taking away the debugger and telling them to use printfs (with no tracing subsystem!) shows them the hell that they have created. Of course, even then they often don't take the hint...

Re:IDE debugging really isn't that bad

[pinkushun]

Its not bad at all, it feels however that modern IDE debugging is pushing away too much from the manual approach to trace down a bug.

It would have been better if modern debugging methods complimented the manual method, and not try push it out of the scene.

Most of the points in TFA relates back to the new debugging methods to "inspire new trends".

In my day

[alostpacket]

we had to code uphill in 10 feet of snow on an abacus using roman numerals.

Re:In my day

[sconeu]

You had Roman numerals? You lucky, jammy, bastard! I'd have killed for Roman numerals. We had to use tally marks. And if we didn't put the slash to mark the fifth, the compiler got confused and core dumped on us!

Re:In my day

[maxwell demon]

we had to code uphill in 10 feet of snow on an abacus using roman numerals.

You had an abacus and roman numerals? Luxury! We had to use heaps of stones for our programming. And we liked it!

Re:In my day

[tool462]

Roman numerals? Then how did you terminate your strings?!

Re:In my day

[Darinbob]

Strings were terminated with extreme prejudice.

Re:In my day

[PBPanther]

Now hex values in roman numerals would be impressive: ..., VIII, VIV, VV, ...

Re:In my day

[PBPanther]

VVI, VVII, VVIII,

Re:In my day

[PBPanther]

VVIV, VVV, VVVI

Re:In my day

[Joey Vegetables]

Core dumps?? Whipper-snapper. In my day, they just exploded. We had to bring in TSA officials to analyze the debris patterns just to figure out what went wrong.

old wives' tale

[fertilizerspike]

This pops up every few months really, somebody goes on and on about how much harder it was to program "back then", and that programmers who have been programming longer are better programmers. Duh! It's called experience, it has nothing to do with how "easy the kids have it these days". How does this stuff get to the front page when my story about the Columbia being destroyed by the Starfire Optical Range was completely swept under the rug. Ditto to my story about Giffords' partial brain transplant into the nine-year-old clone of her, the young Christina Green. Slashdot sucks.

Re:old wives' tale

[HarrySquatter]

Yep and posts like this one are fucking hilarious with such obviously made up shit like:

I'm old enough to remember when it wasn't like that. You'd run your program and it was ready in a second, you'd exit and it left no trace. Crashes were virtually unheard of. We have people where I work who only do data entry, and they still use wordperfect 4.2 on 386 hardware. I've seen their workflow and how fast it works for them and I can see if they "modernized" it would cripple their productivity.

Hahah lolwut? Crashes were virtually unheard of? Back in DOS crashes were basically a way of life with all the buggy software that each had their own handrolled version of psuedothreading, video ouput, etc. Secondly, WordPerfect 4.2? That was seriously buggy shit. Yep, this is just a bunch of old timers remembering a romanticized version of history that never really existed.

Re:old wives' tale

[HarrySquatter]

Yes, that was kind of the point. Since he was holding up WordPerfect as an example, which was *gasp* wait for it *gasp* a DOS program, he was clearly attempting to claim that the DOS era was something free of crashes which is completely absurd. Secondly, the claim that software older than DOS wasn't buggy and crash prone is also bullshit. Some of the most classic bugs that get pointed out when you read up on the history of C come from this supposed "golden age" where all programmers were apparently wizards of their craft. Except that this "golden age" is a nostalgic farce and there were plenty of shitty programmers in that day producing buggy and bloated (for the time) code.

'Resource constrained era'

[DavidR1991]

Comments/phrases like these completely fail to grasp that things like this are RELATIVE. What is 'resource constrained' today isn't what was seen as 'resource constrained' 20 years ago. Likewise, many young programmers _today_ (including myself) DID in fact learn to code in what would be seen as resource constrained environments compared to today's machines. I cut my teeth on an 8MB Win95 machine and later a 32MB machine. Sure, that amount of RAM to play with is an insane luxury if we're thinking back to early/earlier 90s or 80s. But compared to what we have now it IS resource constrained. And heck, even mobile devices have more than 32MB to play with these days.

20 years from now 2 or 4GB of RAM will look like 'resource constrained' environments, and all of us who are 20-year olds now will be thinking "Herp derp, this new generation won't understand the resource constrained 32MB days!". And then 20 years from that, their experience will help them operate in 'resource constrained environments' when several TB of RAM is the norm or something

TL;DR: This is all a stupid circular pattern where each generation seems inferior to the last but still has some useful knowledge relative to specs of modern machines

Re:'Resource constrained era'

[Jeremi]

20 years from now 2 or 4GB of RAM will look like 'resource constrained' environments, and all of us who are 20-year olds now will be thinking "Herp derp, this new generation won't understand the resource constrained 32MB days!"

I like the aesthetics of this idea, but I'm not sure that the needs of computing are going to keep up with the supply of computing resources much longer.

For example, the last time I really had to worry about running out of disk storage was in 2005 or so. Since then, the size of the hard drives on the computers I use has always been "sufficiently large" that I've never run out of disk space -- from my perspective, modern hard drives are effectively infinitely large.

And in 2010 or so, I upgraded my computer to 20GB of RAM, and since then I've never had any issues with running out of RAM... even with multiple virtual OS's running, I still have plenty of RAM free. So for me, RAM scarcity has become a non-issue as well.

Of course I'm not saying it's impossible to run a 2011-era computer out of resources; it's easy to do if you try. But it's getting increasingly more difficult to do it without meaning to.

I'd imagine that by 2020 or 2030, the storage and processing capacity of computers will be so profoundly huge that people literally won't be able to come up with any effective new ways to waste it all. Even if they encoded all their spam emails as super-high-definition 3D holograms -- just because they can -- they still won't run out of resources.

At that point, people will simply stop thinking about gigabytes and gigahertz and so on, just as people no longer think about the starter motors or chokes in their automobiles. Computers will "just work", and if you ask someone how much space they have left on their drive, they won't know... or care.

One question...

[MachDelta]

How the fuck do you forget something you were never taught in the first place?

This article should really read: "Crotchety old programmers fail to pass on tricks of the trade, then complain anyways"

Re:One question...

[Anonymous Coward]

To listen, you must first be quiet.

Re:One question...

[Darinbob]

The market has changed over time. The number of engineers we need to deal with systems that have small memory or high efficiency requirements has grown slightly, whereas the number of code monkeys needed to write fluff apps and tweak web pages has grown immensely.

Re:One question...

[Jeremi]

This article should really read: "Crotchety old programmers fail to pass on tricks of the trade, then complain anyways"

Damn right we failed to pass on the tricks of the trade... the day after you do that, you're laid off and replaced by a 19-year-old H1B who's willing to work for Jolt and Fritos.

As for the complaining... that's an important part of being crotchety.

Duplicate story

[amn108]

Eh, didn't someone remind us of this a couple of months ago? Seems like someone really has teeth to grind with modern coders. Get a life, you suspicious person!

Go bang some metal

[Jimbookis]

Coder types, buy a CRO (like the cheapie but terrific Rigol 1052E), buy an Arduino board and use the AVRStudio4 to start hacking. Learn how to use digital I/O pins to measure the time it takes functions to run and try do some realtime stuff. I'll be making my daughter an electronic drum kit next week using an Arduino, some piezos and her eeePC to receive MIDI over a USB/serial to generate the sounds. A simple project to be sure but it'll get me up to speed with the Atmega1280.

I inherited an 8051 (spit - fucked if I know why anyone likes this CPU) project at my old work. I asked why they didn't turn the C optimiser on, the answer was the optimiser is broken as the code wouldn't run which sounded like BS to me. The owner with 30 years of embedded eperience was satisfied with this explanation. I got it working by putting the volatile keyword on some globals that were shared between main() loop functions and interrupts and bugger me if the application didn't start working with the optimiser on! My respect for the owner and his company began it's downhill slide that day. So even grumpy old codgers with years in the field like my old boss can be total n00bs too.

An observation

[zerox030366]

Most of my programming experience is in either C or assembly language, and a good portion on embedded devices. Recently at my job I have been learning perl, which is obviously an entirely different animal. I find it particularly interesting coming from this background to look at the different data types- In assembly, there really are no data types but only the hardware, in C, the data types are basically just abstractions of the hardware (pointers, arrays, etc). But perl has all kinds of things like typeglobs, and hashes and references (which still strike me as the english major's version of a pointer), which are far more abstracted. The hardware is doing the same things as always, but the model of the computer portrayed by the language is much different.

Re:An observation

[Jimbookis]

I have the same programming pedigree as you. For my work at least I have never had to use anything higher level than C due to embedded projects. I worked with a young bright self taught programmer for whom higher level languages was his only experience and took the view of the computer as a mysterious black box. He appreciated that there was low level stuff going on in this thing but he couldn't really get at it with .NET. A good example of things going pear shaped was the insane amount of time the.NET application took on an eeePC when writing large amounts of data to serialised XML form.

Re:An observation

[zerox030366]

I worked on one embedded project with a C# programmer and he had the same idea of a computer being a thing of mystery- he had no clue how the hardware worked and his method of debugging was simply guessing any error he could think of, even if it was physically impossible.

Hardware issues less common

[coolmadsi]

I get the feeling that hardware errors were a lot more common back in the authors day; they don't come up very often now.

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).

Excuse me while I laugh my head off...

[sconeu]

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.

Re:Excuse me while I laugh my head off...

[aztracker1]

I thought the same... though PERL is great for one thing... text data processing, like logs.

Re:Excuse me while I laugh my head off...

[david_thornley]

And a surprising amount of little tasks on computers seem to call for good text processing. It's a very useful language.

Embedded software development

[DeadCatX2]

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.

Re:Embedded software development

[NewWorldDan]

Oh, the things I didn't know when I started doing embedded software development. I learned a rather frustating lesson that Microchip's PIC16 series only has a 7 level call stack. Ironicly, I was only overflowing when I called a routine to output debugging information.

To further muddy the waters, the device transmits data to a server where everything is written in C#. My work can be frustrating at times. Much less so since we switched development to the PIC32 series (128k ram? Heaven!)

Re:Embedded software development

[jepaton]

Even on slightly fancier processors you can have limited JTAG debugging support. Severe limitations on the number of instruction breakpoints and data breakpoints can limit the usefulness of the debugger for everyday work. Even in not-particularly-time-critical software single-stepping through the code can be impossible - either the bug is time dependant (e.g. errors in hardware drivers or race conditions) or normal execution relies on timing (e.g. communications). The debugger is useful only for a very narrowly defined set of bugs.

When the debug-with-printf approach is used the program speed can be badly affected. Changes in program speed can affect the occurance of the bug being investigated. Output may be going to a serial UART running at no more than 115200 baud. Even the GPIO toggling method can have this problem; the processor we use has the GPIO in a separate clock domain that runs several times slower than the instruction clock. One workaround for this is to write to RAM (if available) or to additional hardware connected to the external memory bus. At worst you're reduced to paper debugging.

Re:Embedded software development

[DeadCatX2]

I hear ya. Each generation of PIC is so much better than the last. Lately I've been using PIC24 series and it's so much better than dealing with all the idiosyncrasies in the 16/18F series. Some of the chips have fake interrupt-on-change pins. Others have the classic read-modify-write problem with no LAT register.

Re:Stuff

[Lennie]

less is definitely more, atleast if you ask me.

Re:PEEK

[somersault]

# man sex

go for the faster hardware

[Osgeld]

it will last longer and be less hassle

Re:go for the faster hardware

[Darinbob]

And cost enough more that you no longer make a profit or you exceed your budget.

Re:go for the faster hardware

[Osgeld]

chances are, faster hardware means something faster than a P4, so if your budget is less than a couple bills you really need to focus elsewhere

Re:go for the faster hardware

[Darinbob]

I mean budget to create a device. Manufacturing it for $19 versus $20 is a big deal if you're selling many thousands.

Next article should be about pointless titles

[Tridus]

"I see poor understanding of the performance ranges of various components," says Bernard Hayes, PMP (PMI Project Mgmt Professional), CSM (certified Scrum Master), and CSPO (certified Scrum Product Owner).

There's such a thing as a certified Scrum Product Owner? Am I now being encouraged to go get management trained on how to be certified at owning Scrum Products?

I'm not sure if I can take what someone with a set of certifications this ridiculous says seriously.

Re:Slashdot's Pointless Story of the Day?

[FlyingGuy]

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.

Optimization vs Standard Performance

[Wraithlyn]

There's a big difference between "optimization", and "designed with standard performance considerations in mind" though. The latter should always be done. The former, only when there's a genuine need to run As Fast As Possible (tm).

Too many new coders today have no grasp of EITHER. They don't understand even the basics of algorithmic efficiency ("big O" notation, the difference between a linear and constant time lookup, etc), the cost of memory allocation (doing things like unnecessarily creating a new instance of a var or object inside of a loop, for example), or how to properly normalize and index a database.

So we wind up with situations where a web service is performing slowly... because it's looking up a DB record based on a non-indexed string match. :P (A real-world example encountered this week). And things like this aren't caused by laziness, or because "the project got done faster", they're caused by simple ignorance of what's actually going on. And why is this? Because when the developer originally built it, the brute force approach "was fast enough" with his small local dataset.

Where are they finding these "new coders?"

[hism]

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:

• - One data structures class and one algorithms class - We learn about properties of fundamental data structures; how to analyze and design algorithms for CS, combinatorial, and graph theory problems; complexity classes
• - One intro compilers course - Nobody graduates without writing a compiler for a C-like language that outputs MIPS assembly.
• - One operating systems course - You can either write an OS for a MIPS emulator, or you can write an OS for a physical 68000-based CPU, using C (without the standard library of course) and assembly. So yeah, we have debugged without an IDE, by staring at hex string dumps, for days at a time.
• - One course on design patterns/architecture - Yes, we learn some Software Engineering principles too, even though it is an academic institution.

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?

Also in terms of CPU or RAM

[Sycraft-fu]

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.

Re:Also in terms of CPU or RAM

[aztracker1]

Again, I agree to an extent... However some decisions up front can be just plain bad... for example, querying a database, pulling a fairly complicated set of joins for a result set, then only using 2 fields because the procedure already existed, to augment this information in a loop, where another query is made for each iteration, that now pulls more information across the wire to use three fields instead of a simpler query with a left join.

I've seen many times over where a convention is used, and a result takes > 3 seconds that should take a fraction of a second. I know that even then it's not so bad, but I am tired of seeing unresponsive web based applications that are only that way because of poor coding choices. Not even getting into passing dates, uuid's, and numbers as strings. It's not rocket science. Simple, poorly written line of business apps. As much as I may prefer one framework over another, the types of bad choices I see happen over, and over again.

A lot of this doesn't come down to premature optimization, a lot often comes down to using certain design patterns, or conventions where they don't belong. Right now, I'm reviewing an application using a typical entity/dal/bll separation, with stored procedures behind the bll. A lot of whats in place is a literal crap ton of translation layers, often for tabular data that doesn't really even fit the enitities defined well, tis isn't "MS Entity Framework" nut hand code.. The entire BLL goes straght to the DAL, which in turn often calls a sproc... most sprocs are only used one place. A really simple web app that should have taken less than 3 months is now at month 8, and still has a ton of bugs, and unfinished work. A simpler DAL for the db calls from the application without the entities, and/or bll would have been simpler, easier to maintain and taken less time. Many of the SPs are really simple queries that imho didn't need t be broken out like they were (that's a dba v. dev argument though).

I've seen similar issues in using ORM tools religiously, where breaking out of the ORM is often prudent.

Total tangent, been a really frustrating day.

Re:Also in terms of CPU or RAM

[TheRaven64]

You're talking about microoptimisations. These are almost always better left to the compiler. The grandparent is talking about macrooptimisations. For example, your compiler can't transform your bubble sort into a merge sort or a quick sort. It can't remove your iterative search of database query results and add a WHERE clause to your SQL.

Picking an efficient algorithm at the start usually makes a big difference to overall performance and doesn't cost much in developer time. Here's a toy example: When I was benchmarking my Smalltalk compiler, I tried implementing a recursive fibonacci generator in C and Smalltalk. The goal for the Smalltalk compiler was to be within 10% of GCC's performance (which it achieved, by the way - it's actually slightly faster on this benchmark on my machine, but that's likely due to weirdness with cache alignments, it should be slightly slower). Afterwards, I tried doing a really inefficient implementation of a better algorithm for generating a fibonacci number in Smalltalk. This was 1000 times faster (and this difference increased with larger input values). A quick and dirty implementation of a linear complexity algorithm will beat a heavily optimised implementation of a polynomial time algorithm in all but the most trivial cases.

Re:Also in terms of CPU or RAM

[Joce640k]

If the code is generally OK then you're right.

If it's bogged down by stupid design decisions then fixing it will take much more than just refactoring a couple of functions.

Re:Also in terms of CPU or RAM

[warrax_666]

Picking an efficient algorithm at the start usually makes a big difference to overall performance and doesn't cost much in developer time.

You'd need to supply some evidence for this rather than just asserting it. In your example of sorting algorithms, it doesn't hold true: Quick sort is a lot more complicated to implement than, say, bubble sort. If you're picking between different sorting algorithms from a library, then it's certainly a different matter. In that case there really is a (demonstrably!) zero cost.

Unless you've benchmarked and determined that the choice of sorting algorithm is actually a problem, you should absolutely do the simplest thing that could possibly work. You have no grounds for doing anything else.

Re:Also in terms of CPU or RAM

[TheRaven64]

Quick sort is a lot more complicated to implement than, say, bubble sort.

Actually, it really isn't. Quick sort can be implemented in 3-4 lines of code in a functional language, or about 20 in an imperative language. It's a spectacularly simple algorithm to implement. I've used it as an example of an algorithm to try to parallelise in a couple of talks because you can fit it on a slide without it becoming too small for people at the back to read. Bubble sort is about as complicated, if not slightly more so.

The same is true in a lot of other cases. Slow algorithms are not intrinsically simpler than fast ones. If anything, the converse is true because a fast algorithm is doing less work.

Yesterday's coders aren't necessarily relevant

[Just Some Guy]

Some old-school developers prematurely optimize for things we no longer need to optimize for (and shouldn't). From an older post of mine:

A recent experience with an ex-coworker illustrated this pretty well for me:

Said fellow, call him "Joe", had about 30 years of COBOL experience. We're a Python shop but hired him based on his general coding abilities. The problem was that he wrote COBOL in every language he used, and the results were disastrous. He was used to optimizing for tiny RAM machines or tight resource allocations and did things like querying the database with a rather complex join for each record out of quite a few million. I stepped in to look at his code because it took about 4 hours to run and was slamming the database most of the time. I re-wrote part of it with a bit of caching and got the run-time down to 8 seconds. (Choose to believe me or not, but I'd testify to those numbers in court.) I gave it back to him, he made some modifications, and tried it again - 3 hours this time. I asked him what on Earth he'd done to re-break the program, and he'd pretty much stripped out my caching. Why? Because it used almost half a gig of RAM! on his desktop and he thought that was abhorrent.

Never mind that it was going to be run on a server with 8GB of RAM, and that I'd much rather use .5GB for 8 seconds than 1MB for 3 hours of intense activity.

So Joe isn't every COBOL programmer, but you and I both know that he's a lot of them. But back to the direct point, how much of that 250GLOC was written with the assumption that it'd be running on 512KB machines or with glacial hard drives or where making the executable as tiny as possible was an extreme priority? Doing things like storing cache data in hash tables would've been obscenely expensive back in the day, so those old algorithms were designed to be hyper-efficient and dog slow. Whether you think that constitutes "working well" is up to you.

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.

Re:Yesterday's coders aren't necessarily relevant

[david_thornley]

It's not just optimizing for resources that are now plentiful, it's missing the changes in the stuff that used to be scarce.

If you're trying to optimize for CPU usage (and there are still applications that require that), you don't start by considering how many cycles you can shave off, you start by considering locality and caching. A few years ago, I sped up a time-hog routine a lot by doing exactly what my oldest books suggested not to do: I first rolled up the loops as tightly as I could and then applied a layer of indirection. By measurement, I was doing something right, and I was trying to make the function more cache-friendly. (It went from taking 80% of the total program time to about 60%, going from 4 times everything else to about 2.5 times everything else.)

Re:Yesterday's coders aren't necessarily relevant

[Your.Master]

One megabyte for 3 hours is 10800 megabyte-seconds. Half a gigabyte for 8 seconds is 4096 megabyte-seconds, which is less than half of the memory usage time. Assuming those numbers are even close to accurate, he wasn't even really optimising for memory usage unless you discount concurrency, and if you discount concurrency then optimising for memory usage over execution time is absurd, even given old constraints.

Re:Yesterday's coders aren't necessarily relevant

[Just Some Guy]

Those numbers are very accurate, except that I rounded my times up slightly and his down to the nearest hour. He wasn't concerned about megabyte-seconds. He was concerned about the horrific idea of a single process using half a gigabyte of RAM for any length of time whatsoever. I'm sure that if you asked him, I was the young punk with no consideration for resource usage.

And again, I understand to a point. I wouldn't want to run a horribly inefficient process that used multiple gigs of RAM simply because it was poorly written. But if I can throw some RAM at a problem to dramatically lighten other resource usage, I'll do it in a heartbeat.

Re:Yesterday's coders aren't necessarily relevant

[DutchUncle]

Nothing is unlimited. There is always a bottleneck. Where "Joe" was failing was in recognizing that the bottleneck had moved. OTOH your solution will be a problem if the system maintains total isolation between tasks and multiple tasks try to do this operation at once.

I'm more "Joe"'s age, but have gotten things done in embedded systems by chasing the bottlenecks from memory to bandwidth to CPU and back around. The point of experience *should* be "find the bottleneck and fix it", not "assume it's the same as it was last project".

I remember an article years ago about one of the early online multiplayer space combat games in which the whole point was that the developers started realizing that faster modems or no, internet or BBS or whatever protocol, short messages for more bandwidth really mattered to avoid lag (like, the missiles should really appear to hit the targets). Instead of the nice clear open messages they had started with on their original design, they had to use delta coding and bit-masked fields and fractional information in different message codes and all kinds of hackery to keep the data transmission short, trading the availability of CPU time to encode and decode for the comm bandwidth available. I also seem to recall more recent articles pointing out how online gaming was rocked by wireless introducing slowness and lag after everyone had gotten used to DSL/cable/fiber modem speeds - same problem come around again.

Re:Yesterday's coders aren't necessarily relevant

[DutchUncle]

ps - re: "resources no longer constrained" - one job had a customer develop a large telephony application intended to run 6 E1 lines (6x30=180 channels). It was modeled on the Tech Support demo model of process-per-channel (under some version of Unix). Worked just great up until some 40 channels or so, then degraded rapidly from activating the next two or three and was unusable with two more. Paging takes time, interrupts take time, RAM is not infinite, and OS thrashing matters. I helped the customer restructure into a DOS-style single process with a big table of channel structures, servicing all available hardware on every interrupt, and suddenly the exact same hardware could handle 180 channels without crashing even if they all went off-hook at once (there *would* be a noticable lag, but acceptable for the purpose). Maybe in a system today with a multicore CPU and multi gigs of memory life would be fine . . . except they'd probably be expecting to have one monster 8GB server instead of four 1GB servers, so the problem would come right back.

No what we need is programmers that can execute

[codepunk]

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.

Re:No what we need is programmers that can execute

[DragonWriter]

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.

Shipping code is a management problem, not a programming problem.

Specs

[LordLucless]

developing thorough specifications before coding

Believe me, if I could get anyone to approve, sign-off or even read a spec before it had to be developed, I'd write them a lot more often.

Re:PEEK

[maxwell demon]

# man sex

I see, you are working as root. You'd have safer sex from your user account.

Far TOO true....

[Magnificat]

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

John Carmack agrees.

[MaxBooger]

Oddly enough, John Carmack says something similar in his 2011 Quakecon Keynote. Ninety minutes of rambling on about Rage, the importance of static code analysis and programming the Xbox360 and PS3 to the metal. Well worth watching.

Re:John Carmack agrees.

[porjo]

Carmack's ability to talk non-stop without notes or prompting for 1.5hrs is astounding!! The relevant part of the video relating to this Slashdot article starts around 1hr 17min 50sec http://www.youtube.com/watch?v=4zgYG-_ha28#t=4666s

Not following the link ?

[choco]

I've now read the original article a couple of times and gone through the main comments a couple of times. ...and I am confused. It seems that many people commenting have not actually bothered reading the original article to see what was being discussed there - and have jumped straight in with comments about what they (mostly wrongly) think or assume the article was about instead.

Many of the skills discussed in the original articles are about avoiding and/or managing a diverse range of real-world problems of the kind still regularly seen today.

Whither specs?

[naasking]

[...] developing thorough specifications before coding [...]

We have more code verification, static typing, contracts, tests and assertions than ever. Somehow I doubt the above.

And if by 'specification', you mean a spec on paper separate from the code, that's because the lessons of the past have taught us that specs are never current, so what's the point? With more expressive, higher-level languages, the programming language becomes the specification language, and a specification in such a language is then naturally executable, ie. code is the specification with sophisticated types, or an executable program can be extracted from the specification ala Coq.

Pareto principle

[dballanc]

It applies to computer science too. Premature optimization may be the root of all evil, but it doesn't mean you shouldn't write code without a high regard for how well it performs in whatever environment you have. A decent understanding of the resource limitations (whether they be ram, io, time, or something else entirely) and a -very- little bit of effort can go a long way.

It's all about balancing coding effort vs the reward in doing so. It's also worth considering your users time. Shaving 10 seconds off the load time on an application may seem silly to a coder if it takes 4 hours to do it... with say a minimal example of 10 people in your office starting your app several times a day, it would take months to break even on productivity. However if you are developing a widespread application, saving 1000 people 10 seconds twice a day is a whole different story. 100,000 and you've just wasted 23 user-days per day to save yourself a one-time half days work. Great job dude!

Use common sense. Balance cost vs benefit. It's not that hard.

The only thing...

[Anonymous Coward]

...today's coders don't know is that their innate talent doesn't trump our experience. At best it only makes them equal to our innate talent that we still have in addition to all our experience.

When a fresh-out-of-college coder thinks he can enter the maintenance cycle of a well-established product and change how everything is done, with no knowledge of any of the client needs or painful events that drove the existing processes, all he does is create a tremendous amount of pain for the clients and embarrassment for himself.

You hear me, new guy? Stop being a bull in the china shop! Learn the damn system before you go changing it.

And also just meeting the functional requirements is NOT ENOUGH. Your code must also be maintainable by people who didn't write it, scalable to demand far greater than a handful of users on a QA server, AND it must be secure, which you won't get right if you haven't studied up on the exploits.

Sheesh.

Re:The only thing...

[CptNerd]

All programming knowledge is here:

The Tao of Programming

Specs analogous to business plans

[Anonymous Coward]

Don't underestimate the value of a spec.

It's a very good idea to write a thorough business plan before going in for a business proposal (and loan), as it forces a person to think through the different scenarios and problems.

Likewise, when somebody shows up with a well-considered spec--usually after some informal Q&A with developers--I find the outcome tends to be very good. Even when the spec evolves (usually via email or voice) and becomes drastically different, the original spec is still valuable because:
1. It thoroughly highlights the business problem(s) that needs to be solved.
2. It forces the writer to consider whether the proposal is actually a good one.
3. It gives a starting point on a candidate-solution (and gives coders a chance to think about a counter-proposals and tweaks).
4. It gets coders thinking early-on about some of the outlier business conditions--not necessarily completely fleshed out in the spec.
5. Down the road, it gives people a window into #1. This is important if you're dealing with esoteric or arcane business rules.

It's all too easy to blame developers for a shoddy job; but often, analysts will ask for features that with a bit of thought were probably a bad idea in the first place.

Full of shit

[Alex Belits]

When the article is not vague, it is plain wrong.

Recently I made teo rather trollishly titled posts on the same subject, on my Livejournal:

http://abelits.livejournal.com/41968.html
http://abelits.livejournal.com/42052.html

Seeing how even supposedly knowledgeable developers post unreadable, vague opinion pieces, I think, I will have to add more to those.

Re:nonsense

[Alex Belits]

ecosystem

lol

Efficient code for the win

[mcavay]

I agree that saving time for people is something, but I also think that a well written and optimised code is the best way. If you write something in a sloppy manor then later down the road that could cost more for the company in further upgrades due to elevating the scale of a program. I am of course new to programming and writing code (3 years). Well for example you have a web page that runs fine and dandy say using "wordpress" it helps a user to get a blog up fast. but then you have to "tweek" the hell out of it to handle a larger number of page views, this leads to more work. The same program can be written in a far more officiant manor. As a junior web developer I find that "bloated code" slows down things a fare bit. When you can do the same thing in 1 line of code as you can in 10 then why are you doing it in 10 ! In short I think that coders should do the best and most economical jobs they can, saving money and time, I mean rather than just saying "oh we will chuck another server at that and it will be ok". I might be wrong about this so please correct me if I am wrong.

Problem is there's more stuff you CAN'T know...

[cardpuncher]

One of the problems I find I encounter more these days than in the past is that there the coder is increasingly at the mercy of more and more layers of underlying code which is more or less impervious to reasonable debugging.

The performance of your application code was in the past pretty deterministic - not usually very much between the OS and your code and the OS usually had a closely-defined role and if it failed the consequences were usually obvious. It was also exhaustively documented so there was little to take you by surprise.

These days your code may be on top of a bunch of middleware running on top of an intermediate language environment on top of a virtualised machine and OS with networked storage. When these things don't behave as you expect, good luck with finding anyone who knows about all of the various internals enough to help you solve the problem.

And, indeed, good luck with writing your application. Half the stuff the middleware provides to you will only be documented in someone's blog somewhere. If you're really lucky, the Release Notes will be accurate in its report of the stuff that doesn't actually work as documented. Some part of it will assume a model of resource allocation that is unhelpful to your specific use case but you won't find that out until halfway through your project.

This is just part of the IT hiccup that occurred with the advent of the microprocessor - Computer Science was forgotten and painfully relearned over a period of about 30 years. Unfortunately, it's rather stagnated in the interim and the problem is not so much that people have forgotten the lessons of the past, they haven't actually developed the new tools to deal with the staggeringly more complex environment in which software now lives and is developed.

Re:Problem is there's more stuff you CAN'T know...

[Lazy Jones]

One of the problems I find I encounter more these days than in the past is that there the coder is increasingly at the mercy of more and more layers of underlying code which is more or less impervious to reasonable debugging.

True, but not tragic, because nowdays you can "google" for a solution or post on SO to get help, while 25 years ago, all you could do was figure it out by yourself or try to ask around whether anyone knows someone with a deeper knowledge of the matter... I really don't want to go back to those dark times, but we sure could file more bug reports or flame programmers publicly for writing crappy libraries. ;-)

Economy/elegance is a green issue too

[hughbar]

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.

5K RAM? Luxury...

[Joce640k]

5k would have been heaven when I first started typing Z80 hexadecimal into a computer.

Some more of the skills I should have

[Bost]

Heal a broken leg, milk a cow, give birth to a child. Sorry, I'm such a noob...

Re:Slashdot's Pointless Story of the Day?

[zAPPzAPP]

I do lowlevel stuff like that on a daily basis on microcontrollers. I do it in C.
That is as low of a language as you need to go. I don't see any point in writing assembler ever.
Yes, it's useful if you can read it for debugging and you will sometimes use a handful of assembler instructions embedded into your usual programming language, to use special functions of your controller. But writing programs in assembler... just no. Just because it can be done, does not mean it's a good idea to do it.

It's a race, not a beauty contest or science fair

[Lazy Jones]

Driven by the web (and possibly games) industry, programming has become a race: whoever ships the product or new feature first, gains an advantage. So development speed is much more important than in the old days, when you could still win something by cramming more features into 64KB RAM or when you paid for your rented computing time and could spend months optimizing your code. Consequently, architectural decisions are still important, but optimizing your code - unless it becomes a specific requirement, for example, when you simply cannot afford to buy a box with 512GB RAM that can run your current stuff unmodified - is not.

Today's machines are stochastic

[alispguru]

Their performance varies a lot, depending on factors you don't or can't know. The back-of-the-envelope computation example in the article goes through a much longer chain of deduction these days:

Fortran statement
x86 instructions
RISC-ish micro-ops
full-speed until:
        * cache empties
        * branch prediction fails
        * speculative execution runs out

When optimization is premature

[DragonWriter]

I have seen people recite the mantra of "don't optimize prematurely" when I can tell that they think it means to never optimize.

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.

"in the days of 14.4 Kbps modems"

[drobety]

Ugh, I cut my teeth when 1200 bds was bleeding edge... Not sure that I agree completely with the author though. Whether a programmer write efficient code depends on his natural skills, not when they were born. Regardless of whether one programmed in assembly in some distant past in order to squeeze every single CPU cycle they could, I think natural skills is what matters most. Bad programmers back then when resources were very limited, would still suck big time nowadays producing efficient HTML/PHP/Javascript.

I agree that it is very useful to know how things really work under the hood, and good programmers, past or present, tend to naturally inquire about "what is behind," so even today's naturally skilled programmers will do as well as naturally skilled programmers of the past IMO.

My problem in this distant past is that I was on a never ending quest to save yet another CPU cycle, even if it meant zilch to the end-user. I eventually understood that shipping a product is quite important, and changed my focus to convince management that "shipping a product that doesn't suck is quite important," and all went well from then on.

Re:PEEK

[tonique]

A classic sequence:

unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep

Re:So Windows 3.x is BETTER than Win7??

[warpuck]

I dont think that 16 bit programs would see a proportional gain if such a thing as a 3.7Ghz 486dx existed. If anything the newer python-jython programs are better because those programming languages are more tolerant of the hardware running the programs. In therory a 20Mhz 386 + AMD or Intel math coprocessor was close to the same thing as a 486dx 20Mhz . Yet some software then would not run on different brands of memory with same motherboard/processor/coprocessor combination. I totally expect a 32 bit programe that works on a 512 Mb Celeron 2.0 system & win XP to work just as well on a 4 Gb Phenom 1090T system &win XP , the only difference should be execution speed. Back then when they were broken I fixed them, now I just get a new one just like everybody else.

Design Patterns

[s-orbital]

Unfortunately, despite having a bachelors in CS, and several years of web programming experience, I have only recently discovered OOP design patterns. They are very useful methodologies, and I think today's programmers, especially in the web development arena are far too ignorant of these useful additions to one's toolbelt.

Lost Knowledge of Bits and Bytes

[obsess5]

I don't think programmers are less capable now than earlier. There's just been a loss of connection between the software and the hardware. I happened to look at a piece of code a young programmer wrote in C++ to insert a 4-byte length field at the beginning of a file. A simple task, keeping in mind that the field had to be big-endian. This programmer, however, formatted the length value as an ASCII hex string, decoded the hex string 2 digits at a time to place the bytes into an array, and then wrote the 4-byte array out to the file. This solution boggled my mind!

As other posters have noted, I think it is because colleges teach using ever higher-level languages and are skimping on the lower-level architecture and operating systems courses. (On the other hand, we learned LISP and SNOBOL when I was in college, so high-level languages are not a bad thing; my own preferred languages are C and Scheme.)

Job security comes from ADDING value, not this...

[Joey Vegetables]

As an architect, designer and coder, I see this all the time, and fight it all the time, but usually lose. There is a place for ORM layers, dependency injection, TDD, poorly documented libraries, closed-source libraries, etc.; however, my experience leads me to believe that most of the time, in expert hands they are unneeded, while in less than expert hands they just get in the way, create more work, slow things down, and make both getting to market, *and* subsequent maintenance, orders of magnitude slower.

I often work with people who would rather write 1000 lines of XML than 25 lines of SQL, or write 25 irrelevant unit tests rather than gather and correctly implement one testable requirement. Give me a managed environment (Java/.NET/Python), a decent RDBMS, and a decent, preferably managed API around any hardware I need to access or I/O I need to perform, and I can generally get the job done with few if any other tools, and it will get done quickly and be at least as maintainable and flexible as the more "enterprisey" solution that needs 50 incompatible libraries just to build. But then the so-called "architects" whose experience comes from reading Pointy Head Weekly^H^H^H^H^H^H Gartner, rather than building or maintaining real systems, will tell me I'm doing it wrong, and make me redo it with the 50 libraries.

"If you're right, and we're just making more work for you, well, think of it as job security." Another canard. Job security comes from adding value and contributing to the success of the organization. Which I try very hard to do, and others try very hard to undo. Not so much at my current job, but my previous employer - a good, but very bloated and bureaucratic organization - was famous for it, and ended up having to outsource almost all their development because it became so inefficient. Now, a bunch of people in Chennai have job security, instead of my former colleagues, because they will be adding value whereas our "architects" did their very best to ensure that we could not.

Re:Cheap microcontrollers

[n7ytd]

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.