Before the IBM PC there were Home Computers, of which there were many, many brands and models, all completely different from each other. Usually a Home Computer plugged into your television set, even though you could buy a monitor if you wanted a sharper picture. I loved the Home Computers because they were all a little different from each other, each inspired by some designer's whim. That was great because it made you think when you saw something that was a new idea.
Once the standard IBM PC was introduced, the market began to do nothing but make copies of this machine. This was actually a kind of death to innovation, and at a time when small computers were still very immature. Our industry decided that all computers should be like this 'IBM thing' when we didn't really even know yet how to build computers. In most respects, today's PC is still just a faster and bigger version of that now 25 year old design. :-(
One key thing that was really great about the Home Computer was its programming language, which was almost always BASIC. Each version of BASIC was a little different, but close enough that you could sit down in front of a computer you've never seen before and start writing something right away.
Another important quality of the Home Computer was its simplicity. Most of the time you only needed a couple of hundred pages to explain how to make any computer's hardware do whatever you wanted. All the graphics and sound, keyboard, joystick, I/O ports, memory maps, etc. were completely documented. And these things were also simple enough that you didn't need a degree to understand how they worked. BASIC made this even easier because you could use the command line interpreter to interactively play with the hardware. This was really personal computing, in the truest sense of the word.
IBM PC is a misnomer.
Tuesday, February 22, 2005
Sunday, February 13, 2005
Aspects
One of the big buzzwords in programming today is 'aspects'. More and more systems claim to be aspect oriented. Just what does this mean?
An aspect is like a perspective. If you look at the back of your hand, you will see those things that are about its backside. That is an aspect. If we do the same with software, this gives us a useful tool. If we take a video game for example, we might have several aspects:
- Display
- Sound
- User input
- Game rules and behavior
What is the point of all this? If we work hard to write libraries of code about these parts of the game, where these different parts of the program don't refer to each other, this gives us a useful level of interdependence, or decoupling as it's calling in software engineering. This is what aspects are for.
If we make each aspect of our programs independent from each other, this makes them easier to understand, to re-use in other programs, and to debug.
Most aspect oriented software use objects as a way to make their aspects work, but this isn't required. You can use the tools at your disposal to do the same thing. The main tool is your brain.
Some tips:
- Don't use global variables without good reason
- Give preference to SUBs and FUNCTIONs over GOSUB/RETURN
- Name things well so it's easy to answer the question "Does that belong in this area of my program?"
Finally, don't get hung up on the word 'aspect'. It's a useful word for thinking about software design, but it's just one word. ;-)
An aspect is like a perspective. If you look at the back of your hand, you will see those things that are about its backside. That is an aspect. If we do the same with software, this gives us a useful tool. If we take a video game for example, we might have several aspects:
- Display
- Sound
- User input
- Game rules and behavior
What is the point of all this? If we work hard to write libraries of code about these parts of the game, where these different parts of the program don't refer to each other, this gives us a useful level of interdependence, or decoupling as it's calling in software engineering. This is what aspects are for.
If we make each aspect of our programs independent from each other, this makes them easier to understand, to re-use in other programs, and to debug.
Most aspect oriented software use objects as a way to make their aspects work, but this isn't required. You can use the tools at your disposal to do the same thing. The main tool is your brain.
Some tips:
- Don't use global variables without good reason
- Give preference to SUBs and FUNCTIONs over GOSUB/RETURN
- Name things well so it's easy to answer the question "Does that belong in this area of my program?"
Finally, don't get hung up on the word 'aspect'. It's a useful word for thinking about software design, but it's just one word. ;-)
Thursday, February 10, 2005
Building Systems in BASIC
Let say you want to write a program in BASIC that manages sales information for a small store. You need to write code for the following things:
- Data entry+User Interface
- Database management
- Reporting
- Graphing
Okay, fine. You create a program called salesmanager.bas and create sections of code for each subsystem. As you build your library of code, you run your program to try it out. When you're done trying out your program, you shut it down and go back to writing more code. Then you try your program again, etc.
This is the traditional way to create programs, and it works great for small programs. When a program gets large, it takes longer and longer to start up the program and try it out.
What if your BASIC could *also* do it in the following way?
- Create a program called salesdatabase.bas and write the simplest possible database manager (one that doesn't really do anything). Start it up and give it a runtime name SALESDB. Leave it running.
- Now create another program called salesui.bas that implements the simplest GUI. Start that up and leave it running.
- Write a function to salesdatabase.bas for adding a new sale and save it. It becomes available to the salesdatabase.bas program that is already running!
- Now add a menu and subroutine to open a simple dialog box for the salesui.bas program. This dialog box code contains a call to the add sale subroutine on the SALESDB program. Without restarting the GUI, the menu is available. You can test it immediately!
Keep adding more code to these programs and 'grow' them a little at a time. Add the reporting and graphing modules to your system in the same incremental way. You can build a large system in this way by 'growing' it in little bite sized ways.
- Data entry+User Interface
- Database management
- Reporting
- Graphing
Okay, fine. You create a program called salesmanager.bas and create sections of code for each subsystem. As you build your library of code, you run your program to try it out. When you're done trying out your program, you shut it down and go back to writing more code. Then you try your program again, etc.
This is the traditional way to create programs, and it works great for small programs. When a program gets large, it takes longer and longer to start up the program and try it out.
What if your BASIC could *also* do it in the following way?
- Create a program called salesdatabase.bas and write the simplest possible database manager (one that doesn't really do anything). Start it up and give it a runtime name SALESDB. Leave it running.
- Now create another program called salesui.bas that implements the simplest GUI. Start that up and leave it running.
- Write a function to salesdatabase.bas for adding a new sale and save it. It becomes available to the salesdatabase.bas program that is already running!
- Now add a menu and subroutine to open a simple dialog box for the salesui.bas program. This dialog box code contains a call to the add sale subroutine on the SALESDB program. Without restarting the GUI, the menu is available. You can test it immediately!
Keep adding more code to these programs and 'grow' them a little at a time. Add the reporting and graphing modules to your system in the same incremental way. You can build a large system in this way by 'growing' it in little bite sized ways.
Subscribe to:
Posts (Atom)
