with the standard amount of memory for a gaming machine for instance being about 2 gigabytes its not like your going to use the swap file unless you require photoshop quake 4 and 15 firefox windows open, while downloading enourmous files, and burning a dvd and watching tv simultaneously. but ram is so friggin cheap these days its not really an issue. better bandwidth between ram and cpu, and gpu should be a priority. look at the difference between pci and pci-e, its like 150% faster. what about hypertransport peripheral interfaces. thats the ticket. anyway eventually well reach a point where circuits cannot be manufactured any smaller, and there will be no more headroom for clockspeeds, at which point software will need to be coded more efficiently in the same way that console games are during the life of the system. 15 years max i figure.
As a person that has worked on (as in programmed) accounting and ERP software for a long time, I think you’re not giving QuickBooks Pro as much credit as it deserves, and maybe a little too much credit for the old accounting software.
But GUI, Help and lack of need to write compact code certainly are large factors.
No doubt I see the past through a rosy lens, but much of Quick Books’s help is online, not part of what’s clogging my drive. Well, not exactly MY drive yet. It’s still on the old purchasing guy’s box because I’m in a standoff with the network guy. He wants me to move to the other computer, saying Quick Books takes too long to install. I counter that may be so but since it usually takes several days to get Autocad installed and set up the way I want it… Suffice to say, I get some exercise running between desks, and some exercise is more than I used to get.
That would be the logical method of programming, certainly if small code size were a highly prized goal. But it’s not.
Just a WAG, but I think the separate paragraph formatting style may have its origin in the way coding teams are assembled. Joe is given the task of preparing the output for a single print line and Mary is charged with gathering Joe’s code into the output for one document. Mary is told not to mess with Joe’s code as long as it works, and Joe doesn’t look into her coding, either (he’s on to other tasks).
This method of team operation is reinforced with concepts like Object Oriented Programming, where Joe’s per-printline code becomes an object and Mary’s code just calls a series of objects; her code then becomes an untouchable object as well.
So I think such coding is driven primarily by economics of development costs.
They certainly do.
Years ago, working on a Mainframe Payroll accounting package, we provided primitive help screens. (Place the cursor on a data entry field, press PFK1, and a screen pops up replacing the current screen, giving help info on that field and what values are acceptable. Pressing End key redisplayed the original screen.) Just this restricted level of Help screens took a sizable amount of code, actually a significant percentage of the ‘working’ code of the application.
And this was on 3270 green-on-black text-only screens. Current GUI screens require a large amount of code to function, even taking advantage of the built-in OS logic. In an application like Quicken, it wouldn’t be surprising that this ‘presentation’ logic takes more code than the actual accounting code.
Twas always thus, which is why very large companies in the financial sector (which I know best) are all still running code on their mainframes (or simulating the code on other platforms) that is many years old (I’ve seen some 1960s code, there is a metric shitload of 70s and 80s code out there*). The risk for any serious business with a long tail to modify core corporate function and the accumulated knowledge inherent in the code base is scary, potentially a corporation killer.
- I worked for a few years for a company (about 15 million customers) whose absolute core stuff (banking transactions, stock market unit transactions, accountancy feeds) was based on a variable-record-length flat file. Algol is a great language, COBOL less so.
1.) A programmer’s machine specs have no bearing on whether he can write an efficient program.
2.) There are literally hundreds of free, simple, and powerful software programs that can replicate the functionality of memory-intensive “bloatware”.
3.) Unbridled from the inherent bloat of a certain OS, you may find that your machine can do things you never expected.
I think the problem for desktop software is that -
- Programmers are on a deadline to produce software
- Faster, resource-loaded machines help them reach the deadline faster
- Their employers have infinite resources to buy the latest greatest machines
- Therefore, software is developed on far more advanced machinery than the general public has at a given time, and developers do not know/do not care that their latest programming gem runs like a snail on average hardware.