Smalltalk about BASIC in New York

I've been invited to demonstrate and speak about the new version of Liberty BASIC I'm working on. The venue is the New York City Smalltalk Users Group on April 6th, a Thursday evening. The reason this group invited me is because Liberty BASIC is developed in a version of Smalltalk so it's an interesting project for other Smalltalk developers.

I've been given permission to invite Liberty BASIC users to come also for a sneak peek. The meeting will be held a couple of blocks from Madison Square Garden. I'll post more details about the meeting place when I have them.

I hope we have have a few members of the Liberty BASIC community join us.

Programming for Fun in 10 Minutes

I found an interesting article where the author (Peter Norvig) complains about book titles that promise to teach programming in 24 hours, 7 days, 21 days, etc. He makes a really good point which is that it usually does take several years to become skilled as a programmer. However, in my own experience it doesn't even take a single day to learn enough programming to have fun doing it. Many of my readers will certainly agree with me when I say that doing it for fun is reason enough. If it isn't fun, you're probably not ever going to be any good at it. ;-)

For the curious, here's the link to his article: Teach Yourself Programming in Ten Years

Evolving a language

Over the years I have tried very hard to maintain a simple and backwards compatible syntax with Liberty BASIC. This has worked well for the most part and most people seem to find Liberty BASIC easy to make friends with.

Sometimes in programming languages it is necessary to be willing to break with the past, especially when bad decisions have been made that hurt the programmer. In Liberty BASIC there is probably one decision in particular that I've been meaning to rectify for some time now, and that is the syntax for interacting with GUI widgets.

Originally it seemed like a cool idea to treat windows and widgets like streams, controlling them by printing to them, and getting information by reading out of them. This was fine in theory, but people don't automatically feel comfortable with this. For example:

'set the font to be Arial of size 10
print #myWidget, "font Arial 10"

Several things about this approach are unpalatable. First, printing to a widget is perhaps more of a leap than most people are comfortable with. Instead they might prefer a straight statement, and not put the command in a string.

The other problem with this approach is that it is just too noisy. I came to realize this a few releases ago and implemented a shorthand without the print keyword and comma, like so:

'set the font to be Arial of size 10
#myWidget "font Arial 10"

Well, that is better but still slightly foreign. Behind the scenes it is exanded to the full form.

Okay now here comes the really difficult part. Since we're sending the command as a string, this can get messy if we want to use variables. We need to concatenate a bunch of stuff together.

'set the font to be Arial of size 10
#myWidget "font ";fontName$; " "; fontSize

Can you say ugly?

Okay, so let's fix this. With Liberty BASIC 5 were going to make another evolutionary step that will give us a lot of flexibility. Instead of treating widgets like streams, we'll treat them like the objects they are. So widget commands will be turned into function calls (or method calls in OO parlance):

'set the font to be Arial of size 10
#myWidget font(fontName$, fontSize)

This is much simpler and cleaner. It is also more similar to the conventions that programmers are used to.

There are also commands which return a value. Here is an example in the current syntax that places the contents of an input field into a variable:

'set myVariable to the contents of this input field
#myWidget "!contents? myVariable$"

In our new syntax you will be able to return a value from a function in the familar way, like so:

'set myVariable to the contents of this input field
myVariable$ = #myWidget contents$()

Were still going to support the old syntax for backwards compatibility, but all the examples and documentation will use the new form.

In addition to using this convention to control widgets, we also hope to use this syntax to add some scriptability to the Liberty BASIC IDE. I'll blog about this in more detail in the coming weeks.

Microsoft still supports Visual Basic?

I recently received some email critical of my claim that Microsoft no longer supports or provides Visual Basic. I suppose this is a fair point. They do after all still sell a product called Visual Basic.

So what gives? An awful lot of people don't think that the new Visual Basic .Net product is Visual Basic at all. It's more of a version of C# (a Java clone, more or less) with some BASIC syntax thrown on top. It's not hard to use Google to find many articles of people who agree with this sentiment.

Here are some examples that I found in just minute:

http://www.sqlmag.com/articles/index.cfm?articleid=21050&

And from Wikipedia:
http://en.wikipedia.org/wiki/Visual_Basic_.NET#Comparative_samples
http://en.wikipedia.org/wiki/Visual_Basic_.NET#Controversy_concerning_VB.NET

If there's any dishonesty here, I claim that it's on Microsoft's part. For years people complained that Visual Basic isn't BASIC. Now people are complaining that VB.Net isn't Visual Basic. Where does it end? ;-)

Whatever happened to PEEK and POKE?

Sometimes I'm asked how to PEEK and POKE using Liberty BASIC. The short answer to this is, you can't. The long answer is more complicated.

The original home computers (like the classic Commodore 64, TRS-80, and Apple II models) were designed to be completely open to their owners. Most of the different parts of the computer like the sound, graphics, keyboard and joystick (there were no mice back then) were controlled by mapping them to different memory locations. So, the built-in commands didn't do everything you need? It was common to control the computer's equipment directly by sticking values into the memory locations that control that equipment, and reading the status back out. This was done with POKE and PEEK. This was a lot of fun, and usually useful too.

Since these early machines didn't multitask it was pretty safe to steal control of things away from the BASIC interpreter (which was a much operating system as there was). Then computers started running Windows, the Mac OS, Linux, etc. and allowed more than one program to run at a time. PEEK and POKE became problematic because if one program decided to mess with the screen for example, it might interfere with what other programs need to do their thing. Not only that, but computers today all have different kinds of hardware in them, so even if you could PEEK and POKE the exact memory locations would be different from machine to machine. So that's the bad news. :-(

The good news is that we can still have a power trip. How? Your operating system manages all the hardware for you behind operating system functions. These functions make every computer look more or less the same to the programmer. You can use these functions to do a lot of powerful things and most languages have a way to use them. For example Liberty BASIC programmers can use the CALLDLL command to make Windows API calls, which are the operating system calls of the Windows operating system. These are more complicated in general (and you can fill a whole bookshelf with information about them) than the old fashioned PEEK and POKE, but at least we aren't left without some way to pull rank on our computers. ;-)

So if you're missing the power and coolness of PEEK and POKE, why not try your hand at API calls?

Here is a useful link to get you started: http://libertybasicuniversity.com/lbnews/nl108/api.htm

Redevelopment price hike?

In a comment to a previous post Isaac Raway wrote: "I see that you note you're going to change the syntax for controlling widgets in the new basic you're working on. Awesome! This may actually make me want to switch to LB as my main platform--maybe."

I'm glad to hear this. The new LB is coming along nicely now.

Isaac continues: "However I'm a bit concerned. I've seen this sort of "redevelopment" happen before, and often times it comes with a higher price tag. One of the strong points of LB I think is that it is truly useful but very inexpensive. I think you're the kind of person who realizes that though, so I have faith you'll keep it affordable."

Well, you're right. Pricing is a marketing issue and it isn't always clear whether to raise or lower prices. I can't promise that I will never raise the price of Liberty BASIC (in fact I've done it before) but I am committed to keeping it affordable. Many times I get feedback that LB is too inexpensive and that I should raise the price, so you see this is not a simple matter to determine.

Also remember that now we have a free BASIC (http://www.justbasic.com).