Some years ago I wrote a GUI editor named FreeForm in Liberty BASIC. I did this to show my users that they could build interesting software. FreeForm comes with Liberty BASIC, including source code. The Liberty BASIC editor permits users to add tools to the Run menu, so FreeForm comes as a tool on that menu when Liberty BASIC is installed.
I haven't worked on updating FreeForm in several years, but that hasn't stopped it from growing and becoming better. The Liberty BASIC community took over development and they've produced several versions, and some of these have been included with Liberty BASIC. Right now they're working on a whole new version, which I hope may be included in Liberty BASIC v4.03.
Other really cool tools that LB programmers have created have been code formatters, lint tools, and even whole IDE's. Brent Thorn is working on a complete IDE for Liberty BASIC written in Liberty BASIC called ViviFire, which includes a BASIC scripting language so that users can extend the IDE in itself. Extra cool!
Thursday, October 06, 2005
Sunday, July 10, 2005
JASIC?
Someone recently mentioned a new up and coming BASIC language product called KBASIC and asked me what I thought. I went to Google and found the site. What I discovered there was so complicated that it reminded me of programming in Java using the Eclipse IDE. Eclipse is an excellent IDE, at least in the sense that it makes programming in Java practical (possible?). You need all the power of Eclipse because Java is a big, heavy and complicated way to write software.
KBASIC seems to emulate Java. Even the style of object orientation presented is very Java-like or C#-like and some syntax is borrowed directly from Java. Why do this? BASIC shouldn't need an industrial strength IDE that is as complicated as the cockpit of an F-15.
This is the sort of thing I am trying to avoid with the new BASIC programming language I'm working on. Java is a mountain of rules and exceptions that the programmer must navigate, never forgetting to dot i's and cross t's. Why make a BASIC that emulates Java? This is the sort of thing that caused outcry when Microsoft did away with Visual Basic and replaced it with VB.Net.
I know that some people enjoy mastering complexity, perhaps as a way to find satisfaction in their work. This is incompatible with the way BASIC programming should be. BASIC should be small, simple and fun.
KBASIC seems to emulate Java. Even the style of object orientation presented is very Java-like or C#-like and some syntax is borrowed directly from Java. Why do this? BASIC shouldn't need an industrial strength IDE that is as complicated as the cockpit of an F-15.
This is the sort of thing I am trying to avoid with the new BASIC programming language I'm working on. Java is a mountain of rules and exceptions that the programmer must navigate, never forgetting to dot i's and cross t's. Why make a BASIC that emulates Java? This is the sort of thing that caused outcry when Microsoft did away with Visual Basic and replaced it with VB.Net.
I know that some people enjoy mastering complexity, perhaps as a way to find satisfaction in their work. This is incompatible with the way BASIC programming should be. BASIC should be small, simple and fun.
Saturday, July 02, 2005
On Modernizing BASIC
dave b. responded to my previous post with this (amongst other things):
I hope this nostalgia over the old BASIC command set and the "small is beautiful” fallacy won't hold LB back from evolving into something really useful (which is what programming languages should be).
Really useful for what, Dave? Go and ask the Liberty BASIC community if Liberty BASIC is useful and they will answer with a resounding yes. It is useful for getting a quick program together, useful for learning to program, useful for having fun with a computer, and more too. To make a comparison, Java is also a useful programming language, but it isn't necessarily useful for the same things. There is no universally useful programming language.
I agree with a lot of your ideas, and if you read all of my posts, I think you'll agree that I don't have the simplistic mindset that you seem to imply that I have. I understand abstraction in software better than you apparently think I do.
Nostalgia has nothing to do with Liberty BASIC's faithfulness to classic BASIC syntax, at least not on my part. This is a matter of marketing. You welcome the C-style of doing things with functions. A lot of other people do not. They want an old-style BASIC. I am marketing to these other people. Your advocacy of mutating BASIC syntax into something that is more "modern" does create a new language that is not BASIC, IMHO. Eliminating old BASIC commands and replacing them with functions turns a lot of people off.
I am working on a new BASIC in part to break the backwards compatibility chain with Liberty BASIC. That doesn't mean of course that my new language will necessarily take the direction that you advocate. OPEN "filename.ext" for INPUT as #1 will still be there. I agree with your point that the syntax for controlling widgets in Liberty BASIC is bad, and it will be replaced in the new BASIC. I will do things differently and in an unexpected way, and not to be deliberately contrary but for a reason. I intend to lead with this new language, not follow.
BTW, a lot of people like Liberty BASIC the way it is and don't seem to need anything else. You have decided to move on to another tool that meets your needs better and that's great.
Don't expect Liberty BASIC to become anything but what it is. This is beginning to feel like you're beating a dead horse. :-/
I hope this nostalgia over the old BASIC command set and the "small is beautiful” fallacy won't hold LB back from evolving into something really useful (which is what programming languages should be).
Really useful for what, Dave? Go and ask the Liberty BASIC community if Liberty BASIC is useful and they will answer with a resounding yes. It is useful for getting a quick program together, useful for learning to program, useful for having fun with a computer, and more too. To make a comparison, Java is also a useful programming language, but it isn't necessarily useful for the same things. There is no universally useful programming language.
I agree with a lot of your ideas, and if you read all of my posts, I think you'll agree that I don't have the simplistic mindset that you seem to imply that I have. I understand abstraction in software better than you apparently think I do.
Nostalgia has nothing to do with Liberty BASIC's faithfulness to classic BASIC syntax, at least not on my part. This is a matter of marketing. You welcome the C-style of doing things with functions. A lot of other people do not. They want an old-style BASIC. I am marketing to these other people. Your advocacy of mutating BASIC syntax into something that is more "modern" does create a new language that is not BASIC, IMHO. Eliminating old BASIC commands and replacing them with functions turns a lot of people off.
I am working on a new BASIC in part to break the backwards compatibility chain with Liberty BASIC. That doesn't mean of course that my new language will necessarily take the direction that you advocate. OPEN "filename.ext" for INPUT as #1 will still be there. I agree with your point that the syntax for controlling widgets in Liberty BASIC is bad, and it will be replaced in the new BASIC. I will do things differently and in an unexpected way, and not to be deliberately contrary but for a reason. I intend to lead with this new language, not follow.
BTW, a lot of people like Liberty BASIC the way it is and don't seem to need anything else. You have decided to move on to another tool that meets your needs better and that's great.
Don't expect Liberty BASIC to become anything but what it is. This is beginning to feel like you're beating a dead horse. :-/
Friday, June 03, 2005
What's my story?
As an implementor of BASIC, where am I coming from?
The home computer, a way back machine - In regards to the BASIC programming language, I think my strongest formative influence comes from working with old home computers. There was something wonderful about these machines that plugged into the family television set. They were simple when compared to computers now, and you could get your mind around them. You could master the whole computer because all of the details fit in a 5x8" spiral bound manual a couple of hundred pages long.
Personal Mastery - Perhaps similarly, I used to work on my own cars. I loved working on old Volkswagen Beetles, and I owned a bunch of them. I knew pretty much everything about the Beetle, and I loved knowing all about it. It's about that feeling you get when you master something. Nowadays I take my cars to the experts because I simply cannot understand the new cars. If it breaks down, I call a tow truck. It's harder to love cars today. This is how computers have become.
Interactivity - Let's see. Just like you can take the parts of an old car and flip them over in your hands, see how they fit together and what makes them tick, programming in BASIC on a home computer was like that. You could stop your program, look at variables (flip them over in your hands, so to speak), execute a little line of code on the fly, and resume execution at any point. If you wanted to mess with the video mode, or tweak the sound, or read/write some memory value, you could. The very nature of the machine permitted it. There is was, all laid out before you like clay in your hands and it was not so vast that you were overwhelmed by it all.
BASIC today - So I really feel that if at all possible BASIC programming should still be like this, but it mostly is not. Most BASIC languages today are compilers. This means that once you start to run your program, you cannot just stop it and tweak it. You can't change the code of a running program without needing to restart the program from scratch. In addition, the huge functionality of modern operating systems inspires programming language implementors to continually make their BASIC languages bigger and bigger. This is an artificial barrier to personal mastery.
The reverse 80/20 rule - Okay, since only 20 percent of the Windows operating system functionality is needed 80 percent of the time, why create a programming language that tries to embrace all of it? Home computers did most of what a computer is useful for, and compared to computers today they didn't do much of anything. The reality is that an awful lot of useful things can be done with a very small language.
Small is beautiful - Balance is also beautiful. BASIC should try to strike a balance between being small, and also supporting the most often needed features of Windows, the Mac OS or whatever operating system it runs on.
Aesthetics matter - How does your BASIC language look, like BASIC? I'm not kidding. Many programming languages today that call themselves BASIC don't look anything like BASIC. Tacking ideas and syntax onto BASIC from other languages only complicates things. If it doesn't look like BASIC, it isn't BASIC. I don't mean this in a snobby way. I just think that the feel of the original language is worth preserving because it had a nice simple down to earth quality. Removing that quality also removes some of the fun, and I don't see why we need to do that. ;-)
The home computer, a way back machine - In regards to the BASIC programming language, I think my strongest formative influence comes from working with old home computers. There was something wonderful about these machines that plugged into the family television set. They were simple when compared to computers now, and you could get your mind around them. You could master the whole computer because all of the details fit in a 5x8" spiral bound manual a couple of hundred pages long.
Personal Mastery - Perhaps similarly, I used to work on my own cars. I loved working on old Volkswagen Beetles, and I owned a bunch of them. I knew pretty much everything about the Beetle, and I loved knowing all about it. It's about that feeling you get when you master something. Nowadays I take my cars to the experts because I simply cannot understand the new cars. If it breaks down, I call a tow truck. It's harder to love cars today. This is how computers have become.
Interactivity - Let's see. Just like you can take the parts of an old car and flip them over in your hands, see how they fit together and what makes them tick, programming in BASIC on a home computer was like that. You could stop your program, look at variables (flip them over in your hands, so to speak), execute a little line of code on the fly, and resume execution at any point. If you wanted to mess with the video mode, or tweak the sound, or read/write some memory value, you could. The very nature of the machine permitted it. There is was, all laid out before you like clay in your hands and it was not so vast that you were overwhelmed by it all.
BASIC today - So I really feel that if at all possible BASIC programming should still be like this, but it mostly is not. Most BASIC languages today are compilers. This means that once you start to run your program, you cannot just stop it and tweak it. You can't change the code of a running program without needing to restart the program from scratch. In addition, the huge functionality of modern operating systems inspires programming language implementors to continually make their BASIC languages bigger and bigger. This is an artificial barrier to personal mastery.
The reverse 80/20 rule - Okay, since only 20 percent of the Windows operating system functionality is needed 80 percent of the time, why create a programming language that tries to embrace all of it? Home computers did most of what a computer is useful for, and compared to computers today they didn't do much of anything. The reality is that an awful lot of useful things can be done with a very small language.
Small is beautiful - Balance is also beautiful. BASIC should try to strike a balance between being small, and also supporting the most often needed features of Windows, the Mac OS or whatever operating system it runs on.
Aesthetics matter - How does your BASIC language look, like BASIC? I'm not kidding. Many programming languages today that call themselves BASIC don't look anything like BASIC. Tacking ideas and syntax onto BASIC from other languages only complicates things. If it doesn't look like BASIC, it isn't BASIC. I don't mean this in a snobby way. I just think that the feel of the original language is worth preserving because it had a nice simple down to earth quality. Removing that quality also removes some of the fun, and I don't see why we need to do that. ;-)
Friday, May 20, 2005
Why languages like BASIC are important today
I think it is important that most programming can be done with simple tools. BASIC fits well with the idea that it should be as simple as possible, but no simpler. The average person cannot commit to learning programming languages that need several thick books to explain them. Before you can get anywhere, you need a language that's comfortable to start with. How else can QBasic's tremendous staying power be explained? The last version of QBasic rolled out of Microsoft 13 years ago, and a quick Google search for QBasic reveals nearly a half a million hits!
I also believe that there is a lot of arrogance in the established programming culture. Many software professionals (some of whom aren't especially good at what they do) look with disdain on the users of "hobby languages". Not everyone who writes software does so as their sole profession. Some people need to write small programs for their own use, and so they can be the sole judge as to whether the software is good enough. Other people will only program for fun, and they should not need to answer to anyone.
Once when I gave a demo of Liberty BASIC to a fellow programmer, his response was, "Who would want to use that?" To him it seemed like a toy. He doesn't understand that not everyone needs or wants all the power and complexity of C++.
I also believe that there is a lot of arrogance in the established programming culture. Many software professionals (some of whom aren't especially good at what they do) look with disdain on the users of "hobby languages". Not everyone who writes software does so as their sole profession. Some people need to write small programs for their own use, and so they can be the sole judge as to whether the software is good enough. Other people will only program for fun, and they should not need to answer to anyone.
Once when I gave a demo of Liberty BASIC to a fellow programmer, his response was, "Who would want to use that?" To him it seemed like a toy. He doesn't understand that not everyone needs or wants all the power and complexity of C++.
Thursday, May 19, 2005
Programming and Love of Learning
One of the things I really love about programming is that I love learning new things, and programming is a great medium for working in ideas. Once programming becomes simply work, the spark is gone and it's better to go find something else to do.
Almost 20 years ago I taught myself C, which I really liked a lot at first. That programming language has some ideas that were pretty interesting to me coming from BASIC, but it became clear to me after a while that C programming is more about twiddling the drudgery bits and details than it is about expressing ideas. Don't get me wrong, C is great for certain things. If I were an operating systems builder I probably wouldn't use anything else.
I don't program in C anymore, but I wouldn't discourage BASIC programmers from learning C or any other language. I learned a lot of ideas from my experiences with C, Forth, Smalltalk and Java. There's no substitute for trying a new language. Even if you still only use BASIC it will change your programming style when you are exposed to new ideas, and you will also have more fun.
Learning. I heartily recommend it. :-)
Almost 20 years ago I taught myself C, which I really liked a lot at first. That programming language has some ideas that were pretty interesting to me coming from BASIC, but it became clear to me after a while that C programming is more about twiddling the drudgery bits and details than it is about expressing ideas. Don't get me wrong, C is great for certain things. If I were an operating systems builder I probably wouldn't use anything else.
I don't program in C anymore, but I wouldn't discourage BASIC programmers from learning C or any other language. I learned a lot of ideas from my experiences with C, Forth, Smalltalk and Java. There's no substitute for trying a new language. Even if you still only use BASIC it will change your programming style when you are exposed to new ideas, and you will also have more fun.
Learning. I heartily recommend it. :-)
Monday, May 09, 2005
Programming - Is the word worn out?
You know, I'm wondering if there doesn't need to be a new word for programming. I mean, it's a fine word and all, but it already has too much baggage and history.
How can we get young people interested in programming? We need a new word. One of those cool (kewl?), hip new words. Something that implies a sense of fun and excitement. When the web was born, the word surf was adopted.
Obviously we cannot just come up with a fresh new word and apply it to the technically mundane programming languages like Java, C++ (or Fortran). The word has to apply to a new and fresh kind of programming.
How can we get young people interested in programming? We need a new word. One of those cool (kewl?), hip new words. Something that implies a sense of fun and excitement. When the web was born, the word surf was adopted.
Obviously we cannot just come up with a fresh new word and apply it to the technically mundane programming languages like Java, C++ (or Fortran). The word has to apply to a new and fresh kind of programming.
Wednesday, April 27, 2005
BASIC, not BATAP
This blog is about BASIC, which means Beginners All purpose Symbolic Instruction Code. If it were about Being All Things to All People, the language would be call BATAP. ;-)
I'm inspired to write this because of the plight of General Motors. The world's largest auto manufacturer is losing money in droves. The reason is in their name, the first word of which is General. The problem is that there is so much competition in this world today, that being general is not a strength. If you want to get people's attention, you need to specialize.
BASIC also needs to specialize. The key ideas it needs to specialize in? Easy, simple, approachable, and fun. Does it have power? Yes. It has the kind of power that gives the average person the ability to program computers because of the four qualities I just listed. When Microsoft created Visual Basic (now officially unsupported by the way) they took BASIC out of the domain of the everyday person and tried to make a professional tool out of it. They should have called it Visual BATAP.
BATAP can never be BASIC.
I'm inspired to write this because of the plight of General Motors. The world's largest auto manufacturer is losing money in droves. The reason is in their name, the first word of which is General. The problem is that there is so much competition in this world today, that being general is not a strength. If you want to get people's attention, you need to specialize.
BASIC also needs to specialize. The key ideas it needs to specialize in? Easy, simple, approachable, and fun. Does it have power? Yes. It has the kind of power that gives the average person the ability to program computers because of the four qualities I just listed. When Microsoft created Visual Basic (now officially unsupported by the way) they took BASIC out of the domain of the everyday person and tried to make a professional tool out of it. They should have called it Visual BATAP.
BATAP can never be BASIC.
Sunday, April 03, 2005
BASIC Overloaded?
One reader posted a comment to my last post on the cult of complexity. He remarked on how the OPEN statement in Liberty BASIC is used to open not only disk files, but windows and DLLs. He expressed his desire for a further extension of OPEN for managing TCP/IP sockets. The thing is, I have been planning to do this for some time, and expect to see it in Liberty BASIC v5.0 when it makes its debut.
Using a command for many different things is called "overloading" by programming language designers. So, the OPEN statement is overloaded in Liberty BASIC. This is one of the techniques I use to try and keep BASIC small. I could have added more commands. Maybe for opening a window I could have added CREATEWIN and for accessing DLLs I could have added MAPDLL or some similar name. This might have been okay, but it doesn't keep the language small. I think is crucially important to minimize growth because of the ever expanding list of things a programming language is expected to handle. If I don't fight growth, pretty soon Liberty BASIC will be unmanagable.
If you have ideas that are very close to each other (like opening a file, a window, a socket, etc.) it makes a lot of sense to overload the commands that access them. This can be taken too far, but usually I believe that it isn't taken far enough. Programming languages need to be more general.
Using a command for many different things is called "overloading" by programming language designers. So, the OPEN statement is overloaded in Liberty BASIC. This is one of the techniques I use to try and keep BASIC small. I could have added more commands. Maybe for opening a window I could have added CREATEWIN and for accessing DLLs I could have added MAPDLL or some similar name. This might have been okay, but it doesn't keep the language small. I think is crucially important to minimize growth because of the ever expanding list of things a programming language is expected to handle. If I don't fight growth, pretty soon Liberty BASIC will be unmanagable.
If you have ideas that are very close to each other (like opening a file, a window, a socket, etc.) it makes a lot of sense to overload the commands that access them. This can be taken too far, but usually I believe that it isn't taken far enough. Programming languages need to be more general.
Sunday, March 20, 2005
The cult of complexity
Just the other day I noticed that someone posted a review on Download.com which criticized Liberty BASIC for being a beginner's language. Excuse me? We are talking about BASIC aren't we? Beginner's All purpose Symbolic Instruction Code? Did I miss something?
This reminds me of a software developer I met a few years back at a developer's conference. He asked me about my product, and I gave him a demo. His reaction was "Why would anyone want to use that?" He missed the point entirely. Not everyone has spent the last decade or more of their life developing cutting edge software 40 or more hours a week. If you have to compete with other people, you may well be forced to master the latest and greatest bells and whistles. He forgets that there are scores of people who need to get something done quickly and easily.
Anyone who programmed in BASIC 20+ years ago will agree that Liberty BASIC has more bells and whistles than any BASIC did back then. I'm actually dissatisfied about that. We should be trying to make programming simpler, not more complicated. There is a certain level of sophistication which adds value, but then there is a line which get crossed where things get very murky. Does that new feature make programming simpler, or harder? It can be hard to tell. The more stuff you have to remember, the harder it is to see the forest for the trees.
Aside from getting work done (unless you're programming only for enjoyment), programming is more about becoming smarter and not about proving how smart you are.
This reminds me of a software developer I met a few years back at a developer's conference. He asked me about my product, and I gave him a demo. His reaction was "Why would anyone want to use that?" He missed the point entirely. Not everyone has spent the last decade or more of their life developing cutting edge software 40 or more hours a week. If you have to compete with other people, you may well be forced to master the latest and greatest bells and whistles. He forgets that there are scores of people who need to get something done quickly and easily.
Anyone who programmed in BASIC 20+ years ago will agree that Liberty BASIC has more bells and whistles than any BASIC did back then. I'm actually dissatisfied about that. We should be trying to make programming simpler, not more complicated. There is a certain level of sophistication which adds value, but then there is a line which get crossed where things get very murky. Does that new feature make programming simpler, or harder? It can be hard to tell. The more stuff you have to remember, the harder it is to see the forest for the trees.
Aside from getting work done (unless you're programming only for enjoyment), programming is more about becoming smarter and not about proving how smart you are.
Thursday, March 10, 2005
BASIC is Special
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!
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!
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.
Subscribe to:
Posts (Atom)
