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?
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
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...
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.
Subscribe to:
Posts (Atom)