3 ms·

> "it has taken more than two weeks for the result to come back" That sounds exceptionally long for that era. I didn't easily find hard numbers. https://spira

> "it has taken more than two weeks for the result to come back" That sounds exceptionally long for that era. I didn't easily find hard numbers. https://spiral.imperial.ac.uk/bitstream/10044/1/35672/2/Newland-J-1981-PhD-Thesis.pdf https://spiral.imperial.ac.uk/bitstream/10044/1/35672/2/Newl... (in a student environment in 1981) shows a turn-around from 20 minutes to 6 hours. See page 123 table 4.1. Also in a student environment, early 1970s, https://ir.library.oregonstate.edu/downloads/8g84mp855 https://ir.library.oregonstate.edu/downloads/8g84mp855 "Batch turnaround time averages somewhat less than a hour with a range of one-half to three hours." At The Rand Corporation in 1974, "Normal batch turnaround for jobs run during the day had averaged 30 minutes for quite some time." - https://dl.acm.org/doi/pdf/10.1145/1500175.1500305 https://dl.acm.org/doi/pdf/10.1145/1500175.1500305 More generically, "Turnaround time may take minutes, hours, days or even more than a week before completed outputs are returned in response to job requests." - https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 . Two weeks therefore sounds very much like an outlier. > "Meanwhile, another engineer programming in Smalltalk and Interlisp is writing and running their implementation directly against a system console." Or BASIC, developed in in 1964 along side with the Dartmouth Time Sharing System. For example, by 1975, the HP 2000F was "the first minicomputer to offer time-shared BASIC", and it supported Fortran and other languages besides BASIC. https://en.wikipedia.org/wiki/HP_2100#HP_2000 https://en.wikipedia.org/wiki/HP_2100#HP_2000 Python is the modern BASIC. Also, note that interactively starting a long job (eg, compiling a large FORTRAN program) only saves the manual batch submission overhead. The compilation might still take time to run, especially if it requires system resources that aren't currently available so is still put into a queue. > Forget about a “10X programmer”, how about a “10 000X programmer”? That is not supported by the research. See https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 for one summary of several papers comparing batch vs. online computing. The Grant-Sackman paper is the only of those using professional programmers instead of students. The summary is "Time-sharing requires fewer man-hours to debug programs for highly experienced programers than a simulated batch system with a two-hour turnaround time." (19.3 hours instead of 31.2) and "Individual performance differences in 3 highly experienced group of programers are considerably larger than observed system differences between time-sharing and batch processing"

vidarh 5y ago
> That is not supported by the research. See https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 for one summary of several papers comparing batch vs. online computing. Of course the 10 000X is skewed heavily by the presumption of a 2 week turnaround time. But I also think people who haven't experienced anything close to batch programming don't appreciate how much you could do on paper. I used to bring printouts of code to school with me so I could work on my programs during free periods and breaks, and it was highly productive, though of course not comparable to sitting in front of the computer.
astrobe_ 5y ago
To add to your comment, the intro immediately reminded me that Forth was born even earlier than 1975, to solve the same punch card problem: "The programming environment in the 50s was more severe than today. My source code filled 2 trays with punch cards. They had to be carried about to be put through machines, mostly by me [Chuck Moore, the inventor of Forth]. Compile took 30 minutes (just like C) but limited computer time meant one run per day, except maybe 3rd shift. So I wrote this simple interpreter to read input cards and control the program. It also directed calculations. The five orbital elements each had an empirical equation to account for atmospheric drag and the non-spherical Earth. Thus I could compose different equations for the several satellites without re-compiling." [1] I therefore take issue with the statement in TFA: "This notion of reducing accidental complexity to the bare minimum is the key to a lot of our problems, and there is no greater champion of this principle than Niklaus Wirth." As far as "bare minimum" goes, the true champion is Chuck Moore, no question asked. He eventually embedded the essence of his language in 144-cores chips [2]. The thing was designed by a CAD program he made with his language, too. This is actually the last chip of a series of "Forth chips" that did better than "Lisp machines" or the various similar "<language> chip", because a derivative of one of his designs, the RTX2010, has visited a comet not long ago. [1] https://colorforth.github.io/HOPL.html https://colorforth.github.io/HOPL.html [2] http://www.greenarraychips.com/index.html http://www.greenarraychips.com/index.html [3] https://en.wikipedia.org/wiki/RTX2010 https://en.wikipedia.org/wiki/RTX2010

vidarh 5y ago

> That is not supported by the research. See https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 for one summary of several papers comparing batch vs. online computing. Of course the 10 000X is skewed heavily by the presumption of a 2 week turnaround time. But I also think people who haven't experienced anything close to batch programming don't appreciate how much you could do on paper. I used to bring printouts of code to school with me so I could work on my programs during free periods and breaks, and it was highly productive, though of course not comparable to sitting in front of the computer.

astrobe_ 5y ago

To add to your comment, the intro immediately reminded me that Forth was born even earlier than 1975, to solve the same punch card problem: "The programming environment in the 50s was more severe than today. My source code filled 2 trays with punch cards. They had to be carried about to be put through machines, mostly by me [Chuck Moore, the inventor of Forth]. Compile took 30 minutes (just like C) but limited computer time meant one run per day, except maybe 3rd shift. So I wrote this simple interpreter to read input cards and control the program. It also directed calculations. The five orbital elements each had an empirical equation to account for atmospheric drag and the non-spherical Earth. Thus I could compose different equations for the several satellites without re-compiling." [1] I therefore take issue with the statement in TFA: "This notion of reducing accidental complexity to the bare minimum is the key to a lot of our problems, and there is no greater champion of this principle than Niklaus Wirth." As far as "bare minimum" goes, the true champion is Chuck Moore, no question asked. He eventually embedded the essence of his language in 144-cores chips [2]. The thing was designed by a CAD program he made with his language, too. This is actually the last chip of a series of "Forth chips" that did better than "Lisp machines" or the various similar "<language> chip", because a derivative of one of his designs, the RTX2010, has visited a comet not long ago. [1] https://colorforth.github.io/HOPL.html https://colorforth.github.io/HOPL.html [2] http://www.greenarraychips.com/index.html http://www.greenarraychips.com/index.html [3] https://en.wikipedia.org/wiki/RTX2010 https://en.wikipedia.org/wiki/RTX2010