|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: 2 days ago @ 9:51 AM
Points: 1,891,
Visits: 936
|
|
The first software that impressed me and caused me to consider entering the field was the Apollo Guidance Computer functionality. The AGC became famous as the computer or set of computers that performed the navigation etc... for the Apollo 11 Lunar Landing and other activities. The functionality of the computer was so advanced for the time that it boggled the minds of geeks across the globe. That was in 69 when science fiction became reality.
I started programming in 1971 and since then I have programmed on multiple platforms, in 15 - 20 different computer languages and have loved every bit of it. Programming and data are still fascinating me today, and every program, research project, or even report is an adventure.
Not all gray hairs are Dinosaurs!
|
|
|
|
|
Right there with Babe
      
Group: General Forum Members
Last Login: 2 days ago @ 6:54 PM
Points: 721,
Visits: 1,375
|
|
pdanes (2/22/2013)
Bill Wehnert - The Tom Swift books (I had a set, too) weren't written by Asimov. http://en.wikipedia.org/wiki/Tom_SwiftI've been a gadget-geek all my life, since I was a little kid, dismantling mom's vacuum cleaner to see what made all the noise (and then getting in trouble for not putting it back together - once I learned what was inside, I was no longer interested). My first experience with computing hardware was mechanical Marchant calculators, in the university physics labs where my father taught. Then came an electronic calculator with a CRT display a couple of inches square, about the size of a large typewriter and weighing considerably more. It could add, subtract, multiply, divide and remember one number. No square root. The first experience with real programming was a beginning Fortran course, at the university again, after a Vietnam-era tour in the Marine Corps. Univac 9300, 32KB of magnetic core memory, punched 80-column card input - the university's sole computer. Everything in the school ran on it, and students were given one run per day, in the evening, to hand in their deck of cards. Next morning, you could pick up your card deck and however many sheets of paper your job had generated, and go troubleshoot it. That evening, you could try again. If there was too much stuff for the operator to fit it all in, you had to wait until the next day. Sometimes, if the operator was feeling generous and the workload was light, you could persuade him to run a few things during lunch hour. Even under such primitive conditions, once I discovered what those machines could do, I was hooked and have been at it ever since.
As a young child, I liked to play with my dad's old punch cards from the grad school courses he was taking at the time. Student access to the mainframe worked the same way as pdanes described - turn in your cards for your once-daily run, check back the next day for results. My dad got about as emotional as he ever gets describing the frustration of working for hours on a program, picking up "error" results, then spending hours more poring over the cards to find the one errant punch.
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Friday, May 17, 2013 7:19 AM
Points: 1,562,
Visits: 1,716
|
|
Rod Early (2/22/2013) I got a TI-99/4A computer in 1982 when I was a sophomore in high school... I also started with the TI-99/4A, I was in 7th grade at the time though. Lots of memories writing BASIC on that. I don't envy you reprogramming the ASCII characters for Greek, I remember I had tried to make real lowwer case letters instead of just small capitals amongst other things, and had the Hex to bits conversions memorized.
The software though that got me interested more in the database side of things was in my first real job when I started using FoxPro for DOS. Yes I had database classes in college that worked with Sybase but those didn't quite grab my imagination the way FoxPro did because we didn't build any front end for the database in college. FoxPro allowed access to the data by SQL or by lowwer level commands. I learned alot about databases from utilizing both, including my preferred way of "pivoting" data using the IIF() function of FoxPro in a SQL query, which I translated to DECODE() function when I learned Oracle, which I translated to CASE in SQL Server.
|
|
|
|
|
Say Hey Kid
      
Group: General Forum Members
Last Login: 2 days ago @ 8:55 AM
Points: 685,
Visits: 1,707
|
|
pdanes (2/22/2013)
Bill Wehnert - The Tom Swift books (I had a set, too) weren't written by Asimov. http://en.wikipedia.org/wiki/Tom_Swift... My first experience with computing hardware was mechanical Marchant calculators, in the university physics labs where my father taught. ...
Which reminds me, I have one of these, which my dad (a machine designer) purchased new when I was a child in the 60s. It's a wondrous piece of machinery
http://www.vcalc.net/cu.htm
...
-- FORTRAN manual for Xerox Computers --
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: 2 days ago @ 2:02 PM
Points: 1,162,
Visits: 3,333
|
|
Michael Valentine Jones (2/22/2013) I don’t see how this list could be complete without mentioning COBOL.
From the 1960s until about 1990 it was the language of choice for business programming with implementations on every major OS.
There are tremendous number of applications written in COBOL still running.
It might not be flashy, sexy, object-oriented, etc. but it continues to be a workhorse.
COBOL can use indexed sequential files, but it still only does row by row cursor style batch processing. I guess it's a work horse on a big mainframe. When I attended university back in late 80's and early 90's, the database related courses were centered around COBOL. However, since then I've never been exposed to COBOL professionally except as part of a Y2K conversion where I had to port an AS400 based inventory system to SQL Server, copying tables and re-writing COBOL procedures as T-SQL. So I know how to read COBOL, but fortunately never had to develop with it.
"Wise people understand the 10,000 things without going to each one. They know them without having to look at each one, and they transform all without acting on each one." - The Tao Te Ching: Verse 47
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Yesterday @ 10:01 PM
Points: 2,944,
Visits: 10,504
|
|
Eric M Russell (2/22/2013)
Michael Valentine Jones (2/22/2013) I don’t see how this list could be complete without mentioning COBOL.
From the 1960s until about 1990 it was the language of choice for business programming with implementations on every major OS.
There are tremendous number of applications written in COBOL still running.
It might not be flashy, sexy, object-oriented, etc. but it continues to be a workhorse.
COBOL can use indexed sequential files, but it still only does row by row cursor style batch processing. I guess it's a work horse on a big mainframe. When I attended university back in late 80's and early 90's, the database related courses were centered around COBOL. However, since then I've never been exposed to COBOL professionally except as part of a Y2K conversion where I had to port an AS400 based inventory system to SQL Server, copying tables and re-writing COBOL procedures as T-SQL. So I know how to read COBOL, but fortunately never had to develop with it.
COBOL can use SQL calls to various RDMS, depending on the environment, COBOL version, RDMS API, etc.
I am not sure if I know of any procedural language that does anything except row by row processing. Are there any set based languages besides SQL?
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Wednesday, April 03, 2013 8:43 AM
Points: 32,
Visits: 142
|
|
My 1st was also a VIC-20 -- which is nothing like the C=64 I eventually upgraded to, Eric! A BASIC manual and then a 6502 Assembler manual was what I lived on, writing animated musical (erm, "beeping") birthday cards for my family in the former and a disk directory prorgam that fit in the 1541 floppy drive's 2K of RAM in the latter. When I could get a hold of a BYTE magazine, I would spend hours typing in the hex code programs to play the half-way decent game it generated.
After turning "pro" with the COBOL programming thing, I was able to afford an Amiga 500 and I moved from programming my computers to integrating software and hardware on them. I still have one of my A500s and the 1200 that followed. The way they managed libraries and devices dynamically should make any Windows programmer jealous. I need to fire up my WinUAE before going back to my databases now...
Man, that was back when this stuff was fun. I think the Arduino is as close as I've gotten to that same feeling in today's computing.
Rich
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: 2 days ago @ 4:21 PM
Points: 335,
Visits: 606
|
|
| First computer I wanted was a SOL. It was a blue box with a keyboard. I seem to recall it had a wood sides. My parents wouldn't let me get it so the next year I snuck out and bought a TRS-80 Model 1 at 15. I remember upgrading it to a floppy then a double sided floppy (76k of storage). Old shugard drive. They offered a computer class in high school but they wouldn't let me take it. I also spent lots of time programming TI calculators until I found out the math teacher was tricking me into learning math at the same time! Loads of fun. I used to try and disassemble the games when I couldn't solve them, everyonce in while I got lucky.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: 2 days ago @ 2:02 PM
Points: 1,162,
Visits: 3,333
|
|
Michael Valentine Jones (2/22/2013)
Eric M Russell (2/22/2013)
Michael Valentine Jones (2/22/2013) I don’t see how this list could be complete without mentioning COBOL.
From the 1960s until about 1990 it was the language of choice for business programming with implementations on every major OS.
There are tremendous number of applications written in COBOL still running.
It might not be flashy, sexy, object-oriented, etc. but it continues to be a workhorse.
COBOL can use indexed sequential files, but it still only does row by row cursor style batch processing. I guess it's a work horse on a big mainframe. When I attended university back in late 80's and early 90's, the database related courses were centered around COBOL. However, since then I've never been exposed to COBOL professionally except as part of a Y2K conversion where I had to port an AS400 based inventory system to SQL Server, copying tables and re-writing COBOL procedures as T-SQL. So I know how to read COBOL, but fortunately never had to develop with it. COBOL can use SQL calls to various RDMS, depending on the environment, COBOL version, RDMS API, etc. I am not sure if I know of any procedural language that does anything except row by row processing. Are there any set based languages besides SQL? That's right, RDMS and SQL made ISAM and COBOL obsolete 20 years ago.
"Wise people understand the 10,000 things without going to each one. They know them without having to look at each one, and they transform all without acting on each one." - The Tao Te Ching: Verse 47
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: 2 days ago @ 9:51 AM
Points: 1,891,
Visits: 936
|
|
Eric M Russell (2/22/2013)That's right, RDMS and SQL made ISAM and COBOL obsolete 20 years ago.
Problem is that it might take another few decades to replace all the COBOL code. It really was the workhorse of the industry for a long time and we wrote a ton of it.
Not all gray hairs are Dinosaurs!
|
|
|
|