Request for aid that makes me sound dopey

[Anthony]

Originally Posted by kdtipa

A really good software engineer can write elegant code that runs fast and without a lot of inefficient code. Inefficient code takes more system resources to handle. If I write a complicated solution that uses nested loops and keeps initializing heavy objects, I'm choosing things that take a lot of system resources that will generally take more system resources. My thinking is that a really good programmer can write the same functionality using better code that is less complicated... less complex.

Usually this is a result of optimizing for development cost -- by writing in higher level languages and using external toolkits, you save development time at a cost in performance.

[Refplace]

Originally Posted by Anthony

Usually this is a result of optimizing for development cost -- by writing in higher level languages and using external toolkits, you save development time at a cost in performance.

A lot of it is also due to management driven production cycles. A lot of programs are poorly optimized due to lack of time devoted to it.
As for the memory discussion its purely ancendontal but my first database program was a DB II (I think) database on a Heathkit with IIRC 148k RAM that ran mostly from floppy discs. The old big 5 1/4 ones.
That was a very long time ago so my numbers may be off but I used 10 or 11 discs that stored mostly data. It was used for my AD&D game to load random monsters from the Monster manual.

[Anthony]

Originally Posted by Refplace

A lot of it is also due to management driven production cycles.

How does this differ from what I said? I mean, sure, there are better and worse ways to cut corners, but in the end all the useful ones amount to 'lower quality final product, but cheaper to develop' (there are some ways of cutting corners that come back and bite you immediately and thus waste money).

[Refplace]

Originally Posted by Anthony

How does this differ from what I said? I mean, sure, there are better and worse ways to cut corners, but in the end all the useful ones amount to 'lower quality final product, but cheaper to develop' (there are some ways of cutting corners that come back and bite you immediately and thus waste money).

It compounds it, not contradicts it.
Since the problem is due in large part to two things that could be addressed with more/better resources (Either more time or better tools) it gives options for better programs using fewer computer resources.
In fact I would argue that an argument could be made for Fine quality programs that run faster or on less sophisticated computers.

[Anthony]

Originally Posted by Refplace

In fact I would argue that an argument could be made for Fine quality programs that run faster or on less sophisticated computers.

It's unlikely to make a difference that's visible at the resolution of Complexity in GURPS.

[scc]

Originally Posted by Rupert

It's only now that we have stupid amounts of system memory and storage space, and code at a much higher level that this conflict doesn't really apply to most programming.

I don't think this really holds up, because as far as I'm aware we're still using C/C++ to program a LOT of stuff, probably most importantly web browsers, but they keep needing more and more memory

[johndallman]

Originally Posted by scc

I don't think this really holds up, because as far as I'm aware we're still using C/C++ to program a LOT of stuff, probably most importantly web browsers, but they keep needing more and more memory

Developers will (mostly) pay attention to performance and resource usage when they start causing problems, but not until then. If people keep buying bigger and faster machines, there's no pressure to put the work into making the code small and fast.

[Rupert]

Originally Posted by scc

I don't think this really holds up, because as far as I'm aware we're still using C/C++ to program a LOT of stuff, probably most importantly web browsers, but they keep needing more and more memory

They have to support more and more 'features', and be able to render more and more complex web pages. The current versions of HTML and scripting allow far more than you could do in 1995, but they need the browser to be able to understand the commands and render them. That means a bigger, and more power-hungry browser.

[RyanW]

Originally Posted by Anthony

They could also run on his phone; most of the processor requirements for games are also graphics.

Look to Dwarf Fortress for a counterexample. The program itself is tiny by today's standards, but it is procedurally intensive.

[Bruno]

Originally Posted by RyanW

Look to Dwarf Fortress for a counterexample. The program itself is tiny by today's standards, but it is procedurally intensive.

Every creature is simulated down to every tooth and toenail and a hell of a lot of organs. The entire world is detailed from the dawn of creation, tracking the lives and deaths of every creature down to game start (and beyond). Every dwarf has motivations, opinions, and preferences. It's crazy brilliant.