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.
In high school I wrote a program that would automatically locate roots of an equation. The assignment was to key in the formula and then sit through the output of a FOR/NEXT looking for sign reversals and unless you hit zero, go back over the range where the reversal occurred at a smaller step. I said screw that, and wrote a program the automated the process and used a stack like process to evaluate the list of sign reversals the initial sweep would locate. The math teacher always bitched me out because he thought I should have been staring at formulas in the textbook rather than running down to the computer room and actually putting them to work. But this time I impressed him and he posted my program on the bulletin board.
My first professional program that I wrote that impressed even me, was the one I wrote to process the phone billing tape for corporate headquarters. I had seen the other programmers get bogged down having to do support work every month on previous programs they had written and I vowed never to fall into that trap. To achieve that, I found already existing databases that other departments maintained and tapped into them for the information I needed. I made the processing a double pass, the first to collect charges and the second to divide them up. The "older and wiser" heads told me to just toss in constants, but I wanted something that would self adjust and never need maintenance. In the end, if the program couldn't figure out where a charge was to go, a human couldn't either. Elements that were not recognized were sent to an error report and through that we found the phone company had been over billing us about $5000.00 a month for years. But the feature that really makes me smile was when after I had left the company, they wanted to expand the number of facilities it would generate the department billing for. The person who inherited my program told them to just run the augmented tape through the program and he'd look through the error report to estimate what changes would need to be made. He called me afterwards to tell me the program did not need any changes, it figured it out by itself. I about flew around the room in happiness.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
The first code i wrote i'm proud of, is an invoice system that i made following almost to the letter the Object Oriented approach... in PHP, having said that, i would never ever do that again, it was a terrible experience given the quirks on the OO implementation of PHP, however, the system is easily extensible once you get to know any of the modules (they all look and work the same).