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
>
> ------------------------------
> *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
(text/plain)