I love to hear stories about programming on those early computers.
Of course, similar functionality is built into most, if not all, modern operating systems. On Mac OS X it is very efficient with memory and maintains the memory of closed programs such that if you hit ⌘ + Q to terminate the process and then you relaunch the program it usually starts up almost instantly.
I don't think it maintains all the memory of closed programs - the data/stack areas of memory will differ hugely between when a program is closed and when a program is launched. If you did save all these areas of memory, the program's state would be exactly the same between opening/closing.
However, the disk blocks containing the executable program file are likely to be cached in memory after you open a program. Memory is orders of magnitudes faster than the hard disk, so this would explain the speedup
I understand this is meant to be humour, but it brings up a very important problem - the mapping between the profit from software and the processes that create it, and in some sense, measuring programmer productivity.
Here, though the program size was 0, the idea was what the cost was for - to come up with this idea, one has to have deep knowledge about the machine and about the way programs are executed on it in particular. One should also spend some brain power (and have the ability to do so) on how to use that to our advantage.
Now, imagine a program of say 100 bytes, whose idea was conceived by one programmer but the implementation written by another. Then, how would you divide the profit from the software among them (assuming you do that)? It perhaps depends on how detailed the idea was, how much thought had to be put in to implement it, how 'brilliant' or 'out-of-the-box' the idea and many other factors, almost all of which are qualitative.
In short, determining salaries and increments for programmers seems a very hard problem.
6 comments
[ 3.7 ms ] story [ 24.6 ms ] threadOf course, similar functionality is built into most, if not all, modern operating systems. On Mac OS X it is very efficient with memory and maintains the memory of closed programs such that if you hit ⌘ + Q to terminate the process and then you relaunch the program it usually starts up almost instantly.
However, the disk blocks containing the executable program file are likely to be cached in memory after you open a program. Memory is orders of magnitudes faster than the hard disk, so this would explain the speedup
Here, though the program size was 0, the idea was what the cost was for - to come up with this idea, one has to have deep knowledge about the machine and about the way programs are executed on it in particular. One should also spend some brain power (and have the ability to do so) on how to use that to our advantage.
Now, imagine a program of say 100 bytes, whose idea was conceived by one programmer but the implementation written by another. Then, how would you divide the profit from the software among them (assuming you do that)? It perhaps depends on how detailed the idea was, how much thought had to be put in to implement it, how 'brilliant' or 'out-of-the-box' the idea and many other factors, almost all of which are qualitative.
In short, determining salaries and increments for programmers seems a very hard problem.