Can someone tell me why on very old timers computers ha, a programmer could write up some code and it would be so small compared today. 500kb?
Can someone tell me why on very old timers computers ha, a programmer could write up some code and it would be so small compared today. 500kb?
Those were the days. Getting PCPro or PCPlus magazines with a 3 1/2-inch floppy disk packed with software! Even prior to that, you could fill a 5.25-inch floppy with heaps of software.
So many factors... programs were simpler, programming languages were limited in features and libraries were simpler and smaller, operating systems were less demanding. The fact hardware systems and the media that carried this software at the time was also very limited in storage and processing capacity also forced programmers to squeeze their code to the best of their abilities.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Beacuse they were very small people with small brains that could only fit small code inside their head. Seriously tho, your program can be as bloated as you want to make them. Reasons why modern sofware often takes up more space is down to many reasons. Ultimately storage space is not really an issue on computers nowadays so less time is spent worrying about it. Computers and programs are also way more complex now. Theres nothing stopping you from producing tiny programs in C tho.
Oh, I was actually looking at VB. It isn't like some kind of small text file, with your code and stuff.
Gates once said, 300+KB would be enough for anyone...
There's a resurge of sorts if you look at mobile phone programming. Very small apps, some bursting with functionality.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.
- Mike McShaffry
Yes, and at that time, it would have taken a senior software engineers yearly salary for several years to buy 1GB of RAM. The original IBM PC with 256KB (or was it 64KB) would set you back the best part of $5000. Of course, there was no hard-disk in that type of machine, that only came with the XT machines. My first PC had 8MB of RAM, and that was plenty to run OS/2 with gcc compiler, emacs and a few other apps with no problem.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Code was less abstract and more "to the metal." It was also necessarily less feature-rich, because features take space. Think about what was available: A disk, with a simple file system on it. A text based screen. A keyboard. Maybe a printer, maybe a modem.
A lot of the code size of today's applications is from layer upon layer of abstraction, which is designed to make the programmer's life easier in exchange for being bigger and slower. If you want to use the features (maybe only a small subset) of some library, you just link with it without giving it a second thought. In other times the design goals were opposite. With so little RAM available the emphasis was on small, tight code.
It's not that we couldn't write small programs today, we just don't bother anymore.
Sure. The reason given above explains what and why makes modern apps several hundred kilobytes (or even megabytes) when the corresponding application in olden days would have been a few kilobytes.
Many different flavours of hardware creates a need for a layer of software-to-hardware translation. Modern systems have more memory so there is no need to strip out and link statically to make sure that the application is small. Writing the code to write "Hello, World" inside a Window in MS Window will require something like (at least) 15-20 lines of rather cryptic code, or 50 lines of less cryptic code. Of course, turning that Hello World program into a bigger application that does some simple word processing will add about the same amount of code as it would to the 4-line console version.
Dealing with graphical UI's [in a nice and modern way] requires graphics resources to be compiled into the application, menu handling, dialog boxes, etc, etc. Where a console application could do that in a few lines of C or Pascal, it now requires a few more lines and a "resource" from a resource-file.
C++ also tends to add to the burden by making many layers of things.
But if needs be, almost all applications can be stripped into something smaller, simpler, and less flabby. At one time, working on a driver, I saved some 30KB [although not noticable in the overall size, it's a large amount in itself] by simply putting "static" in front of a bunch of const initialized data in functions - because the compiler will then only generate the data once, rather than storing the data and generating instructions to copy it into the local variable. Just as one example.
As a summary: Applications are bigger now because they can be, in PC's. If you are targetting an embedded system with 32MB of RAM, then having a single application that takes up 400MB won't work!
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Well, could you make a small 2D graphics program, like a bunch of squares. or triangles. One move around, and another animated or AI sort of thing and interact with the shape that is controlled by you? A small program.
Oh, I ment to say me. I am interested in trying to do something along those lines. A possible shooting game of shapes?
I started another thread elsewhere. In Gaming.
Right, thank you.
So...Um, could someone please direct me to a C compiler thing? Sorry people, I'm not familiar with the terms.
Um, then I can try writing out the traditional er... code thingi.