Long ago I used to hear often that you can accomplish three things in programming:
small code size
fast code
short developement time
And that you could always accomplish any two of those but not all three.
Is that still true today?
Long ago I used to hear often that you can accomplish three things in programming:
small code size
fast code
short developement time
And that you could always accomplish any two of those but not all three.
Is that still true today?
Nope. Probably never was...
A decent programmer acquires a set of skills that contribute to both development speed and well written code, good compilers provide automatic production of highly optimized code...
These are just soundbites meant to impress and give some sort of romantic notion to programming. They are hardly verifiable, do not under any circumstance constitute a universal truth to such a complex and heterogenous task as programming, and can in fact, under most circumstances, be easily proven wrong. Because they are usually given in the shape of some sort of unquestionable truth, they tend to restrain critical thinking.
Ignore those and many other sayings.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
You can always accomplish all three simultaneously by changing your notion of "small", "fast" and "short". However, if you ignore these relative notions and understand the saying as just being about trade-off, then it becomes obvious that some trade-off between time and improvements of different kinds will always be present, and not only in programming.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Interesting answers.
The time I was referring to had very little hardware to perform things like video or even
audio.
Speed was needed in the code itself. So that has definitely changed and may not be
a factor, at least for certain applications.
But assuming there was no hardware to handle the speed problem, Would it still be true?
Being defeatist in many areas of my life, I refuse to accept further notions of failure in programming.
I think Laser summed this up quite well.
Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.
I don't understand what you mean by "no hardware". But does it matter if I don't? What can possibly exist in every software development project ever written that makes it true that no code can be both simple, fast and quick to write? If we are ready to accept this, we need to identify the causes. Otherwise we are dealing with an unproven statement.
Laserlight makes an interesting point about trade-offs. It's a well known problem in programming. But these don't exist everywhere, or are always relevant if they do (in which case the terms "fast", "simple" and "quick" assume different meanings). So the simple matter of fact is that the way the saying on your OP is constructed makes it very easy to write it off as being false.
Oh boy, I couldn't empathize more!
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
It does seem difficult to achieve all three at once, though. I remember writing a graphics library for the
Commodore 64, which had none. The computer was so slow, that assembler was only way to do it.
I came up with a very small code size of very fast graphics functions, callable from BASIC. But I really
can't say if it could have been done in less time. I couldn't. And I don't know if some else could have
either. That graphics library was not an easy project.
How far back in history did you have to go to dig that up... 25 years? maybe more...
Back to days when MS-DOS was king, I'm betting...
Heck, even a 386 machine could play videos at TV resolution with full stereo sound.
Well, at least this is in the GD forum.....
Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.
Oh my... what a nice double ententre!Well, at least this is in the GD forum.....
Oh, yes, I am talking about the 80's.
But now, is speed coming from speed efficient code or hardware?
Ummmm... lets see... 16 mhz, 16 bit IAPX86 vs 3 ghz 64 bit AMD64x2 .... What do you think?
Round here you can't even buy a machine under 1.6ghz and the "entry level" desktop system is a dual core 64 bit processor running 2.8ghz.
Last edited by CommonTater; 08-23-2011 at 10:22 AM.
Indeed.
How much incredibly sluggish code might be out there, and no one notices?
Fast machines do free up a programmer to concentrate on things other than speed.
Sometimes.
