Yes I had an experience writing a baseball stats program on a Commodore 64 using BASIC. All of the data were in data statements and saved with the program on tape until we could afford a floppy drive and then store data in a serial file and load it in the Baseball stats program.
I too used Visual BASIC, when MS-Access 1.0 first came out middle of the 1990s, I had an interview at a tools making company and they asked me to make a record collection database in MS-Access and even if I never used it before I figured it out because everything was GUI. So I created tables and forms in less than an hour and had a data entry form as well.
Visual BASIC 3.0 and 4.0 they had a RDO object to connect to a database using ODBC drivers. Had an AS/400 and used Showcase ODBC to connect to the DB2 database on the IBM AS/400 for Windows PCs. Used RDO for MS-Access and SQL Server Databases. Then later on ADO replaced RDO.
Then in the Dotnet languages they have ADO.Net that does the same thing to connect to databases.
In my Linkedin profile, former managers and coworkers would endorse me for databases, because I was always fixing the database after someone else messed it up and when they needed a new one nobody knew how to make one, and so I made the databases for them. Converted from Excel and Access to SQL Server as well. Had a VB program that read the Excel or Access database and ran through the ADO database recordset to insert them into SQL Server in another table.
I originally got into computers to learn how to make video games, but found that solving business problems and doing business apps would be more profitable because the video game market had crashed in the 1980s.
>Yes I had an experience writing a baseball stats program on a Commodore 64 using BASIC. All of the data were in data statements and saved with the program on tape until we could afford a floppy drive and then store data in a serial file and load it in the Baseball stats program.
So you had the program rewrite itself every time it ran to edit the data statements? That would be fascinating.
I think sharing these stories are awesome. Constraints in programming are always fascinating and they create awesome hacks. And to me the most fascinating is when you invent something radical -- at least to you -- that is actually a known concept in Computer Science.
Yeah I lost the disks I had with the C64 when I let a friend borrow it and he never returned it and moved away from our neighborhood.
But programming the Commodore 64 was a challenge because BASIC on it was primitive and older than some of the others out there like the Atari 8 bit series. I learned what peek and poke accessed parts of the C64 memory you needed to know what they did to write video games and control sprites. If you wanted to write code that changes the data statements you had to know what area of memory it used and use poke to put it there. In a way I guess you are right that it was self modifying code in that it changed the data statement. I'm sure other people did that as well. When all you have is a Commodore 64 before the Internet, best you could do is read magazines like Compute!s Gazette and get on BBS systems and talk to other programmers to get ideas and share tricks we learned.
The Commodore 64 was like the Raspberry PI of the 1980s, it was cheap and it worked. I might buy a Raspberry PI some day.
That's a very cool story! Let me know if you'd like to publish it on Medium under the "childhood hacks" page I put together. I'm trying to get as much stories like this under one roof as possible. Should be fun.
Reading about relative files and such in the commodore 1541 manual: Went very well.
Writing a program out on paper: Went very well.
Getting it to work at all on the computer: Total failure.
I just couldn't think clearly enough about how to go about debugging a program.
To VB's credit they did a great job with debugging tools. The stepping debugger was great but to me the "immediate" (which is a repl of sorts) was magical.
6 comments
[ 2.6 ms ] story [ 25.4 ms ] threadI too used Visual BASIC, when MS-Access 1.0 first came out middle of the 1990s, I had an interview at a tools making company and they asked me to make a record collection database in MS-Access and even if I never used it before I figured it out because everything was GUI. So I created tables and forms in less than an hour and had a data entry form as well.
Visual BASIC 3.0 and 4.0 they had a RDO object to connect to a database using ODBC drivers. Had an AS/400 and used Showcase ODBC to connect to the DB2 database on the IBM AS/400 for Windows PCs. Used RDO for MS-Access and SQL Server Databases. Then later on ADO replaced RDO.
Then in the Dotnet languages they have ADO.Net that does the same thing to connect to databases.
In my Linkedin profile, former managers and coworkers would endorse me for databases, because I was always fixing the database after someone else messed it up and when they needed a new one nobody knew how to make one, and so I made the databases for them. Converted from Excel and Access to SQL Server as well. Had a VB program that read the Excel or Access database and ran through the ADO database recordset to insert them into SQL Server in another table.
I originally got into computers to learn how to make video games, but found that solving business problems and doing business apps would be more profitable because the video game market had crashed in the 1980s.
So you had the program rewrite itself every time it ran to edit the data statements? That would be fascinating.
I think sharing these stories are awesome. Constraints in programming are always fascinating and they create awesome hacks. And to me the most fascinating is when you invent something radical -- at least to you -- that is actually a known concept in Computer Science.
But programming the Commodore 64 was a challenge because BASIC on it was primitive and older than some of the others out there like the Atari 8 bit series. I learned what peek and poke accessed parts of the C64 memory you needed to know what they did to write video games and control sprites. If you wanted to write code that changes the data statements you had to know what area of memory it used and use poke to put it there. In a way I guess you are right that it was self modifying code in that it changed the data statement. I'm sure other people did that as well. When all you have is a Commodore 64 before the Internet, best you could do is read magazines like Compute!s Gazette and get on BBS systems and talk to other programmers to get ideas and share tricks we learned.
The Commodore 64 was like the Raspberry PI of the 1980s, it was cheap and it worked. I might buy a Raspberry PI some day.
Reading about relative files and such in the commodore 1541 manual: Went very well. Writing a program out on paper: Went very well. Getting it to work at all on the computer: Total failure.
I just couldn't think clearly enough about how to go about debugging a program.