[Skaggles]

[pokiaka]

While I can't agree that we should start again from scratch without advancing etc. I did read in Jeff Duntemann's assembly book that we've gotten lazy and spoiled with memory and whatnot, and in the time that programmers didn't have much memory and a super-CPU (as we have these days) to work with they built up a very efficient character.

[Lemur]

Hipster programmer strikes again?



...always relevant.

[cfoley]

pokiaka, on 16 September 2012 - 09:00 PM, said:

While I can't agree that we should start again from scratch without advancing etc. I did read in Jeff Duntemann's assembly book that we've gotten lazy and spoiled with memory and whatnot, and in the time that programmers didn't have much memory and a super-CPU (as we have these days) to work with they built up a very efficient character.

It's all relative. We get taught about the classic time v space trade off. Really, it's a three-way trade off: cpu time, memory and development time. The first two have got a lot cheaper and readily available so it' natural that the development time becomes the limiting factor. It's almost always better to code something that is easy to write and easy to maintain than to spend ages crafting a superior solution.

[DarenR]

I was the last true inventor of all things techincal... I mean back in the day when I created H.A.L. and flew in space everyone loved me. Now not so much.....damn it wait that was a movie...

[CTphpnwb]

pokiaka, on 16 September 2012 - 04:00 PM, said:

While I can't agree that we should start again from scratch without advancing etc. I did read in Jeff Duntemann's assembly book that we've gotten lazy and spoiled with memory and whatnot, and in the time that programmers didn't have much memory and a super-CPU (as we have these days) to work with they built up a very efficient character.

They also did some really stupid things, like using two characters for the year instead of four. That cost businesses and individuals billions of dollars and millions of lost man hours to fix. In some cases, those same programers came up with "fixes" that are only temporary and will cause problems ten, twenty, or even fifty or more years from now if the software isn't replaced.

So much for the more "innovative" past.

[trevster344]

aloneprogrammer, on 16 September 2012 - 01:57 AM, said:

I'm not on innovation but today's dev don't have enough skills like pasts' dev

They have plenty.. you're just quite naive and haven't finished that puzzle yet.

[supersloth]

today's topic creators are not as innovative as those of the past.

[BenignDesign]

We need to start from scratch and build a bigger, better topic creator.

[jon.kiparsky]

CTphpnwb, on 17 September 2012 - 09:50 AM, said:

pokiaka, on 16 September 2012 - 04:00 PM, said:

While I can't agree that we should start again from scratch without advancing etc. I did read in Jeff Duntemann's assembly book that we've gotten lazy and spoiled with memory and whatnot, and in the time that programmers didn't have much memory and a super-CPU (as we have these days) to work with they built up a very efficient character.

They also did some really stupid things, like using two characters for the year instead of four. That cost businesses and individuals billions of dollars and millions of lost man hours to fix. In some cases, those same programers came up with "fixes" that are only temporary and will cause problems ten, twenty, or even fifty or more years from now if the software isn't replaced.

So much for the more "innovative" past.

They were innovating. You usually get things wrong when you're innovating. That's why it's usually a bad idea to innovate just for its own sake.

[ishkabible]

the Y2K problem actually was very smart for programers if you ask me. It allowed them to push out more advanced software with less man powers at the time and THEN it employed a bunch of programers to fix it down the road.

would you rather be innovative or smart

[jon.kiparsky]

Regardless of the virtues of creating work for programmers down the road, the use of 2-digit dates was a very good design in an era of limited memory. This begins with punch cards, of course: you have 80 columns, it's 1950 - do you really think you want to use two columns for the year? As the records migrate to electronic storage, memory is still very expensive, and shaving two digits from that field still makes sense. The failure occurred later, when programmers failed to adapt the design to expanding memory capacities.

[GrantLyk]

aloneprogrammer, on 15 September 2012 - 08:38 AM, said:

Yes this is true today's programmer can't do what other do.There are many programming language but they built on C or on DENNIS RITHIES'S Shoulder and C is on Asm so someone can create asm which can create language which directly generate binary,can someone make things appear o monitor or create colours from ground-up without using anything all from scratch,etc....

Haha, oh so hipster, i bet you were programming before it was cool?

[duffman18]

GrantLyk, on 17 September 2012 - 01:44 PM, said:

aloneprogrammer, on 15 September 2012 - 08:38 AM, said:

Yes this is true today's programmer can't do what other do.There are many programming language but they built on C or on DENNIS RITHIES'S Shoulder and C is on Asm so someone can create asm which can create language which directly generate binary,can someone make things appear o monitor or create colours from ground-up without using anything all from scratch,etc....

Haha, oh so hipster, i bet you were programming before it was cool?

What! Programming is cool now!?!? If I would have known this sooner picking up women would have been so much easier.

[baavgai]

CTphpnwb, on 17 September 2012 - 10:50 AM, said:

They also did some really stupid things, like using two characters for the year instead of four. That cost businesses and individuals billions of dollars and millions of lost man hours to fix.

You think a COBOL programmer writing code in the 1960s(!) was thinking about someone still running the same code long after they've retired? First known reference to Y2K is in 1984, in Computerworld. Even then, it sounded too far away to worry about. Who would keep one of these ancient systems running into the next century?

I have programs 10+ years old running live, in production, that were supposed to be a bandaid for the new systems that never came.

Remember, it's possible your code will run longer that you do.