"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 <paul@opscode.com>
> 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:* plug-discuss-bounces@lists.phxlinux.org 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"
> <Rusty.Carruth@smartstoragesys.com> 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 - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)