Of course BASIC is special!
I don't know how many times I've run into programmers who smugly stick their noses up in the air at the mention of BASIC. I know I've done the same thing when I hear the name Perl. :-p But in fact, pretty much all programming languages are particularly good for one or more kinds of programming tasks. They're all special!
Okay, but what makes BASIC special? Like most programming languages, BASIC can be used to create many kinds of software. But, BASIC is especially great for small games and utilities. If you need to write a tool or if you're playing around, and if you need to get something (anything?)working right now, BASIC is probably just what the doctor ordered. If you've just gotta write that "mega does it all" killer app in BASIC because you love BASIC? Don't let me stop you (especially if you're using my software to do it)! ;)
I know that people who love BASIC often want to make it good for everything. They add this and that until it has all the features of other languages. They mean well, I think. At a certain point this violates the KISS (keep it simple stupid) philosophy that makes BASIC so great at making computers accessible. After all, sledgehammers are great but they sure are heavy. SledgeBASIC anyone?
So let's keep BASIC special. I know I will!
Thursday, March 10, 2005
Friday, March 04, 2005
What Defines BASIC?
When you think of BASIC, what comes to mind?
What is the core language itself? I implemented Liberty BASIC from what I considered to be the essentials of the language. I am not a VB programmer. My own experience programming in BASIC comes mostly from these influences:
* Benton Harbor BASIC
* TRS-80 BASIC
* Applesoft BASIC
* Commodore BASIC
* MBASIC
* GW-BASIC
Except for Benton Harbor BASIC, these are early flavors of Microsoft BASIC. They all use line numbers and have these commands in common: LET, PRINT, INPUT, GOTO, GOSUB, RETURN, READ, DATA, IF/THEN, FOR/NEXT, DIM, OPEN, CLOSE, etc. There are also functions like VAL, SIN, LOG, LEN, MID$, LEFT$, RIGHT$, STR$, etc.
They are also all command line interpreters. This is an important feature that is mostly lost in modern BASICs. The interactivity of the language is one of the things that makes it approachable and easy to learn. Most newer BASICs are not interactive, including my own. I'm working on a new BASIC which adds interactive features.
So is there a BASIC standard? In fact there is an ANSI standard, developed by a commitee. This standard BASIC is largely ignored by the community of BASIC implementors. Microsoft has been the biggest influencer in the BASIC space, and their QBasic became the defacto standard for BASIC. Visual Basic has not been able to overcome QBasic's popularity for the casual user and hobbiest. Perhaps QBasic's inclusion of an immediate mode (approximating a command line interpreter's interactivity) is one of the reasons why it is Microsoft's last real BASIC?
I'm interested in your feedback on this. My own thoughts are:
* BASIC has a small core of classic commands. Learn these commands and you should be able to be productive in any version of BASIC in five minutes, or it isn't BASIC.
* New commands should be added with reluctance.
* BASIC programmers should not be required to use GUI elements in their programs.
* The BASIC coder should not have to understand C data types to write a program.
* BASIC should be interactive by use of a command line or other innovative features.
* Extensions to any BASIC should not feel like some completely different language so that someone who knows BASIC looks at code written in that dialect and says, "What the HECK is that?!!"
Your thoughts?
What is the core language itself? I implemented Liberty BASIC from what I considered to be the essentials of the language. I am not a VB programmer. My own experience programming in BASIC comes mostly from these influences:
* Benton Harbor BASIC
* TRS-80 BASIC
* Applesoft BASIC
* Commodore BASIC
* MBASIC
* GW-BASIC
Except for Benton Harbor BASIC, these are early flavors of Microsoft BASIC. They all use line numbers and have these commands in common: LET, PRINT, INPUT, GOTO, GOSUB, RETURN, READ, DATA, IF/THEN, FOR/NEXT, DIM, OPEN, CLOSE, etc. There are also functions like VAL, SIN, LOG, LEN, MID$, LEFT$, RIGHT$, STR$, etc.
They are also all command line interpreters. This is an important feature that is mostly lost in modern BASICs. The interactivity of the language is one of the things that makes it approachable and easy to learn. Most newer BASICs are not interactive, including my own. I'm working on a new BASIC which adds interactive features.
So is there a BASIC standard? In fact there is an ANSI standard, developed by a commitee. This standard BASIC is largely ignored by the community of BASIC implementors. Microsoft has been the biggest influencer in the BASIC space, and their QBasic became the defacto standard for BASIC. Visual Basic has not been able to overcome QBasic's popularity for the casual user and hobbiest. Perhaps QBasic's inclusion of an immediate mode (approximating a command line interpreter's interactivity) is one of the reasons why it is Microsoft's last real BASIC?
I'm interested in your feedback on this. My own thoughts are:
* BASIC has a small core of classic commands. Learn these commands and you should be able to be productive in any version of BASIC in five minutes, or it isn't BASIC.
* New commands should be added with reluctance.
* BASIC programmers should not be required to use GUI elements in their programs.
* The BASIC coder should not have to understand C data types to write a program.
* BASIC should be interactive by use of a command line or other innovative features.
* Extensions to any BASIC should not feel like some completely different language so that someone who knows BASIC looks at code written in that dialect and says, "What the HECK is that?!!"
Your thoughts?
Tuesday, February 22, 2005
BASIC and the Original Personal Computers
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.
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.
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.
Saturday, January 29, 2005
Objects and BASIC?
As an implementor of a BASIC language (http://www.libertybasic.com/) I have a lot of people write me with their suggestions. This is a great thing. Some people ask for object oriented features. I know this is all the rage, and I understand object oriented programming well because I've been programming in Smalltalk since 1988, and Java for 3 years. Smalltalk is the first modern object oriented language, and a darn good one.
Here's the problem. BASIC was not conceived as an object oriented language. Just as many implementors of contemporary BASICs have made the language unrecognizable by piling the features of C and other languages on top of it, an object oriented BASIC risks becoming some other language entirely.
Any really good object oriented language is objects all the way down. In these languages (Smalltalk and Self for example) even numbers, strings, and boolean values are objects. Everything is treated uniformly. It would be a supreme challenge to redesign BASIC so that it had this kind of uniformity. It just wouldn't look like BASIC anymore. :-(
This doesn't mean that BASIC couldn't be extended to have some object oriented ideas. To do so it would be important to identify what the simplest and most useful ideas of objects are, and to invent a very small syntax extension for the BASIC language to support these ideas. I think any object oriented extensions should be simple and consistent enough to be learnable in five minutes. The goal should be maximum bang for minimum buck. Otherwise, why bother when there are already so many other object oriented languages?
Here's the problem. BASIC was not conceived as an object oriented language. Just as many implementors of contemporary BASICs have made the language unrecognizable by piling the features of C and other languages on top of it, an object oriented BASIC risks becoming some other language entirely.
Any really good object oriented language is objects all the way down. In these languages (Smalltalk and Self for example) even numbers, strings, and boolean values are objects. Everything is treated uniformly. It would be a supreme challenge to redesign BASIC so that it had this kind of uniformity. It just wouldn't look like BASIC anymore. :-(
This doesn't mean that BASIC couldn't be extended to have some object oriented ideas. To do so it would be important to identify what the simplest and most useful ideas of objects are, and to invent a very small syntax extension for the BASIC language to support these ideas. I think any object oriented extensions should be simple and consistent enough to be learnable in five minutes. The goal should be maximum bang for minimum buck. Otherwise, why bother when there are already so many other object oriented languages?
Saturday, January 22, 2005
Simplicity Revisited
In my last post I explained that classic BASIC was implemented as an exploratory programming environment. It occurred to me that my earlier post about simplicity touches on an extremely important aspect of BASIC's exploratory qualities.
List most software today, programming tools do 101+ things. This reminds me of a Nova documentary I saw about jet fighter planes. The cockpit of a modern jet fighter has more dials than a clock store and more buttons than a sewing shop. The documentary explained was that these were all there so that the pilot would be able to do lots of useful things. As it turns out, not many of the things in the cockpit are useful for flying an airplane in combat.
As an exploratory programming language, early BASIC was simple to learn. There was no GUI. Windows, icons and other graphical features do not always improve software (although they can). There were only a few commands and ideas that you needed to learn. Was this enough? Maybe not, but its simplicity is one of the essential concepts that made it successful.
"Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away." --- Antoine de St. Exupery, Wind, Sand, and Stars, 1939
List most software today, programming tools do 101+ things. This reminds me of a Nova documentary I saw about jet fighter planes. The cockpit of a modern jet fighter has more dials than a clock store and more buttons than a sewing shop. The documentary explained was that these were all there so that the pilot would be able to do lots of useful things. As it turns out, not many of the things in the cockpit are useful for flying an airplane in combat.
As an exploratory programming language, early BASIC was simple to learn. There was no GUI. Windows, icons and other graphical features do not always improve software (although they can). There were only a few commands and ideas that you needed to learn. Was this enough? Maybe not, but its simplicity is one of the essential concepts that made it successful.
"Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away." --- Antoine de St. Exupery, Wind, Sand, and Stars, 1939
Friday, January 14, 2005
Exploratory Programming and BASIC
One idea that hasn't been written much about lately in the computer press is "exploratory programming." This idea was very popular about a decade ago and it refers to powerful programming tools that make it easy and quick to try out different ideas. Smalltalk is one of the best examples of an exploratory programming environment. Smalltalk lets you make objects that "live" in your programming IDE and then you can play with them to see what happens. You don't need to compile a program at all to build software. Why does this matter? Exploratory programming helps make programming easier, more fun, and less intimidating. You can play around with little pieces of the program you're trying to create until you feel that you understand it well enough to put it all together.
Okay, what does Smalltalk have to do with BASIC? I'm glad you asked. :-) BASIC was originally conceived as an exploratory programming tool. BASIC has an interpreter loop, just like Smalltalk. Write a little code, use RUN to execute just a piece of your program if you like. Stop a running program, check the value of variables and change them. Rewrite just a line of code if you like. Restart the program. Execute code without even adding it to your program, straight from the command line. Most BASICs on home computers would let you play with the hardware, from graphics to audio to devices connected to an I/O port, again straight from the command line. You were free to explore.
Sadly BASIC is not like this anymore. Almost all BASIC language software today compiles to a program that cannot stopped, tweaked, modifed and restarted. Even our own Liberty BASIC http://www.libertybasic.com are like this (except that Liberty BASIC you can evaluate code in the debugger and by using the eval() function).
We are working on a new BASIC to bring exploratory programming back. This will not be an old fashioned line numbered interpreter. This new BASIC will provide a workbench where you can make changes to running programs, and where you can try out small or large BASIC snippets just to see what they do.
More information coming...
Okay, what does Smalltalk have to do with BASIC? I'm glad you asked. :-) BASIC was originally conceived as an exploratory programming tool. BASIC has an interpreter loop, just like Smalltalk. Write a little code, use RUN to execute just a piece of your program if you like. Stop a running program, check the value of variables and change them. Rewrite just a line of code if you like. Restart the program. Execute code without even adding it to your program, straight from the command line. Most BASICs on home computers would let you play with the hardware, from graphics to audio to devices connected to an I/O port, again straight from the command line. You were free to explore.
Sadly BASIC is not like this anymore. Almost all BASIC language software today compiles to a program that cannot stopped, tweaked, modifed and restarted. Even our own Liberty BASIC http://www.libertybasic.com are like this (except that Liberty BASIC you can evaluate code in the debugger and by using the eval() function).
We are working on a new BASIC to bring exploratory programming back. This will not be an old fashioned line numbered interpreter. This new BASIC will provide a workbench where you can make changes to running programs, and where you can try out small or large BASIC snippets just to see what they do.
More information coming...
Saturday, January 01, 2005
Simplicity
There was an interesting thread on our conforums site http://libertybasic.conforums.com recently where we discussed Windows API calls. Someone mentioned that the most useful API calls should all have BASIC equivalents.
I understand the reason this was suggested, but I have to disagree. I don't know how many people come to Liberty BASIC because they tangled with Visual Basic and found it to be too large and complicated. I program in Java for a lot of my work. It's big and unwieldy (it wasn't when it arrived in 1995). I can vouch for small is beautiful.
Most programming tasks don't need a big language.
Another important point to keep in mind is that as we move toward Macintosh and Linux versions of Liberty BASIC, we'll have to be very careful not to add many platform specific commands.
I understand the reason this was suggested, but I have to disagree. I don't know how many people come to Liberty BASIC because they tangled with Visual Basic and found it to be too large and complicated. I program in Java for a lot of my work. It's big and unwieldy (it wasn't when it arrived in 1995). I can vouch for small is beautiful.
Most programming tasks don't need a big language.
Another important point to keep in mind is that as we move toward Macintosh and Linux versions of Liberty BASIC, we'll have to be very careful not to add many platform specific commands.
Tuesday, November 23, 2004
The death of programming
Why don't people create their own software anymore?
1) They don't have to. They can just buy what they need.
While this is true, there are so many times when packaged software doesn't do exactly what is needed. There are also so many kinds of useful software that could be written that will not make it onto store shelves.
2) They don't know that they can create their own software.
In fact they may even wonder why they should bother. They don't know what they're missing if you ask me. Programming is a much better way to spend brain cells than watching TV or surfing the web.
3) It is really hard to create software with the popular languages (Java, Perl, C++).
This is not possible to overemphasize! Why these intractable wrecks have become popular is beyond me. Don't get me wrong. These languages have their place (except for Perl, I mean), but they aren't suitable for the average guy or gal. These are programming languages for lawyers.
4) The computer doesn't come with an easy to use programming language anymore.
This is SOOOO important. It used to be that when you turned the average computer on, the first thing it did was start BASIC. You could start programming immediately, and it was very easy to pick up. Nothing bad happened if you made a mistake, and it was fun!
5) People think that programming isn't an important part of computer literacy.
Everyone will admit that it is good to understand cars if you are going to drive one. It helps you to drive more safely, and if you break down somewhere you stand a chance of helping yourself out of a tough spot. It is no different with computers. If you learn to program computers it helps you to take advantage of them, and not the other way around.
1) They don't have to. They can just buy what they need.
While this is true, there are so many times when packaged software doesn't do exactly what is needed. There are also so many kinds of useful software that could be written that will not make it onto store shelves.
2) They don't know that they can create their own software.
In fact they may even wonder why they should bother. They don't know what they're missing if you ask me. Programming is a much better way to spend brain cells than watching TV or surfing the web.
3) It is really hard to create software with the popular languages (Java, Perl, C++).
This is not possible to overemphasize! Why these intractable wrecks have become popular is beyond me. Don't get me wrong. These languages have their place (except for Perl, I mean), but they aren't suitable for the average guy or gal. These are programming languages for lawyers.
4) The computer doesn't come with an easy to use programming language anymore.
This is SOOOO important. It used to be that when you turned the average computer on, the first thing it did was start BASIC. You could start programming immediately, and it was very easy to pick up. Nothing bad happened if you made a mistake, and it was fun!
5) People think that programming isn't an important part of computer literacy.
Everyone will admit that it is good to understand cars if you are going to drive one. It helps you to drive more safely, and if you break down somewhere you stand a chance of helping yourself out of a tough spot. It is no different with computers. If you learn to program computers it helps you to take advantage of them, and not the other way around.
Sunday, November 21, 2004
Introduction
Greetings!
I decided to establish this blog as a place to share my thoughts about programming in BASIC. I am the author of two versions of BASIC:
Liberty BASIC - http://www.libertybasic.com
Just BASIC (a free programming language) - http://www.justbasic.com
I'm working on a third yet unnamed BASIC as well.
So if you're a fan of BASIC, I hope you will enjoy reading my posts here and I invite your comments.
Thanks,
-Carl Gundel
I decided to establish this blog as a place to share my thoughts about programming in BASIC. I am the author of two versions of BASIC:
Liberty BASIC - http://www.libertybasic.com
Just BASIC (a free programming language) - http://www.justbasic.com
I'm working on a third yet unnamed BASIC as well.
So if you're a fan of BASIC, I hope you will enjoy reading my posts here and I invite your comments.
Thanks,
-Carl Gundel
Subscribe to:
Posts (Atom)
