After my stint working as a contractor on the IBM + Raytheon project, a friend of mine I knew from church who happened to know I specialized in Smalltalk reached out to me and got me an interview at Kronos, Inc. where they made time and attendance products. They hired me as a contractor.
Kronos was the market leader in this space and their breakthrough product was the combination of digital punch clocks with a magnetic card strip reader and an application developed in C to process all the data of employees coming and going.
Before I went there they had created a new version of their system called TimeKeeper C/S which was developed in Smalltalk. The C/S part stood for Client/Server, so Smalltalk application used a SQL Server database as its backend.
My task on this contracting job was to develop an extension to their TimeKeeper C/S application. Because they didn't have a database resource to work with me, I developed a dynamic object persistence system that was file based, and I also created a dynamic user interface mechanism to present application windows based on metadata.
It was an interesting project and the work paid well. Later on the contacts I made would help me again and again.
After the contract period was finished I went back to working on Liberty BASIC again.
Showing posts with label c. Show all posts
Showing posts with label c. Show all posts
Thursday, September 19, 2019
Sunday, September 16, 2018
Python - The Emperor's New Clothes
I recently posted a couple of examples of a starfield simulation written in BASIC. One of these was written in Commodore BASIC for the VIC-20. The other was written in Liberty BASIC for Windows.
BASIC gets a lot of flack from people with a certain kind of snob factor (yes, you know who you are). And there is the infamous comment by Edsger Dijkstra, and BASIC has never lived it down. Nowadays when you see people discussing what is the best first language I probably see Python mentioned most. In these forum discussions someone always seems to snidely denounce BASIC as that old thing with the GOTO and the unreadable spaghetti code. They don't seem to have a good reason to recommend Python, except that it isn't BASIC.
People also recommend C and it's derivatives such as C++ which also has GOTO. So go figure.
Wait, here is something scandalous! On the Python Software Foundation website, in their design and history FAQ page, they actually answer the question about why there is no GOTO in Python by encouraging people to use exception handling as a hack to simulate something like GOTO! Ummmm. See for yourself. https://docs.python.org/3/faq/design.html#why-is-there-no-goto
Okay, getting back to the starfield simulation example. If you look at the version of the starfield simulation written in Liberty BASIC, it addresses some of the things that BASIC is frowned on about.
BASIC gets a lot of flack from people with a certain kind of snob factor (yes, you know who you are). And there is the infamous comment by Edsger Dijkstra, and BASIC has never lived it down. Nowadays when you see people discussing what is the best first language I probably see Python mentioned most. In these forum discussions someone always seems to snidely denounce BASIC as that old thing with the GOTO and the unreadable spaghetti code. They don't seem to have a good reason to recommend Python, except that it isn't BASIC.
People also recommend C and it's derivatives such as C++ which also has GOTO. So go figure.
Wait, here is something scandalous! On the Python Software Foundation website, in their design and history FAQ page, they actually answer the question about why there is no GOTO in Python by encouraging people to use exception handling as a hack to simulate something like GOTO! Ummmm. See for yourself. https://docs.python.org/3/faq/design.html#why-is-there-no-goto
Okay, getting back to the starfield simulation example. If you look at the version of the starfield simulation written in Liberty BASIC, it addresses some of the things that BASIC is frowned on about.
- GOTO - Uh oh, not really. There is one GOTO, but in this case I'm not sure a WHILE/WEND forever loop is really better, so... The Commodore BASIC version has three GOTOs.
- Structure - The Liberty BASIC version uses control structures properly the way modern languages do.
- Line numbers - Liberty BASIC programs do not require numbers. You can give your routines meaningful names instead of numbers.
Okay, let's be frank. Liberty BASIC was not the first version of BASIC to solve these problems. There are many BASICs with modern features, and so it isn't fair to criticize BASIC as being a bad language for beginners. BASIC has been a proper language for teaching good programming practices for a very long time now.
What do you think? Comments welcome. :-)
Monday, March 14, 2011
Power BASIC and the Uncrashable Kingdom
I had it in mind to use Power BASIC as the compiler to implement the new DOS file server for the factory. This was a new, slicker and rebranded version of Turbo BASIC which I had been using for a while. It wasn't cheap. Power BASIC was a nicely polished compiler and had good documentation. I think we paid $300 or so for it.
I wanted to create a nice UI for the file server so I purchased a windowing library for Power BASIC. It made it easy to create text mode windows using graphics characters. The way it worked was very similar to the way that a Windows programmer would do it in C. You called functions which created windows, buttons, etc. These would return a numeric handle.
Your program would intercept messages from the UI library in an event loop and act on them. Each message would include the handle for the window or widget it was about, and also a value for an action such as a click or a key press. This is not an easy way to write windowing code, but the file server would have a simple enough UI. The end result looked nice and was functional.
I learned a lot on this project. This must have been the highest quality BASIC code I had written to this point. It was a multitasking file server using state machine techniques. Unlike its Xenix based predecessor, this file server never crashed once we had it up and running. Never.
I wanted to create a nice UI for the file server so I purchased a windowing library for Power BASIC. It made it easy to create text mode windows using graphics characters. The way it worked was very similar to the way that a Windows programmer would do it in C. You called functions which created windows, buttons, etc. These would return a numeric handle.
Your program would intercept messages from the UI library in an event loop and act on them. Each message would include the handle for the window or widget it was about, and also a value for an action such as a click or a key press. This is not an easy way to write windowing code, but the file server would have a simple enough UI. The end result looked nice and was functional.
I learned a lot on this project. This must have been the highest quality BASIC code I had written to this point. It was a multitasking file server using state machine techniques. Unlike its Xenix based predecessor, this file server never crashed once we had it up and running. Never.
Sunday, March 28, 2010
Welcome to My Research and Development Lab
In search of the perfect next development tool to create our shop floor control system I was now in full blown research and development mode. I would read lots of magazines looking to learn as much as I could. I had a modem and a phone line in my office now too, and I was downloading free programming tools and trying them out.
Bob allowed me to take off and go to the public library so that I could read magazines articles about languages and programming. There were plenty of articles about object oriented extensions to languages like C and Forth. I found all this very interesting, but I had no experience with object oriented programming so I really didn't know what to think.
I saw an ad in a magazine for a language called Actor by the Whitewater Group, and this really caught my attention. The code looked like C, but it was supposed to be object oriented. There was a code snippet in a screenshot in the ad that implemented a very simple drawing program. The code was just a few lines long. The screenshot also showed the simple drawing program and they used it to draw a version of the product logo. The idea was that you could create very sophisticated software with very little code. The only thing was that the software was not cheap, and it required a copy of Microsoft Windows 2.1. We weren't yet running Windows on any computer in our office. This was in the summer of 1988.
One other tool I was interested in was called Matrix Layout. This was a visual flowcharting tool that produced graphical DOS applications. I guess you could call it a kind of HyperCard, which is a Macintosh programming tool for end users. It was only $149 so I obtained a copy for myself. The developer's office was in Boston, so I just drove there one day after work and bought it at the receptionist's desk. I was ultimately quite disappointed by this product. I tried to prototype a version of the video rental application I wrote in BASIC, but it was too much effort for the result. Once you've used a real programming language, these visual tools for non-programmers feel very limited. Clarion is really a lot better because it has a real programming language you can use to script extensions beyond the visual layout tools. Matrix Layout did not provide any way to write scripts. A simple BASIC interpreter would have done great things for this tool.
Then there was Ashton Tate's Framework. This was a fascinating programming system where modules of your application are in a frame, which can hold more frames, and these can hold yet more frames, etc. It had a scripting language called FRED which was based on a Lisp, a very powerful language. Framework was an integrated office suite, and it was extensible using the frame concept and the the scripting language. I never actually got to try it out, but I'm not sure it would have been suitable for the shop floor control system I wanted to develop anyways.
If Bob was beginning to wonder about whether I was ever going to produce anything for all the time and money spent, I never knew it. He was very patient. I did manage to stay busy with smaller projects. He had lots of ideas to enhance the applications I had already written, and he would come to me and we would talk about what he would like.
Bob allowed me to take off and go to the public library so that I could read magazines articles about languages and programming. There were plenty of articles about object oriented extensions to languages like C and Forth. I found all this very interesting, but I had no experience with object oriented programming so I really didn't know what to think.
I saw an ad in a magazine for a language called Actor by the Whitewater Group, and this really caught my attention. The code looked like C, but it was supposed to be object oriented. There was a code snippet in a screenshot in the ad that implemented a very simple drawing program. The code was just a few lines long. The screenshot also showed the simple drawing program and they used it to draw a version of the product logo. The idea was that you could create very sophisticated software with very little code. The only thing was that the software was not cheap, and it required a copy of Microsoft Windows 2.1. We weren't yet running Windows on any computer in our office. This was in the summer of 1988.
One other tool I was interested in was called Matrix Layout. This was a visual flowcharting tool that produced graphical DOS applications. I guess you could call it a kind of HyperCard, which is a Macintosh programming tool for end users. It was only $149 so I obtained a copy for myself. The developer's office was in Boston, so I just drove there one day after work and bought it at the receptionist's desk. I was ultimately quite disappointed by this product. I tried to prototype a version of the video rental application I wrote in BASIC, but it was too much effort for the result. Once you've used a real programming language, these visual tools for non-programmers feel very limited. Clarion is really a lot better because it has a real programming language you can use to script extensions beyond the visual layout tools. Matrix Layout did not provide any way to write scripts. A simple BASIC interpreter would have done great things for this tool.
Then there was Ashton Tate's Framework. This was a fascinating programming system where modules of your application are in a frame, which can hold more frames, and these can hold yet more frames, etc. It had a scripting language called FRED which was based on a Lisp, a very powerful language. Framework was an integrated office suite, and it was extensible using the frame concept and the the scripting language. I never actually got to try it out, but I'm not sure it would have been suitable for the shop floor control system I wanted to develop anyways.
If Bob was beginning to wonder about whether I was ever going to produce anything for all the time and money spent, I never knew it. He was very patient. I did manage to stay busy with smaller projects. He had lots of ideas to enhance the applications I had already written, and he would come to me and we would talk about what he would like.
Tuesday, March 23, 2010
Thinking Forth
I wrote some small programs in C, and I was having a good time doing that. However, my ambition was to write a shop floor control system and I started work on that using C. I found that C was manageable for small programming tasks. As the project got larger dealing with all the pointer arithmetic, manual memory management and casting of numeric types was beginning to drive me nuts. I had to conclude that C is a really good language for operating system work because it was designed for that, but that for application level work it just shouldn't be necessary to be concerned with bits, bytes, pointers, memory allocation etc. Heck, BASIC would have been a better language than C for this.
After my disappointing experience with Wendin DOS and C I decided that I needed a more expressive programming language. I started to dabble in different languages, and I would write toy shop floor control systems to see how the code would come together. My work was exploratory in the sense that I wasn't in a big hurry to produce a result. I felt that I didn't know which course to take. In particular, I didn't know how to code a solution to overcome the hurdle of multitasking.
For example I experimented with a 4GL called Clarion. Bob was willing to spend several hundred dollars on this based on some stellar reviews that it received in magazines. Clarion really was great, but it was oriented primarily as a development tool for forms based database apps, and it had a nice reports engine. It did also include a compiler for BASIC-like language, but this was a short lived experiment. I do seem to remember creating a custom app for accounting with Clarion so we did get some value for the money.
So after this my mind turned back to the Forth programming language. I had already some experience with it, and I was excited to see if I could use it to create a multiuser shop floor system.
I found a version of Forth called Fifth, which included a simple IDE for MS-DOS. I also played with a couple of other Forth implementations.
So I went looking and bought a book titled Thinking Forth by Leo Brodie, the same author of the wonderful Starting Forth book I encountered a few years earlier. This was the most inspiring book about programming I had read yet. I enjoyed Leo's explanations about how software needs to be written abstractly, that code should be as small and simple as possible, about the importance of choosing the best words for procedures and variables, and also how to write well factored code and what that really means. The book also has great interviews with experienced Forth programmers and many funny and illustrative cartoons. Great stuff. Now, where did I put my copy?
After my disappointing experience with Wendin DOS and C I decided that I needed a more expressive programming language. I started to dabble in different languages, and I would write toy shop floor control systems to see how the code would come together. My work was exploratory in the sense that I wasn't in a big hurry to produce a result. I felt that I didn't know which course to take. In particular, I didn't know how to code a solution to overcome the hurdle of multitasking.
For example I experimented with a 4GL called Clarion. Bob was willing to spend several hundred dollars on this based on some stellar reviews that it received in magazines. Clarion really was great, but it was oriented primarily as a development tool for forms based database apps, and it had a nice reports engine. It did also include a compiler for BASIC-like language, but this was a short lived experiment. I do seem to remember creating a custom app for accounting with Clarion so we did get some value for the money.
So after this my mind turned back to the Forth programming language. I had already some experience with it, and I was excited to see if I could use it to create a multiuser shop floor system.
I found a version of Forth called Fifth, which included a simple IDE for MS-DOS. I also played with a couple of other Forth implementations.
So I went looking and bought a book titled Thinking Forth by Leo Brodie, the same author of the wonderful Starting Forth book I encountered a few years earlier. This was the most inspiring book about programming I had read yet. I enjoyed Leo's explanations about how software needs to be written abstractly, that code should be as small and simple as possible, about the importance of choosing the best words for procedures and variables, and also how to write well factored code and what that really means. The book also has great interviews with experienced Forth programmers and many funny and illustrative cartoons. Great stuff. Now, where did I put my copy?
Monday, March 8, 2010
MIX C
Unlike today, in the 1980s most computer magazines like BYTE, Compute!, and PC Magazine had lots of articles about programming and programming languages. BASIC, Pascal, Prolog, Lisp, Forth, assembly language; you name it. In 1987 C was a very popular language and a good C programmer made good money so I decided that I should learn it.
I found an magazine ad for MIX C headlined "C for yourself". They had a very special deal called MIX C Works and this included the compiler, a split screen code editor, and a source level debugger for only $89.90. The ad claimed that the included book would make learning C easy. I paid for this software myself, and it was so exciting to open the package when it arrived in the mail. Nice new crisp books and disks. It all felt very professionally done. It was a great investment.
It was very exciting to dig into the C tutorial and use the editor and the source level debugger. This was really well written software and book was as good as the ad promised. C is a nice, small language and well written C is actually quite pretty to look at with those curly braces.
We had some simple applications in engineering that were perfect for learning a new language. Open a file, translate the information in some way and write it back out to a new file.
I found an magazine ad for MIX C headlined "C for yourself". They had a very special deal called MIX C Works and this included the compiler, a split screen code editor, and a source level debugger for only $89.90. The ad claimed that the included book would make learning C easy. I paid for this software myself, and it was so exciting to open the package when it arrived in the mail. Nice new crisp books and disks. It all felt very professionally done. It was a great investment.
It was very exciting to dig into the C tutorial and use the editor and the source level debugger. This was really well written software and book was as good as the ad promised. C is a nice, small language and well written C is actually quite pretty to look at with those curly braces.
We had some simple applications in engineering that were perfect for learning a new language. Open a file, translate the information in some way and write it back out to a new file.
Tuesday, March 2, 2010
Enter the Robots, or... Old Apple IIs Don't Die, They Just Walk Away
Bob had made an arrangement with an entrepreneur (I wish I could remember his name.. Steve, maybe?) who was developing robots. The idea was that a robot could be developed that could tour a factory or other business and move materials automatically from one place to another. I don't know the details of their agreement, but it was probably that Bob would get one of these robots on the cheap or for free for providing the developer with space to work and for providing a real world factory for the robot to be tested in.
The entrepreneur was also the engineer developing the robot technology. I had a few good conversations with this guy because I shared an office with him briefly. He explained to me that the robot had two computers. One was an IBM PC compatible motherboard and the other one was an Apple II+ motherboard. The Apple II+ motherboard would later be replaced with a more generic 6502 card later on. One computer controlled the movement of the robot and read sensors, and it was programmed in C. The other computer had a goal seeking program written a language called Arity Prolog, and this computer controlled the other one.
The robot itself looked kind of like a big R2D2 with a flat top for placing materials to be transported. It had small sonar detectors like you would see on early Polaroid instant cameras, and on the top it had a small dome with a rotating infrared sensor. The robot was taught the layout of the factory, and it would continually adjust its course based on what it knew, what it sensed with sonar, and also by using the rotating sensor to look for infrared senders located in different locations in the factory.
The entrepreneur was also the engineer developing the robot technology. I had a few good conversations with this guy because I shared an office with him briefly. He explained to me that the robot had two computers. One was an IBM PC compatible motherboard and the other one was an Apple II+ motherboard. The Apple II+ motherboard would later be replaced with a more generic 6502 card later on. One computer controlled the movement of the robot and read sensors, and it was programmed in C. The other computer had a goal seeking program written a language called Arity Prolog, and this computer controlled the other one.
The robot itself looked kind of like a big R2D2 with a flat top for placing materials to be transported. It had small sonar detectors like you would see on early Polaroid instant cameras, and on the top it had a small dome with a rotating infrared sensor. The robot was taught the layout of the factory, and it would continually adjust its course based on what it knew, what it sensed with sonar, and also by using the rotating sensor to look for infrared senders located in different locations in the factory.
Subscribe to:
Posts (Atom)
