"Anyone can cook. But not everyone can become a great chef."
As more and more people have gained access to the tools, the level of
proficiency to use said tools has dropped. One example from this thread.
"Linux used to be rock stable, now it crashes every three months"
More people are trying to make it work with more and disparate hardware.
That makes it harder and harder for a coder to really optimize the
performance of any given amount of code. So that optimization comes in
later... at the compiler generally. This is why Intel spends so much on
their compiler and performance gains are seen just from changing
compilers. But that optimization comes at a price. It won't work as well
on AMD processors. It can't be used at all on Sparc, Power, etc...
The real bloat comes when you find out things like a microsoft developer
crammed a limited version of their Flight Simulator into Excel... and
that inclusion made it to release. Or the different ways you access
functions aren't the same code in the backend... which means they were
probably made by different developers at different times under different
conditions. So now you have multiple, similar yet different, copies of a
function in the compiled code. Same thing with Linux and all the
different libraries and GUIs and other applications...
John carmack has similar rants and epiphanies on his twitter feed.
On Friday, June 14, 2013, Dazed_75 wrote:
Nevertheless, as one of those old-timers, I have to be concerned
at the apparent total disregard for code efficiency. Far too many
of the tools to make design and development efficient do so with
inexcusably crappy code in the tools themselves.
The tools still need to be at least cognizant of efficiency or
they will produce exponentially inefficient code. That is a
complete and total waste of resources. If I am rich, it does not
follow that I should be ignorant and throw stacks of money into
the wind lest I become not rich. On the other hand, spending my
riches wisely can make me a better businessman and able to be a
better human being while retaining the richness to continue doing so.
So don't ignore efficient code as a waste of money, but choose
wisely when to be spendthrift and when to be profligate.
On Fri, Jun 14, 2013 at 9:33 AM, Paul Mooring <[email protected]>
wrote:
I think as an extension of this thought, there's still plenty
of systems programs writing really "tight" code. The linux
kernel for example is pretty efficient, in my opinion it's on
par with ye programmers of old. The difference now a days
there's a *lot* more programmers and the field is much easier
to get in to.
Paul Mooring
Operations Engineer
www.opscode.com <http://www.opscode.com>
------------------------------------------------------------------------
*From:* [email protected] on behalf of
Kevin Fries
*Sent:* Thursday, June 13, 2013 6:43 PM
*To:* Main PLUG discussion list
*Subject:* RE: Then vs Now Programming WAS: Re: AMD vs Intel
memory managemement
I think there is a big reality being missed here. Back in the
"old days" when developers wrote "tight" code, that was out of
necessity not out of some higher purpose. Computers did not
do much, spell checkers were a luxury, as were point and click
interfaces. I remember spending more money for my first 10MB
hard drive than i would spend for a 1TB today. The price to
write this tight code today is too high for the benefit it
would bring. Yes code is more bloated today, but if you take
a look at the bloat in proportion to the increase in memory,
disk, and network speed, it could be argued that software has
gotten smaller, not larger.
Just my $0.02
Kevin
On Jun 13, 2013 2:03 PM, "Carruth, Rusty"
<[email protected]> wrote:
IMHO, the answer is yes. And the answer is no.
Operating systems in ‘the olde days’ were REALLY small,
and didn’t do much. No gui, for one! (Well, ok, on the IBM
1130 I used the GUI was the flashing lights on the console!)
Shoot, the entire boot loader fit on a single 80 column
punch card. The card had I think 12 bit positions per
column, so that means we could load a program (from
cards!) with 120 bytes of program. The computer ran 16 bit
instructions, so that means in 60 instructions we could
read binary data from the card reader (12 bits at a time),
and store it into memory!
FORTRAN (and later C) and assembly language were probably
the primary languages in use for applications.
As James said: “Cache? We don’t need no stinkin’cache!”
Cache was a luxury that Idon’t think we even considered…
I’m not sure how much is language bloat, and how much is
(perceived?) lack of need to be careful abo
--
Dazed_75 a.k.a. Larry
Please protect my address like I protect yours. When sending
messages to multiple recipients, use the BCC: (Blind carbon copy).
Remove addresses from a forwarded message body before clicking Send.
--
A mouse trap, placed on top of your alarm clock, will prevent you from
rolling over and going back to sleep after you hit the snooze button.
Stephen
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
