The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
hahaahhah, perfect I wish I could vote you up.
That remember me when I was in high school back in my home country, in a very selected high school I pissed a friend of mine because I could write an algorithm finding the pithagoric numbers in less lines than him and he was so frustrated that he began making the hole program in one line, but the line was verrrryyy long,
Back in the 90s, I built a 3d tennis game in Java. I was so proud of myself seeing the tennis ball bounce around the court. For self-gratification, I did new TennisBall() about 20 times and just had all these balls bouncing around the court.
From that point on, I was hooked on writing software. I still enjoy it today.
Unfortunately my first decent code is lost forever. It was a game of Reversi/Othello running on a Tandy TRS-80 and which would fit into the default 4kB RAM (yes those are kilobytes). To make it fit I had to do an inordinate amount of variable re-usage and multi-purpose sub-routines, but it worked and could beat an intermediate player. If you gave it a couple of corner squares to start with it would beat anybody.
I remember paying £120 to upgrade the RAM to 16 KB so that I could write/run a business simulator - how times have changed... or have they?
My first "decent" code? Well that would omit all the programs I wrote to auto-generate porn using nothing but ASCII characters, wouldn't it?
But seriously, it's been so long that my first respectable code is lost to the mists of history, so I'll regale you with the earliest relevant story I can remember: Assembly-language programming on a Data General NOVA 1200.
At the time I worked for a division of General Instrument that no longer exists. It made and sold "payments processing" systems that employed some rather delicate proprietary electro-mechanical "workstations." The principal function of a workstation was to read a "turnaround document:" the sort of paper slip you'd detach from your phone bill -- carefully! You know how treacherous perforations can be! -- and mail back to the phone company with your monthly payment.
The workstation used OCR techniques which, for that era, were pretty sophisticated, but which nevertheless had only about a 90% efficacy rate. There were some turnaround documents the workstation just couldn't read, but which had to be processed anyway. So there was a second device in the system to cover that need: a "key entry station" or KES much like an ASR-33 teletype.
Of course, an operator keying in strings of digits from a turnaround document is even more error-prone than an OCR-capable machine. Therefore, part of the processing of KES input involved verifying it, using check digits buried in the account numbers on the document. There was a large, kludgy module built into the system for that purpose: large, because the system was a patchwork put together by many programmers over many years; kludgy, because none of the people who'd worked on it believed in commenting their code, and all of them feared to delete anything that might be important to someone else...even if it had been definitively obsoleted.
I was young and foolish, back then. I volunteered to redo that module, and was given the green light to do so.
It took awhile, as the NOVA 1200 was a very weak CPU: no hardware multiply or divide; only 32K 16-bit words of memory; only four registers; no hardware stack; and only four addressing modes, all of them extremely weak . Also, the module had to account for a range of check-digit and cross-verification techniques, from which each of our customers selected according to his preferences. But when I was finished, the module was smaller by 40% than its predecessor, and every instruction was commented in actual, legible English.
(Incidentally, there's no better way to pick up good coding habits than to write assembly language for a few years. Rigorous adherence to good practices is a matter of survival in assembler, and the habits remain with you lifelong.)
Feeling rather good about my work and myself, I turned it in to my supervisor and turned to the next task. I had no idea what would follow.
My co-workers were displeased, to put it mildly. In redoing that module, I'd committed two sins:
I'd deleted a lot of their code;
I'd compelled them to learn about my new approach to verification.
The pride and joy of my young programming career had made me massively and enduringly unpopular. I heard about it in no uncertain terms, from a few days after I submitted it to the day I left the company. There's a moral in there, somewhere.
(This message is programming you in ways you cannot detect. Be afraid.)
Just out of college, I wanted to use something from the data structures class so wrote a right-inthreaded binary tree structure by hand to handle a large data set. Each unique number went to it's own leaf with a count. In the end, I could traverse the tree, generating a histogram and various statistics, st dev, etc as desired. I think it was in HP Basic predating the PC era at our workplace.
My story is from a long time ago--probably 1989. I'd been hired by a small consulting shop as a COBOL programmer. My favorite language, however, was C and I worked it into my job as frequently as I could. In these days before Perl and Python, all of my quick knock-off "scripts" were C programs.
My day-to-day working computer was a Unisys 6000/30 running CTIX, Unisys' version of UNIX System V, and the accounting software. I was connected to it with a dumb terminal; others were connected by dumb terminals or PC's over serial cables.
The company charged meticulously for time spent consulting, including phone time. To make tracking that time easier, the boss had installed a phone system that tracked time on incoming calls, and when calls completed, sent the details to a serial printer. The trouble was, the paper would bind up in that printer all the time and calls would end up going uncharged. One day the boss was extra ticked off because the paper had been jammed up for days and no one had noticed.
Hm, I thought; it's a serial interface, and the printer was only maybe 8 feet closer to the phone box than the Unisys was, and I had three serial ports free. How about a daemon to poll the serial port and put the results in a file, and eliminate the serial printer? I proposed the idea to the boss and he allowed me to work on it on a low priority basis when client demands allowed.
So I figured out how to configure and read serial ports from C, and had my serial printer substitute available in two or three days. The boss and the girls in accounting were extremely happy about it. They requested me to write some utilities to look up particular phone numbers in the file and so forth, all of which I did in C. The cool part, though, was interfacing to the printer, back in a day when you couldn't just look up how to do things on the Net, but had to actually read the voluminous manuals that came with your system and piece the concepts together yourself.