Came across this article today. While I have not had to do all the things on the list, many of them do make me cringe.
Have you ever:
1) written your own sort method?
2) debugged code with tons of 'goto' statements?
3) managed memory with 'malloc' and 'free' statements?
4) Dropped a box of punch cards and spilled them all over the floor?
What coding 'techniques' do you not miss the most?
Never ascribe to malice that which can be adequately explained by stupidity.
I've only been doing this for around 10 years, so I did not experience many of the techniques in the article. However, I do not miss this:
fred rosenberger wrote:
3) managed memory with 'malloc' and 'free' statements?
or trying to figure out who didn't null-terminate a C string and is clobbering code somewhere in the build, then writing a StringBuffer-esque library to eradicate that problem.
I also don't miss the lack of information. If one ran into a problem that wasn't in the manual or in one of the guru's minds, it was hack-and-pray until one got something to work. Now, the solution to pretty much any problem is just a quick Google away.
Having been writing code for over 30 years, yeah, I've done it all. Including the anguish of the dropped box of cards (a multi-thousand line FORTRAN programs to simulate the stock market).
I have been coding seriously for only about 25 years. I have hand-written hashtable-like things that are currently in production. I've written many sort routines. I've written "malloc" and "free" and friends, and had them go into production.
I wrote DOS TSRs. I wrote Windows 3.1 TSRs. I wrote a boatload of INITs for early Mac systems.
I wrote printer drivers for a TWENEX system.
I wrote plenty of self-modifying code back in the day. I've hot-patched software.
I wrote a virtual machine and an associated interpreter for ANSI C: then Java came out.
I've written code that writes code that writes code. That's not exactly "old school", but it's the thing I've done that most nearly caused my brain to explode.
fred rosenberger wrote:
2) debugged code with tons of 'goto' statements?
4) Dropped a box of punch cards and spilled them all over the floor?
For a while, the preferred way to write Fortran was to use FLECS or ratfor, each of which used millions of goto to make Fortran look like a nice structured langiuage. You would get two goto per indented block of code which if you look at typical C/Java is every line or two of source.
On the dropping a box of Hollerith cards, you bet. For the hard core, columns 73 to 80 were unread, so you could punch in sequence numbers. If your box had sequence numbers, it was trivial to go over to the card sorting machine, do a pass, and get them back in order. The problem was that you had to leave "sufficient" sized gaps in the sequence so you could insert new cards as you debugged. Guess too small, and you had a real problem.
My biggest mental brain breaker was single step debugging of DDT. DDT was the machine instruction level debugger on Twenex machines. Debugging user programs with DDT was a standard skill. But debugging DDT itself was a challenge, single stepping into DDT as it single stepped through machine code.
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Wrote a sorter that looked at the number of elements and used either a heap sort, a quick sort or a bubble sort.
Wrote a memory allocation/usage library that accessed main memory, extended memory, expanded memory and a disk cache transparently. It wasn't quite a malloc()/free() drop in.
Wrote DOS TSRs. No Mac inits.
Wrote a couple programs (but not device drivers) for a TENEX system.
Wrote a PDP-11 linker. ...in machine code. Not assembly... machine.
Wrote some self modifying code that output a DOS .BAT file.
Written in COBOL, SNOBOL, Lisp, APL and Pascal. Mmm... APL nothing better than domino character/operator to do linear regression (if I recall correctly).
Never dropped a box of cards.
W. Joe Smith
Ranch Hand
Joined: Feb 10, 2009
Posts: 710
posted
0
I once wrote a program that changed the color and text shown on a button. In Visual Basic.
With less than 2 gigs of ram.
Man, that was rough.
SCJA
When I die, I want people to look at me and say "Yeah, he might have been crazy, but that was one zarkin frood that knew where his towel was."
My first work project was a PDP-11/44 memory diagnostic. Because the code had to test the memory in which it itself resided, the code would copy itself into registers a piece at a time while patterns were tested in the memory where it used to reside.
That was almost as much fun as the micro-code firmware diagnostics for the VAX-11/750 processor.
After working in diagnostics for 5 years, I transitioned into "true software" development (DECforms project, to be specific) and the code got much less, er, "interesting".
Edit: Good lord! In poking around the DECforms pages (now owned by HP through Compaq which bought most of DEC) I found this manual which is relatively unchanged from when I first wrote it over twenty years ago (a design guide for GUI interfaces on character cell terminals that predates HTML by a number of years).
Maneesh Godbole wrote:On a more serious note, what is "self modifying code" and "code that writes code"? This sounds positively interesting. Is this some AI stuff?
Not really AI. Any compiler is at one level code that writes code. But the point is generally code that modifies itself to do something better.
It makes debugging the code a real bear, as what is executed isn't what the source code looks like. It was popular when hardware was expensive and programmers were cheap. That's completely gone (except in very special areas) so for the past twenty years, and for sure since Java and other interpreted languages, computers are cheap, and programmers are very expensive, so easier to write and easier to debug code is valued.
There was a time when programmers would reuse the same instruction space. Or jump into data structures.
Fortran's computed goto is a simple variant on it. And the classic spoof of it is the Datamation article on the
On a more serious note, what is ... "code that writes code"?
The most common form are probably code generators. One example would be tools like lex/yacc that generate code to parse text files from a specification. In the pre-ORM days I wrote an application that would generate Java source code to access DB tables, based on all the table and attribute information available through JDBC, with all the additional code we needed our DAOs to have.
XDoclet was a popular Java tool for doing this kind of stuff. See http://www.codegeneration.net/ for some more information on the topic in general.
I can remember when you booted a system by toggling the machine code for the loader into the system with a series of switches (the pink and purple ones) on the front of the system. It only took doing it a couple of hundred times before you memorized the sequence.
Note that the switches are organized (by color) in threes because, of course, you thought of everything in octal.
fred rosenberger wrote:Boy, I remember those machines. My dad's office had 3-4 cabinets like that. I thought they were the coolest looking things ever.
The DEC PDP-10 KI had the coolest console of any machine I used. This was the next to last PDP-10 model, it had zillions of buttons, lights and switches. When DEC designed the KL model, they discovered that the price of the buttons, lights, switches and wiring them up cost more than a PDP-11/40. So they used a PDP-11 as the console. No more blinking lights. It was the end of an era.
Maneesh Godbole wrote:This thread should be deleted...immediately.
Reading it is giving us greenhorns an inferiority complex.
Oh, I don't know... 10 years from now people are going to be talking about EJBs in exactly this way.
Bert Bates
author
Sheriff
Joined: Oct 14, 2002
Posts: 8712
posted
0
We had a PDP-8 (I think it was an 8), in high school. Our programs were stored on 9-hole ticker tape - sometimes we could edit a program by cutting the tape, removing or rearranging a piece or two, scotch-taping the pieces back together again, and punching holes thru the taped areas where holes had been covered by tape. I actually kind-of miss that
I remember thinking that "gosub" was pretty cool!
I remember the "cold-start" h-card for an IBM-1130 had so many holes in it, it would frequently get mangled when it was read.
I remember swapping 15 lb., 15" inch diameter, 8 inch high, 10 megabyte hard drives.
I remember opening up the 1130's cabinet and seeing actual "core"... and then upgrading from 24k to 32k of core.
I remember hating when your program started with line numbers like: 10, 20, 30, 40... and ended up: 10, 20, 31, 32, 33, 34, 35, 36, 40...
Okay, last one, I remember when I was learning C my boss told all of us programmers that using a goto could be grounds for firing!
Eliminate fossil fuel subsidies. (If you're not on the edge, you're taking up too much room.)
Brian Legg
Ranch Hand
Joined: Nov 07, 2008
Posts: 488
posted
0
Bert Bates wrote:I remember hating when your program started with line numbers like: 10, 20, 30, 40... and ended up: 10, 20, 31, 32, 33, 34, 35, 36, 40...
Okay, last one, I remember when I was learning C my boss told all of us programmers that using a goto could be grounds for firing!
In Basic my programs always ended up like: 100, 200, 250, 255, 260, etc.... (always left plenty of room )
Your boss was a smart man Bert
I don't think I can compete with any of you.. I started playing with IT with my first pc. I don't remember what it was but it had win 3.1 that you had to run from the DOS prompt. I started coding in QBasic with line numbers and goto statements and my freshman year of high school I bought my first laptop, a very heavy, hot, Toshiba with 8MB HD and less RAM then it takes me to open calculator on my current pc. I bought it so I could type code into notepad for later instead of having to hand write it in a notebook.
On the topic of "self modifying code" -- this was commonplace with programmers working in assembly. I used it when I worked in assembly too. However, I was never really a fan of it. I have friends (then colleagues) that used it for *everything*.
I still remember one of them coming into my office, asking for help in debugging an issue -- he had a routine that works fine on the 8088, but didn't work on the new 80286.
It was basically a graphics routine that calculated a pixel and drew it. It has a parameter that specified how to draw it -- whether you wanted the pixel AND, OR, or XOR with the background. But this parameter wasn't like "set ax to 1 for OR, set ax to 2 for AND, etc". It was wierd. Set ax to a very specific number for OR, etc. I looked at my friend, without having to scroll down to the code yet, and said... let me guess. that's the op code for OR. that's the op code for AND....
Anyway, after an hour of debugging, the issue was... the fetch cache for the 286 was longer than for the 8088. So, when he self modified the code, it didn't take at certain locations, because those locations were already fetched into the cache.
Having a language with an actual finite number of commands usually about 300 at most, that after a year you would have fully memorized.
Mark
There is a bit of nostalgia here. With smaller number of commands, you have to write a lot more "commands" (functions), in order to do something useful. Obviously, it is much easier to remember these functions, because you wrote them. But when you change jobs, and use someone else's lib, you have to relearn everything.
Of course, this is moot, as it's unlikely that your new job will be using the same programming language...
Having a language with an actual finite number of commands usually about 300 at most, that after a year you would have fully memorized.
I don't follow this at all. What are commands in a language? Java has maybe 10 verbs: if, while, switch, etc. Very few high level languages have many more.
I've never seen a language constrain the number of variables you can name (altho embedded systems may not have the RAM to use them). When programming in a macro or assembly language, you might have 300 opcodes, but they are fairly easy to remember.
I loved BLISS. It was a much better language than C (IMHO), but it fell from favor.
Bert Bates
author
Sheriff
Joined: Oct 14, 2002
Posts: 8712
posted
0
Anyone ever hear of TIRS? (The Integrated Reasoning Shell).
Back in the early 90's TIRS was one of IBM's expert systems languages, it ran on OS/2, AIX, and some 360 OS.
It was clean, "reduced instruction", powerful, and fast, fast, fast. I wrote a bunch of systems using TIRS, including the piece of software I'm most proud of in my career.
Brian Legg
Ranch Hand
Joined: Nov 07, 2008
Posts: 488
posted
0
I spent 3 years coding in Euphoria, which was actually a pretty good language. Too bad it has/had about 0% usability in the real world.
Bert Bates wrote:I remember hating when your program started with line numbers like: 10, 20, 30, 40... and ended up: 10, 20, 31, 32, 33, 34, 35, 36, 40...
On the Commodore 64 there were programs that could automatically renumber all the lines (and all the references to the line numbers ofcourse) in your BASIC program, so that you could get it back to 10, 20, 30, 40, ... again after adding lines in between.
0
You mean, 10000110011101.. I remember calling assembly language as a foreign language during my graduation days. 
Those codes are like a airy shots. 
)
but for me, it more like an stereo tape with more than required play/pause buttons 
