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.
[QUOTE=dropzone]
Like I said earlier, Quick Books Pro has neither bells nor whistles, yet it’s GARGANTUAN for what it does. Maybe writing tight code is expensive but so is the typing, the mere putting of code into the programmers’ computers, and if they write a million lines of code when ten thousand will get the job done that is a waste.
Look. This software is just another basic accounting system. People have been writing these for decades and the only real difference between Quick Books and something written in interpreted BASIC thirty years ago is the GUI. The speed is even comparable if the old one were running on a hard drive.
[/QUOTE]
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.
[QUOTE=Chronos]
On the question of formatting information for different paragraphs, here’s an idea… Why not only put in the formatting information when the user actually changes the formatting?
[/QUOTE]
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.
[QUOTE=RaftPeople]
But GUI, Help and lack of need to write compact code certainly are large factors.
[/QUOTE]
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.
[QUOTE=Musicat]
driven primarily by economics of development costs.
[/QUOTE]
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.
[QUOTE=Musicat]
Programmers, since time=money, tend to work on the fastest, biggest capacity computers so their development cycle is short. Unfortunately, the average user for their software rarely has such a dream machine.
It is my opinion that programmers should be forced to use the slowest, smallest machine around instead. This way, they would feel the pain they are infllicting on their customers and would tend to take steps to optimize the code.
Also, the programs they write are typically compiled for the fastest, newest machine & opsys. Rarely do they absolutely need the features in XP vs. 98, for example, but since that is the platform they wrote it for, that may be the only platform it runs on.
There’s an awful lot of baggage to a 65 million color GUI when a simple text-based display would be adequate for many tasks.
[/QUOTE]
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.