We ended up with three of them, bought for about $250 from the ad in Popular Electronics. Note that display resolution of 17 x 12 text. That's not kidding. Text was drawn with a 5x5 character set on the 112 x 78 pixel graphics display. There was no real text mode. While I could log into the DEC with my 300 baud modem, this made actually using it a bit of a challenge.
Fortunately for the FORTRAN course, all the outputs were printed and I did have an 80-column printer. (I also had the full travel keyboard which is pictured about half-way down that page, so no, I wasn't doing it on the chiclet keys.)
Having such a crippled first computer taught me a lot. There was a user group but very little guidance and I had to pretty much figure everything out myself. To this day I reember a fair number of 8080 opcodes because of that machine.
I bought my first home computer in 1977. It had 3 x 10MB HDDs, 110KB (6-bit) which was the max, and 1 VDU (video terminal). It required an air conditioned room which I built in one of my garages. The computer was the length of my garage and I kept it operational until 2000 when I sold it for scrap gold.
That brings back some memories. I had a F83 shareware disk back in the day. It is very much an IBM PC MSDOS system, which defaulted to running from floppy disk A:. I have written a couple of BASIC interpreters and compilers over the years, the last written in VB6 to generate x86 source code for the FASM assembler. Once you wrap your head around the expression evaluator, which really needs to be implemented with recursion, the rest is easy.
I learned Fortan & COBOL at a local junior college (Chabot, Hayward, CA) at night... At that time I was a hobbyist and vice president of the local Apple ][ computer club (ABACUS, the Apple Bay Area Computer Users Society), programming AppleSoft & Integer BASIC & 6502 ASM, weekends. My day job as a COBOL programmer was for a regional department store. My actual coding work depended on understanding CISC (the online customer interface on IBM 390 mainframes), & IDL (database programming language, prior to DB2). COBOL was something you learned in a semester course at school. Very little of what we did at work was actual COBOL code. And I think most COBOL code for business today relies on many protocols, and disciplines, as well.
I give lots of credit to COBOL programmers as they've had to whether the storms of the changing world of software. They do a lot with a rather limited language.
Because the COBOL programmers had not to do much to ride out the storm.
I still can compile and run source code written before I was born (1963), with a almost any current COBOL compiler.
You might have noticed, as a programmer, that stuff you have written, or projects you worked on seem to come back to you, years later.
Like those bumerang children. Somehow somebody hunts you down and you may need to fix it. Maybe it's just me, but I think it hits all programmers.
Sometimes it's a VB6 program (sorry @localroger) and I still have VB6 but them Telerics Controls are gone. Sometimes it is a switch to different servers or versions and you have to do wonders in short time because everything broke.
But Pythonxx does not run Pythonyy, Modula/Pascal is mostly gone, every 2 month a new language appears and another disappears, GO, Haskel, Smile, whatever.
Then the constant changing frameworks. Most of my non COBOL jobs are Windows C#. Basically love it, but - hell - I spend at least 50% of my time to rewrite stuff already running to STILL run on the next server version, NET version, VS version. Constant changing environment, It is HORRIBLE!!!!
Does not happen with COBOL.
This rather limited language has one thing most other languages does not have, it never broke any existing code.
Sure it is very strict and very verbose and somehow limited compared to newer languages. But ISAM DB access is WAY faster as any SQL. Sure not as nice as SQL but if you need to transact 10 millions of records, neither Oracle or MS SQL can beat even BDB or CISAM. By some magnitudes.
sorry for the rant, but I want to retire and we REALLY need some young COBOL programmers...
Sometimes it's a VB6 program (sorry @localroger) and I still have VB6 but them Telerics Controls are gone.
No worries! While VB6 still works I recognize that nearly the entire plugin and external control ecosystem for it is extinct. Many people who learned with VB were taught from the beginning to use the data access object instead of writing data to files, and of course that was the first thing Microsoft broke in order to force people off the platform.
I learned on an 8-bit machine though, so I always used the language itself to deal directly with data on the disc. The last actual plugin I depended on was the MSCOMM serial port control, which was mysteriously bundled only with the Professional version of VB because obviously you don't need to use serial ports unless you're a Professional. One day I was at a customer site and they had their own copy of VB, and I needed to run their app in the IDE to debug it but it wouldn't run because their version of VB was standard and even though I'd run the installer to get the MSCOMM control onto their machine, it was registered for runtime use only and not development. This pissed me off so much I spent the next two weeks figuring out how to control the serial ports directly to the Windows API, which is a massive pain in the Smile and as far as I know I am the only person ever to do that in VB. But I did it, and as a result my VB apps since that day in 2004 or so have no dependencies at all except the vbrun600 dll, which has been part of Windows itself since Win2K. This means I no longer have to run an installer; I can just copy the folder onto a new windows box, make a shortcut, and they will run. I have watched IT people drill a hole in the ground doing a complete turnaround from "why the hell do you use VB6" to "That's terrific" when I explained that to them.
We used btrieve for the database engine with VB3/4/5/6 but .Net broke just about everything.
Eventually, VB6 was eventually rewritten (not by me) in some other language for the net.
For VB, I wrote a set of conversion routines so we could handle bits/bytes/etc conversions back and forth to strings/etc.
Comments
http://oldcomputers.net/interact.html
We ended up with three of them, bought for about $250 from the ad in Popular Electronics. Note that display resolution of 17 x 12 text. That's not kidding. Text was drawn with a 5x5 character set on the 112 x 78 pixel graphics display. There was no real text mode. While I could log into the DEC with my 300 baud modem, this made actually using it a bit of a challenge.
Fortunately for the FORTRAN course, all the outputs were printed and I did have an 80-column printer. (I also had the full travel keyboard which is pictured about half-way down that page, so no, I wasn't doing it on the chiclet keys.)
Having such a crippled first computer taught me a lot. There was a user group but very little guidance and I had to pretty much figure everything out myself. To this day I reember a fair number of 8080 opcodes because of that machine.
I never used a Forth with screens, so it would take a while for me to dedust such an implementation and get used to it... *sigh*
I give lots of credit to COBOL programmers as they've had to whether the storms of the changing world of software. They do a lot with a rather limited language.
I hope the need pays off for those folks!
dgately
Somehow.
Because the COBOL programmers had not to do much to ride out the storm.
I still can compile and run source code written before I was born (1963), with a almost any current COBOL compiler.
You might have noticed, as a programmer, that stuff you have written, or projects you worked on seem to come back to you, years later.
Like those bumerang children. Somehow somebody hunts you down and you may need to fix it. Maybe it's just me, but I think it hits all programmers.
Sometimes it's a VB6 program (sorry @localroger) and I still have VB6 but them Telerics Controls are gone. Sometimes it is a switch to different servers or versions and you have to do wonders in short time because everything broke.
But Pythonxx does not run Pythonyy, Modula/Pascal is mostly gone, every 2 month a new language appears and another disappears, GO, Haskel, Smile, whatever.
Then the constant changing frameworks. Most of my non COBOL jobs are Windows C#. Basically love it, but - hell - I spend at least 50% of my time to rewrite stuff already running to STILL run on the next server version, NET version, VS version. Constant changing environment, It is HORRIBLE!!!!
Does not happen with COBOL.
This rather limited language has one thing most other languages does not have, it never broke any existing code.
Sure it is very strict and very verbose and somehow limited compared to newer languages. But ISAM DB access is WAY faster as any SQL. Sure not as nice as SQL but if you need to transact 10 millions of records, neither Oracle or MS SQL can beat even BDB or CISAM. By some magnitudes.
sorry for the rant, but I want to retire and we REALLY need some young COBOL programmers...
Mike
Timesink mode = 1
https://github.com/watson/awesome-computer-history
No worries! While VB6 still works I recognize that nearly the entire plugin and external control ecosystem for it is extinct. Many people who learned with VB were taught from the beginning to use the data access object instead of writing data to files, and of course that was the first thing Microsoft broke in order to force people off the platform.
I learned on an 8-bit machine though, so I always used the language itself to deal directly with data on the disc. The last actual plugin I depended on was the MSCOMM serial port control, which was mysteriously bundled only with the Professional version of VB because obviously you don't need to use serial ports unless you're a Professional. One day I was at a customer site and they had their own copy of VB, and I needed to run their app in the IDE to debug it but it wouldn't run because their version of VB was standard and even though I'd run the installer to get the MSCOMM control onto their machine, it was registered for runtime use only and not development. This pissed me off so much I spent the next two weeks figuring out how to control the serial ports directly to the Windows API, which is a massive pain in the Smile and as far as I know I am the only person ever to do that in VB. But I did it, and as a result my VB apps since that day in 2004 or so have no dependencies at all except the vbrun600 dll, which has been part of Windows itself since Win2K. This means I no longer have to run an installer; I can just copy the folder onto a new windows box, make a shortcut, and they will run. I have watched IT people drill a hole in the ground doing a complete turnaround from "why the hell do you use VB6" to "That's terrific" when I explained that to them.
Eventually, VB6 was eventually rewritten (not by me) in some other language for the net.
For VB, I wrote a set of conversion routines so we could handle bits/bytes/etc conversions back and forth to strings/etc.