-
The students' programs would then be run in batch mode and the output delivered back to the classroom. The students had quite an anxious wait to find out if their program had run successfully, or if the line printer output just said "Syntax error at line 70". A mistake in your program would lead to a wait of several days before you could try again.
Not just students with the slow turnaround. My first programming job, the computer was busy all day with production work and all development was run by the night shift. So we had one shot per day to get a program working. It was normal to have 10 or more programs on the go at the same time. The day would start by looking at the night's output. Fix syntax errors first, they were the most obvious. Then look at all the test runs, fix the logic errors. If there was time after that, continue writing the next program.
Some of the programs were epic. One I wrote was 7000 punch cards, 3-1/2 card boxes and took several minutes just to read in. This was in the days of batch processing. The program took input from another program that supposedly validated user input - valid dates in date columns, reasonable values in numeric columns etc. The program took this input and validated it against numerous random access files, did some processing and passed it on to the program that updated files.
One night, a card was missing from the deck (unexplained). This resulted in the library definitions of two files to not be copied in, so the compiler flagged errors. Since almost every line of the program dealt with one or other of the files, the resulting error list was HUGE. We put the printout in the back of a utility, weighed the end down with a rock and drove until it was all laid out on the road. it was quarter of a mile long.
What was interesting, that program occupied less than 64kbytes memory. IIRC it had multiple overlays (a precursor of virtual memory that was explicitly programmed) and every time it was changed it was necessary to shuffle things so it still fitted into the available memory.
It took many programmers most of a year to get that suite of programs into operation. When it was finished, it cut production costs so much it saved the cost of development in less than a year.
Memories, sweet memories. I still do programming for 'fun'. The current project is about 4000 lines and if it takes more than 5 seconds to compile I'm wondering what else was happening to slow it down. The good old day weren't that good. -
Typing in a Basic program from a journal was an odd way. I did it, but not very often, and not much basic. I remember that there was a short program for the C64 to also type in binary files with some check-sums.
It's nearly 20 years I last wrote a Basic program (some simple data-logging). It brings back memory.
Modern compilers tend to be relatively slow - this is in part from C and related languages with the program split over many files, plenty of libraries and #defines, but also with more optimization. With respect to compiler speed the Borland turbo pascal and related are really nice.
There is also a positive side if the turn around cycle is a bid slower - it forces to take more care and write correct code from the start. In some respects µC programming is a bid like with the computers in the 1980s. -
[...]The good old day weren't that good.
Hardware is powerful enough now that we've gone full circle- interpreted languages such as BASIC, Python are getting popular (FORTH I will leave out).
The main thing an interpreted language offers is run-time error checking. Instead of the shit that is C and C++ where you can punch a hole in an OS with an bad array index, or a buffer overrun inserting your favorite trojan, even antique BASIC spit out an error message and a programmer would know their code went past some limit for a variable. -
Instead of the shit that is C and C++ where you can punch a hole in an OS with an bad array index...
Let's not exaggerate. There is no modern OS where this is possible. Memory pages have access protection at the hardware level and you cannot corrupt system memory from user space by writing to wrong memory addresses. You can write the crappiest program you like with complete confidence. The worst that will happen is that your program will crash.
(The exception would be a simple microcontroller system like an Arduino, but then it is not running an OS either.) -
Windows 10 "Page Fault In Nonpaged Area" and a BSOD. The hardware can catch it but the OS bungles it.
We've had decades of blue screens, I don't think I'm exaggerating as far as modern personal computing still plagued by a rogue programming language.
To this day we have buffer overruns as a security problem. At some point we need to acknowledge some programming languages are dangerous and not improving, instead relying on expertise.
As far as retro-computing, learning it should be fun- not some venture into frustration that causes kids and noobs to dislike programming.
BASIC as an antique language- slower, easier to learn and safer than C, C++ lol.
-
Windows 10 "Page Fault In Nonpaged Area" and a BSOD. The hardware can catch it but the OS bungles it.
How can that happen from user mode? i.e., how can writing to a memory address from a C/C++ program cause such a driver error? -
Hardware is powerful enough now that we've gone full circle- interpreted languages such as BASIC, Python are getting popular (FORTH I will leave out).
The main thing an interpreted language offers is run-time error checking. Instead of the shit that is C and C++ where you can punch a hole in an OS with an bad array index, or a buffer overrun inserting your favorite trojan, even antique BASIC spit out an error message and a programmer would know their code went past some limit for a variable.
Complied code can also catch runtime errors. It is just a question of the compiler / settings. The extra checks take a little extra time and memory - today this should be not a problem at all. Pascal compilers usually did runtime checks by default, while C compilers usually did not - in part because things like overflow are "normal" with C. The C style strings were a bit error prone and hard to check. Pascal was more written for learning - stricter type checking and more checks.
I initially liked Basic and Arex (a kind of Python predecessor on the Amiga), but now I miss the error checks done by the compiler. Especially with a longer program it is a big no go if a rarely used routine fails because of a syntax error
. Compiler warnings are also really nice.
-
Windows 10 "Page Fault In Nonpaged Area" and a BSOD. The hardware can catch it but the OS bungles it.
If you can write a user mode program that does that without elevated privileges you can submit a bug report to Microsoft. That would be a serious security vulnerability in Windows and they would in due course roll out a patch to fix it through Windows updates.
Such a thing could happen due to bugs in a device driver, but unfortunately there you are at the mercy of the hardware vendor. Unlike Apple, Microsoft does not control the hardware platform, and if the hardware screws up you cannot do much about it except to replace or reject the faulty hardware. -
Quote from: rfclown
...to prank friends. I hooked the cassette on/off relay to the phone line to pulse dial. Then I'd program it to dial a friend's number after a long delay, and keep dialing every few minutes.
Is it still running? cos I'm getting get those calls every day...