February 22, 2013 at 10:54 am
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.
Jason Wolfkill
February 22, 2013 at 11:02 am
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.
February 22, 2013 at 11:07 am
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
...
-- FORTRAN manual for Xerox Computers --
February 22, 2013 at 11:34 am
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 22, 2013 at 12:11 pm
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?
February 22, 2013 at 12:32 pm
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
February 22, 2013 at 12:32 pm
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.
February 22, 2013 at 12:34 pm
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 22, 2013 at 2:31 pm
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!
February 22, 2013 at 2:48 pm
It's not obsolete if it still does the job it was designed to do. I've written my share of FORTRAN, RPG, COBOL and who knows what else over the years. No idea if any of it is still running somewhere, but if so, great! There are plenty of tasks that need attention, without inventing silly make-work like replacing fully functional existing code.
Things are only obsolete if they can no longer perform their assigned function. COBOL does not fit that definition by any stretch of the imagination.
There are shops that develop new applications in COBOL today, and do an enormous amount of useful work. Just because it doesn't fit someone's idea of 'the latest and greatest' doesn't mean it's a bad idea to use it.
February 22, 2013 at 3:19 pm
pdanes (2/22/2013)[ There are plenty of tasks that need attention, without inventing silly make-work like replacing fully functional existing code.
Absolutely agree! If it works, requires no maintenance, and you are not moving platforms, leave it alone. We have some COBOL programs that have been running daily for over 12 years with no maintenance done to them. That's not common, but it does exist.
Back in the day, I wrote my share of COBOL on mainframes and AS/400. AS/400 even had (has?) embedded SQL that you can get some benefit of set based operations, but many people would still write it as a cursor so the procedural flow was still the same.
February 22, 2013 at 3:36 pm
Eric M Russell (2/22/2013)
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.
SQL did not make COBOL obsolete, since SQL is not a front-end tool and not really a replacement for COBOL.
I wrote plenty of COBOL programs that accessed SQL RDMS databases (DEC RDB, not SQL Server) 25 years ago.
February 22, 2013 at 4:45 pm
LOL! Does anyone remember APL, "A Programming Language"? That's what hooked me in 1975, because it was an interactive terminal (keyboard, no CRT) back when all the other computer programming classes at my university were key-punched cards with overnight processing. I used it to write some interactive basic statistics tutorials for the statistics class I had just taken (probability and permutations versus combinations).
February 23, 2013 at 7:27 am
I read the previous comments, and except for a very few, posted by us "oldtimers" which bought back memories of my first programming tasks in 1960. (Hard to believe that was some 53 years ago) Using the now ancient IBM 1401 and a language known as "AUTOCODER". Autocoder was basically an assembly language. We could not utilize variables, but had to store data in specific memory locations, and to a programmer a ream of paper listing memory locations and what value was in that location was an indispensable tool. The IBM 1401 at that time was, I think rightfully so, designed to handle business data, such as item warehouse location, number of units available, unit price, so that it could be used to reduce quantity in inventory, recall the price per item so as to generate a invoice for the customer. My first task was to attempt to solve engineering problems using a business orientated language. Enough of that, it was to me fascinating, since the only way I did have to solve an engineering problem was a mechanical calculator, input the starting value, pull the hand crank to store the value, enter the operation by depressing the proper key to (add, or subtract, or divide) then input the next value and pull the hand crank.... hand record the result of the calculation, and then continue, hours of endless work to solve the simplest of engineering calculations. And so I started with autocoder, and at the height of my frustrations using autocode, IBM announced a new computer language FORTRAN. A language designed for engineering calculations and loadable on a 1401 computer. Happy days ... oh those so happy days (hindsight). But the result was a strong desire to learn more about programming and how to use it as an engineering tool. Thank goodness that desire to learn remains with me until this day, and I look upon things such as relational databases as a wonderful tool.
February 23, 2013 at 5:07 pm
I got hooked on computers when I took my first programming class in college - a required course as part of the EE stuff I was doing at the time. My first computer was a Radio Shack TRS-80, where I wrote BASIC programs (to tape!). But the first piece of true software that really evolved things (for me) was when I got my Apple //c and was using AppleWorks.
Ahh, how things have changed since then.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
Viewing 15 posts - 31 through 45 (of 62 total)
You must be logged in to reply to this topic. Login to reply