Nostalgia in Programming
-
flip the NEXT switch UP once to advance to the next memory location, enter the instruction using the 8 DATA switches, then flip the WRITE switch once to save it. ;P
Will Rogers never met me.
You young folks don't know how lucky you are. Why, when I was your age, a byte only had two bits -- and they were both 1s! Do you have any idea how hard it is to do floating-point arithmetic in Roman numerals? Ah, but the men were men in those days...
(This message is programming you in ways you cannot detect. Be afraid.)
-
Chris Maunder wrote:
What sort of relatively recent stuff (this was 10 years ago) did you used to have to do to get your apps to work?
Let's see. Because the database manager was an idiot, my manager and I had to create a skunk-works project to hide how we were doing things so it didn't take a week per table to write the update, insert, delete, select operations. I kid you not. Rewrote the "Application Coordinator" that this guy had put together taking up most of a year of his time. I rewrote it in a weekend, to the wrath of said developer and the envy of everyone else that had to use said developer's pile of dung. Needless to say, my team ditched this guy's code immediately, and we went on to be a productive, on time and on budget team. Along those lines, getting my team's app to work meant finding the right people, smart people, not dogmatic "design pattern" nincompoops that were running around the hallways touting Java and exclaiming "ooh, did you read about the Visitor Pattern?" On a personal note, getting my C++ apps to work meant realizing that "base class" was the top of the abstraction, not the foundation (and therefore the derived class) in a class hierarchy. I had to remove the "base of the pyramid" image from my understanding of OO. And lastly, solid architecture. And what that meant was, architecture that logged every keystroke, every mouse click, every button press, so I could tell the mostly good, honest, but sloppy people in the QA department, no, you didn't click on "Save", you clicked on "Cancel" to refute their claim that the app failed to save their document. Marc
Marc Clifton wrote:
And lastly, solid architecture. And what that meant was, architecture that logged every keystroke, every mouse click, every button press, so I could tell the mostly good, honest, but sloppy people in the QA department, no, you didn't click on "Save", you clicked on "Cancel" to refute their claim that the app failed to save their document.
Ooh, good idea. I was figuring on using the C# version of
UnhandledExceptionFilterHandlerfor ultimate deniability error-catching, and that's a good addition as well. Now I just need to work around C#'s "if anything but the main thread has an unhandled exception, terminate the thread and ignore it" methodology... -
Marc Clifton wrote:
And lastly, solid architecture. And what that meant was, architecture that logged every keystroke, every mouse click, every button press, so I could tell the mostly good, honest, but sloppy people in the QA department, no, you didn't click on "Save", you clicked on "Cancel" to refute their claim that the app failed to save their document.
Ooh, good idea. I was figuring on using the C# version of
UnhandledExceptionFilterHandlerfor ultimate deniability error-catching, and that's a good addition as well. Now I just need to work around C#'s "if anything but the main thread has an unhandled exception, terminate the thread and ignore it" methodology...SortaCore wrote:
if anything but the main thread has an unhandled exception, terminate the thread and ignore it" methodology...
Well, you could put try-catch's in your threads! And there is Application.ThreadException[^] as well. Marc
-
I was just daydreaming and thinking about the differences between the HTTP GET and POST verbs (OK, I'm a little tired, OK? The mind wanders) and I suddenly remembered a trick I had to do in the wee early days of the internet when posting article content. We used to have to split the content into small chunks before sending it in the form postback, and then rebuild it on the server end. What sort of relatively recent stuff (this was 10 years ago) did you used to have to do to get your apps to work?
cheers Chris Maunder
First Programmer: Back in the day, we didn't have Windows. A command-line was our only interface to the machine. Second Programmer: Command-line?!? You had a command-line?!? All we had was punch cards to input all of our code. First: Punch cards?!? You had punch cards?!? All we had was paper tape. Second: Paper tape?!? You had paper tape?!? We had to hand toggle switches on the front of the machine and hand assemble all of our code. First: Toggle switches?!? You had toggle switches?!? We had to wire wrap our 0's and 1's directly into the logic of the computer. Second: 1's?!? You had 1's?!? ;-)
-
I was just daydreaming and thinking about the differences between the HTTP GET and POST verbs (OK, I'm a little tired, OK? The mind wanders) and I suddenly remembered a trick I had to do in the wee early days of the internet when posting article content. We used to have to split the content into small chunks before sending it in the form postback, and then rebuild it on the server end. What sort of relatively recent stuff (this was 10 years ago) did you used to have to do to get your apps to work?
cheers Chris Maunder
Going back to the 90's I learned to program using a 16bit compiler for DOS which meant I had to deal with memory segmentation and near/far pointers. Needing to use pointers to have more than 64k of data (and when I was working with multiple 64,000 byte screen buffers this was inevitable) forced me to actually learn how to use pointers for things beyond the textbook standard linked list, etc.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Bet you were glad when they finally invented the wheel so beer trolly didn't spill as much beer. Jeez...
cheers Chris Maunder
If doing that in school counts I've entered code that way (68000 breadboard computer in an electronics class) and I'm 95% sure I'm younger than you are. :doh:
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
First Programmer: Back in the day, we didn't have Windows. A command-line was our only interface to the machine. Second Programmer: Command-line?!? You had a command-line?!? All we had was punch cards to input all of our code. First: Punch cards?!? You had punch cards?!? All we had was paper tape. Second: Paper tape?!? You had paper tape?!? We had to hand toggle switches on the front of the machine and hand assemble all of our code. First: Toggle switches?!? You had toggle switches?!? We had to wire wrap our 0's and 1's directly into the logic of the computer. Second: 1's?!? You had 1's?!? ;-)
Oh, good old days ^
-
I remember flipping switches when the machine we used for communications went down. I would get a call from the field and had to walk to the other side of the building and start the boot switching sequence.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopesI remember that about 30 years ago, the links to the UK JANet network (Joint Academic Network) used PDP11s as communications servers which needed half a dozen instructions toggled into the front panel to boot the main program. I used to be able to do it from memory! BOOM! BOOM! :-D
-
I was just daydreaming and thinking about the differences between the HTTP GET and POST verbs (OK, I'm a little tired, OK? The mind wanders) and I suddenly remembered a trick I had to do in the wee early days of the internet when posting article content. We used to have to split the content into small chunks before sending it in the form postback, and then rebuild it on the server end. What sort of relatively recent stuff (this was 10 years ago) did you used to have to do to get your apps to work?
cheers Chris Maunder
Long time ago...... programming a PDP 11/45 via the front console. Load an address and insert the octal instruction 014747. Then start running from the address you loaded the instruction (single stepping the execution is more fun!) The "program", a single instruction, will cause the computer to run "backwards" and fill memory backwards from the starting point with 014747 until it gives a hardware trap (address error.)
-
I remember that about 30 years ago, the links to the UK JANet network (Joint Academic Network) used PDP11s as communications servers which needed half a dozen instructions toggled into the front panel to boot the main program. I used to be able to do it from memory! BOOM! BOOM! :-D
StarNamer_ wrote:
I remember that about 30 years ago
It was the early 1970's and it was a PDP8 if my memory serves me correctly. It used to drop out a lot so I got pretty good at doing it also. :cool:
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
I have created a really complex and dynamic organizational chart using pure HTML Tables like a Boss! :cool: A giant table with crazy amount of pre-calculated
rowspanandcolspan, with even crazy amount of coding in picking the cell border colors (black or white). so that that whole madness will look like this[^] with really tiny scroll bars. It was in Classic ASP, and the only real alternative (that might not work everywhere) was to create an ActiveX control or Flash control and draw the whole thing. It was a network marketing company (like Amway) where members can see their complete network tree (people they have successfully infected/brainwashed). I am still proud of it. :-DRemind Me This - Manage, Collaborate and Execute your Project in the Cloud
Using Tables? OK, that's kinda cool.
cheers Chris Maunder
-
Yeah. And that's why Eclipse is mostly used for Java, the stick isn't that satisfying when you can't hold it from all the dirt. OT: Didn't knew you are on FarceBook.
I will never again mention that Dalek Dave was the poster of the One Millionth Lounge Post, nor that it was complete drivel.
-
flip the NEXT switch UP once to advance to the next memory location, enter the instruction using the 8 DATA switches, then flip the WRITE switch once to save it. ;P
Will Rogers never met me.
Reminds me of toggling in the bootstrap loader on the PDP-11/20.
-
I was just daydreaming and thinking about the differences between the HTTP GET and POST verbs (OK, I'm a little tired, OK? The mind wanders) and I suddenly remembered a trick I had to do in the wee early days of the internet when posting article content. We used to have to split the content into small chunks before sending it in the form postback, and then rebuild it on the server end. What sort of relatively recent stuff (this was 10 years ago) did you used to have to do to get your apps to work?
cheers Chris Maunder
Giving away my age ... I started wiring boards for EAM (look it up) equipment. The trays of cards (80 characters each) were diagonally marked (magic marker) in case the cards were dropped...ugh. When I graduated to an 8k 1401, the 80 character boot strap area (programs loaded from cards - no OS) was hard wired to the card reader and the next 132 characters were hard wired to the printer. It made for interesting issues when additional code was required in the middle of run: code had to be interspersed with data cards. To top that off, I worked in a large display window on Madison Ave, since IBM liked to show off their equipment. The first communications project I worked on used punched card readers for remote input and IBM Selectric typewriters as output devices. It ran on a dedicated 360/40 256k mainframe with 24k of OS and 3-28 mbyte disk drives. You had to watch the register lights on the console to "see" if the system was in a tight loop. Using current IDEs (VS2013 and Eclipse) and targeting various device types, I don't miss the "Good Old Days" at all. The most agile activity back then was trying not to trip on cables. Abbott Fleur
-
I was just daydreaming and thinking about the differences between the HTTP GET and POST verbs (OK, I'm a little tired, OK? The mind wanders) and I suddenly remembered a trick I had to do in the wee early days of the internet when posting article content. We used to have to split the content into small chunks before sending it in the form postback, and then rebuild it on the server end. What sort of relatively recent stuff (this was 10 years ago) did you used to have to do to get your apps to work?
cheers Chris Maunder
Let's see, I've never done embedded programming so my limitations weren't too bad. On the PDP-11/20 running RSTS with BASIC-Plus, you had an 8KB address space for your program and data. Since it was interpreted, code comments took up space and thus were discouraged. Variable names weren't a space issue since they were limited to upper case letters A-Z, optionally followed by a digit, optionally followed by a type indicator: No type indicator was a floating point number, a type indicator of '%' was a 16 bit integer, and a type indicator of '$' was a string. Given the address space limitations, most programs were broken into one or more data entry programs which interacted with the user, did limited data validation, wrote the input data into a temporary file, and then passed control to another program, using the "CHAIN" keyword, that did additional validations, including file-based validations, and if everything was OK, updated the actual production data files. If there was a data problem, the program would CHAIN back to the data entry program with a link to a temporary file that had information about what was wrong with the data. The file system was equally primitive. You read and wrote 512 byte blocks of data from/to the disk. The rest was up to the developer. Some people wrote indexes which lived in separate files and sped up access. I wrote a hash-based lookup with collision detection and handling.
-
Giving away my age ... I started wiring boards for EAM (look it up) equipment. The trays of cards (80 characters each) were diagonally marked (magic marker) in case the cards were dropped...ugh. When I graduated to an 8k 1401, the 80 character boot strap area (programs loaded from cards - no OS) was hard wired to the card reader and the next 132 characters were hard wired to the printer. It made for interesting issues when additional code was required in the middle of run: code had to be interspersed with data cards. To top that off, I worked in a large display window on Madison Ave, since IBM liked to show off their equipment. The first communications project I worked on used punched card readers for remote input and IBM Selectric typewriters as output devices. It ran on a dedicated 360/40 256k mainframe with 24k of OS and 3-28 mbyte disk drives. You had to watch the register lights on the console to "see" if the system was in a tight loop. Using current IDEs (VS2013 and Eclipse) and targeting various device types, I don't miss the "Good Old Days" at all. The most agile activity back then was trying not to trip on cables. Abbott Fleur
I worked on an IBM 360/40 with 256k core memory. There were a few disks, but a majority of our work was done with tape. Do you remember how to do a master file update with the master on one tape drive and the updates on another tape drive with the new master going to a third tape drive? Needless to say, I preferred the PDP-11/20 I mentioned in another post.
-
Long time ago...... programming a PDP 11/45 via the front console. Load an address and insert the octal instruction 014747. Then start running from the address you loaded the instruction (single stepping the execution is more fun!) The "program", a single instruction, will cause the computer to run "backwards" and fill memory backwards from the starting point with 014747 until it gives a hardware trap (address error.)
The idle loop on RSTS would make the console lights cycle in a clockwise direction. You could tell how busy the CPU was by watching to see how often and how long the idle loop display was interrupted. Once the system was down for a hardware failure, so we wrote and toggled in our own "idle loop", except it cycled the console lights in a counter-clockwise direction. We waited as other developers came into the computer room to see why they couldn't log on. Only one developer figured out there was a problem by simply seeing the console lights cycling backwards. The rest asked us if there was a problem.
-
I was just daydreaming and thinking about the differences between the HTTP GET and POST verbs (OK, I'm a little tired, OK? The mind wanders) and I suddenly remembered a trick I had to do in the wee early days of the internet when posting article content. We used to have to split the content into small chunks before sending it in the form postback, and then rebuild it on the server end. What sort of relatively recent stuff (this was 10 years ago) did you used to have to do to get your apps to work?
cheers Chris Maunder
Chris Maunder wrote:
What sort of relatively recent stuff (this was 10 years ago) did you used to have to do to get your apps to work?
Boot Windows with NUMCPUS=1 on an early dual core machine so our video recording software would continue to work when we stopped recording the audio. Oh, and the OS happily ignored the directive and ran itself and our software on both CPU cores anyway, but only with NUMCPUS=1 did our software run correctly.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
I worked on an IBM 360/40 with 256k core memory. There were a few disks, but a majority of our work was done with tape. Do you remember how to do a master file update with the master on one tape drive and the updates on another tape drive with the new master going to a third tape drive? Needless to say, I preferred the PDP-11/20 I mentioned in another post.
I left off that I was a 7094 tape jockey (in the same window). That was a 32k machine with a card reader the size of a very large generator and 14 tape drives. It billed out @ $700/hr. The OS (IBSYS) was on 1 tape. IBM did all their 360 simulations on the 7094. To make life a little easier we had a utility program (on 1 card) that rewound all the tapes at once so we didn't have to walk around and do it by hand.
-
StarNamer_ wrote:
I remember that about 30 years ago
It was the early 1970's and it was a PDP8 if my memory serves me correctly. It used to drop out a lot so I got pretty good at doing it also. :cool:
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopesI was at Manchester University in the Physics Department from 1978 to 1986 as a Research Associate so it would have been either 1979 or 1980 and it was definitely a PDP-11 that we had. I also used a PDP-8 (and a PDP-10) in 1974/5/6 as an undergraduate at Oxford. Also a PDP-7, a PDP-9 and a PDP-15 while at Manchester. All of them were 'proper' computers with a panel of lights and a row of toggle switches!
