Steve. A. is pretty new name for me, though i have known he’s dialect BluntAxeBasic somehow. Anyway, after examining he’s dialect and the tutorial he has created with it, i was impatient to know more about him, the QDepartment group and the tutorial/dialect he has created. So, i emailed to him and now, here we are.
E.K.V: So Steve, let’s start with some general statics and features about you. Who, what and where?
S.A: My name is Steve Arbayo, I live in Southern California, USA, on the western edge of the Mojave Desert. I grew up living near the coast, but, seeking to escape the congestion of inner city living, I moved to the desert near the mountains. My sport is fishing and living near the mountains offers some great places to fish. I mainly fish for trout and large mouth bass, but, fishing for any kind of fish is fun.
When I was young, I took an interest in radio electronics. It started when I was a kid, one of my uncles gave me a crystal radio kit that I built and used to listen to distant radio station at night. Winding coils and building tuners became a passion of mine. My interest in radio stuck with me through out my young adult life. I always kept a work bench with a soldering iron, where I was always working on building a radio circuit or repairing something. In the 1970’s, in addition to radios, I started building and experimenting with transistor logic and memory circuits. I was building all the elementary components that make up a CPU. I then started learning hex code and machine language. At that time, small computers weren’t readily available and those that did exist were extremely expensive.
In 1977, I bought a Radio Shack EC-4000 Programmable Calculator. For the first time, I was actually programming, in a language, for a specific CPU.
In the early 1980’s I bought a Timex-Sinclair TS-1000 and a Commodore C-64. The C-64 had a ton of programs available on plug-in cartridges, but, I actually spent more time working on the TS-1000, programming in machine and assembly language and learning BASIC. When I got a program working on the TS-1000, I would then try it out on the C-64.
I think because of my prior experience with transistor logic circuits and dealing directly with the hardware, I actually enjoyed machine and assembly language programming more than I did BASIC. I liked knowing what the actual hardware was doing and being able to manipulate it at that very low level.
By the mid 80’s I was so involved in computers that I decided to make my hobby start paying for itself. I started working with a friend as a computer consultant. I hooked up with my local Radio Shack dealer, (the owners were friends of mine), as my source for computer hardware. As a consultant, I was advising small business owners on how to computerize their business and teaching them how to use the computer. And, of course, when it was needed, I was writing programs for those computers. Before long, I saw that there was going to be a future in computer networking. Initially, I worked with a number of different LAN networks, but, soon specialized in Novell Networks, exclusively.
With the advent of the internet and other related factors, I retired from networking in 2000.
I am semi-retired, but, among other things, I do some internet related programming and I am always furthering my education in computer science.
I wrote my first (primitive) assembler, way back on my TS-1000, for the Z80 CPU. Ever since then I have always wanted to continue with that type of programming. Staying very low-level, talking directly to the machine. Unfortunately, modern operating systems do their very best to remove the programmer from the machine. Writing interpreters, compilers and assemblers is as close as you can get to the machine these days, given the operating systems. That takes us to where we are now.
E.K.V: You are also a founder of QDeparment group at yahoo. Would you tell something about why it was founded and from early days of it?
S.A: Back in 2000, I was interested in acquiring an updated version of QuickBasic 4.5. I also needed something that would take some of my old QBasic code and recompile it to run on the Win32 platform. Also, I was doing CGI programming and I wanted a dialect of BASIC that was cross-platform and would run on Linux, for CGI stuff.
That’s when I discovered Rapid-Q. This dialect was still in development, but, the developer seemed to be working at a rapid pace in fixing bugs and adding new features. There was also a good user group that had formed.
Then, completely out of nowhere, development stopped and word got out that the developer had sold the source code for Rapid-Q to a commercial software company.
Many members of the user-group felt that we had been betrayed. Even though it was not an open-source project, we felt that we had been used by the developer and had been his unwitting beta-testers. When he got the code to a point that it was a viable product, with a user-base of several thousand users, he sold it.
We were shocked! As a group, we were thrown into complete disarray. Many members had invested a great deal of time in both learning how to use the compiler and in finding the bugs and offering up fixes and work-arounds to known issues.
Before the dust settled, about a hundred of us decided that we needed to break off our relationship with Rapid-Q and form a development group of our own. We set out with the purpose of learning and teaching each other how to write our own interpreters and compilers and making the results entirely “open source”. We had a mission.
One of our members (named City-Zen) created a new user group on ‘e-groups’ and named it ‘QDeparment‘. The name QDeparment has it’s origins in the James Bond movies. “QDeparment” was the section where all the neat gadgets that James Bond used were invented and developed.
As a group, we decided that whatever we wrote it should be written in C/C++. So, we set out to first learn C and C++. Now, mind you, not a one of us knew anything about writing compilers or interpreters. Or if we did, it was purely theoretical and hadn’t been put into practice.
After a time of discussion with no development, a few people branched off, believing that any development had to be done at Source-Forge. A few formed small groups of their own.
There remained a good number of us who were committed to getting something started and actually writing a compiler and interpreter.
While we were learning, there was still no progress on writing a compiler. Not until one day, when group member Darren Turland submitted a small snippet of code to the group that suggested how an interpreter might read in and parse a few lines of code.
This was the “Ahhah!” moment. This small, well documented piece if code that Darren wrote became the basis for everything that followed at QDeparment.
E.K.V: You really got my interest now. Where this piece of code by Darren did lead in near future back then?
S.A: The zip file is now in an archive of important group resources. http://tech.groups.yahoo.com/group/files/A__Resources/dlanguag.zip
When Darren first uploaded it, (11/21/2000), he simply dumped it into the QDeparment files section. It wasn’t in a folder. Darren later deleted the file, (perhaps thinking it wasn’t very good), after he had written and uploaded better code examples.
Later, believing that Darren’s original code was significant, (to the group at least), I re-uploaded it and relocated it into an archive folder, so that it wouldn’t get misplaced.
This is what I wrote in the file description:
“This is Darren Turland’s source-code for his basic interpreter and compiler, (ver.1.0). It was studying these 2 bits of code that allowed me to understand how the interpreter and compiler work. It’s simplicity makes it easy to understand.”
E.K.V: Did this lead to a developement of multiple different interpreters, tutorials and such or where? What major things this did bring to the community?
S.A: QDeparment was created on Oct. 21, 2000.
One month later, on Nov. 21, 2000, Darren T. posted this message:
“humble beginnings…..
ok
here is my attempt at the start of a basic interpreter. no laughing, although do comment on code and best practive please. I have based it on basec as the source was freely available, but have written my own version to aid in my C learning. Obviously the code is full of my own tests but has the bare bones, of a token picker, bytecode maker, .exe generator, and an interpretor to read bytecode.
dont expect too much as it is VERY limited and was started as an excercise more than anything.
Darren”
Initially, we were quite disorganized. We didn’t know where to begin. We were all seeking direction and there was no one to give it. We were doing a lot of experimentation, learning to use the various C/C++ compilers. There was a lot of Q&A taking place at the group. Everyone was asking how to do something and others finding the answers and offering suggestions. It was a very productive time at QDeparment.
However, there was no organized work on an interpreter or compiler. If anyone was working on a compiler, they were doing it on their own and not producing any code to the group. The people who were speaking the loudest, (so to speak), in regard to what direction we should be taking, were the ones who felt that we needed to setup a Source Forge project and do our work there. Not everyone agreed with that idea. I didn’t see any advantages in doing that. It seemed to me, that a Source Forge project would turn any work that was done into a closed project. Open only to a select few. Most of us liked the free exchange of ideas and shared source code. We had a great sense of camaraderie. Everyone was feeling they had something to contribute and it was encouraged.
In our first week we had over 200 posts to QDeparment. Lots of code snippets were being posted, lots of advice and information was being shared. Things went on like this for the first month, with still no one producing any hint of a compiler.
When Darren uploaded his code, there was a complete silence.
I don’t know why, but, there was nothing said about it. I think we all downloaded it, printed it out and were pouring over it, trying to understand it.
By early Spring, 2001, a handful of us were actively working on constructing compilers and interpreters and sharing source code. By this time, I had uploaded my first version of Bxbasic.
Here is the command list for the first version:
REM, CLS, GOTO, BEEP, END, PRINT
E.K.V: And now, what is status of QDeparment group?
S.A: Activity over the past couple of years hasn’t been what it once was.
Economics is a great influencer of what people do in their free time. Almost as soon as QDeparment was started, the “dot-com” bubble burst. A noticeable slow in group activity could be seen. When the credit bubble, in the economy, burst a couple of years ago, group activity came to a complete stop. We still have over 250 group members. They just aren’t too active, in terms of submitting code or posts. Many have moved on to other projects or other interests, but remain group members.
Many past and current members have contributed greatly, in developing programming tutorials, providing source code for interpreters and compilers which they have designed and built and sharing what they know and have learned. There are some very knowledgeable people at QDeparment that I and others rely on to answer some very complex programming questions.
Just recently, I had a difficult programming question. As is my habit, when I have a difficult problem to solve, I spent several hours on Google, MSDN and many programming sites, searching through old posts and FAQs, trying to find an answer. I could find discussion regarding the problem, but, not a solution to my problem. Before giving up for the day, I decided to post my question on QDeparment. Within minutes, a group member posted back with not only the solution, but, source code supporting it.
That is the status of QDeparment today.
E.K.V: Now let’s move to your personal project, BluntAxeBasic. Beside of creating a basic dialect, you have created a tutorial about it. Which was first, passion to create a tutorial or the dialect itself?
S.A: The Dialect.
When I began writing Blunt Axe Basic, I had two tasks before me:
I have a number of reference books and manuals for various dialects of BASIC and I’ve always been pretty good at “reverse engineering” things, so if I can see what something does, I can usually figure out how to duplicate it.
The problem was, I hadn’t done much programming in C prior to that. One advantage I did have was, I had a stack of books on C programming that I had bought over the years. So, with a stack of C books in front of me, I first had to figure out how to do the things BASIC did, but, in C.
That is not as simple as it may sound.
BASIC statements don’t exactly translate directly into C statements. In other words, a BASIC statement that reads this way: PRINT “hello world!” might read like this in C: printf(”hello world!”); .Now the casual observer might say, okay so you make a few, slight syntax adjustments and you move on to the next thing.
Well, the above was a very simple example. C has no equivalent for this BASIC statement: LET a$ = “hello world!”. I felt like I was reinventing the wheel, not reverse engineering it.
I never set out to write a tutorial.
I worked on my interpreter for many months, all along with the advise and help from the members at QDeparment. Often times I would post a piece of code that had given me trouble and illustrate how I had overcome any difficulties. As a rule, I always coded using two different C compilers. That way, if something I wrote did work, I knew it wasn’t an accident or a fluke. Then, I’d upload my latest version and ask others to compile or test it, to be sure it was working.
One thing that I did do was to document as extensively as I could, the code I was writing. I wanted to be sure that the reader didn’t have to waste time trying to figure out what a piece of code was doing. I felt that they should be able to look at my documentation or comments and understand what the code did. In this way, the code was there more for reference. After a while, my documentation of the code was more extensive than the code itself. I had taught programming before, so I knew the importance of good documentation.
E.K.V: Was there moments of pure “i’ll give up” often when you were working with the BluntAxeBasic? After all, even you do sound man who had a passion, i can imagine lot’s of mountains in your way.
S.A: Give up ? No.
I never thought of giving up. I have had several setbacks, delays and “put it on the back burner” you might say. But, I have never thought of giving up. Blunt Axe Basic has always been an ongoing “work in progress”. Most of the work done on Bxbasic was done between 2001 and 2004. I have recently stepped up production, so to speak, by adding new functionality and features.
In the beginning, once I figured out some of the easy stuff, I was able to make a lot of progress in a relatively short time. For me, one of the hardest parts was in constructing an expression parser to evaluate arithmetic expressions. I initially built one, just by trial and error, but, it was poorly designed and kept giving me problems. It was designed in somewhat of linear fashion and worked mostly, but, not always. The more complex the expression, the more likely it was going to fail. I was kind of stalled at this point. I had heard of and read about Recursive Descent, but, I hadn’t used it before.
I decided to revisit Jack Crenshaw’s book titled: “Let’s Build A Compiler”.
I had read through it previously and put it down, not gaining much from it, because there were two things wrong with it, from my point of view.
One: it was written using Pascal as the base language and I didn’t know Pascal.
Two: it was targeted for the Motorola 68000 processor, which was also a problem for me.
It was written in a language I didn’t use, targeted for a machine I didn’t have. I had no way of testing any of his code or running any of his examples.
My solution was, using C which I did have and the A86 assembler which I also had, to completely rewrite the source code portions of his tutorial so that I could actually run the examples in Crenshaw’s book. It took me several weeks, but I got it done.
Now, this wasn’t just a simple, “line of code” for “line of code” translation. I had to spend a lot of time looking up Pascal statements and M68x assembly code. Additionally, either I was misinterpreting some of his writing or some of his code simply didn’t work. And, there were breaks in the continuity of his text. After a time, I realized that Jack had written his book over a period of several years, with breaks of several months in between.
To me, that explained a lot. It appeared that, when he would resume writing after a long break, he would forget his place. That also explained the fractures in his code. Also, he never finished it. There is a gaping hole at the end, where the next chapter should be. At any rate, once I was able to fully understand Jack’s meaning and make my translations, I was able to fill in many of the blanks. When I was through with the translation, I had a fully functioning Recursive Descent Parser for math expressions. To me, this was a piece of art. I decided to upload the translation I had just done, along with my added comments and notations, to the QDeparment, (with all due credits to Jack Crenshaw).
With this newly gained knowledge, I did another (one of many) complete rewrite of Bxbasic. I also trashed my If-Then-Else parser that I had previously written and used the same approach as the math parser. I may have had to stop and completely rewrite someone else’s writing, so that I could better understand a point and gain the knowledge I needed, but, I’ve never wanted to give up.
E.K.V: Now what is current status with BluntAxeBasic? Where you are taking it, what new are integrated and perhaps, is there something you will drop out?
S.A: As of this date, BluntAxeBasic has progressed only slightly since I finished writing the tutorial, (by my standards, that is). “Blunt Axe Basic”, the tutorial, was actually written back in 2004, over a three or four month period. It sat in the QDeparment archives until the Spring of 2009, when I published it as an “e-book”.
Early in the Winter-Spring of this year (2010) I began working on Bxbasic, looking for bugs and fixing them and adding some minor features as I went along.
At this point, I need to mention that there is a fork of Bxbasic, which I call BxbAsm. I began writing BxbAsm after I finished writing my “Let’s Build A Scripting Engine-Compiler” tutorial. BxbAsm is an actual compiler “front-end” that takes Bxbasic scripts and generates assembly language output, with the use of MASM, (Microsoft Assembler), as the compiler “back-end” to produce Windows executable files. The reason I mention BxbAsm, at this point is that, this past Winter I wanted to really test the abilities of Bxbasic and see how large a program I could write with it and at the same time, test its breaking points.
Now, BxbAsm is written entirely in C and what I did was I wrote a version of BxbAsm entirely in Bxbasic script. When it was done, Bxbasic, (the interpreter), was running a program that just happened to be a compiler “front-end”, generating Assembly Language that was ultimately assembled and linked by MASM. This was a lot of fun.
It is the largest program I have written in Bxbasic and it caused me to make several additions and refinements to Bxbasic. This exercise took Bxbasic out of the realm of a theoretical model or simple tutorial and made it into a viable programming tool.
In the past few months I have added a number of small improvements to Bxbasic. My immediate goal is to take Bxbasic out of its current state of being a ’subset” of GWBasic and QBasic. Being a “subset” means that, (unless it has something else and more important to offer), it is only partially useful. I made a list of standard keywords used in GWBasic and started crossing them off the list as I added those new features. At this point, Bxbasic now has all the standard math functions and a few extras. When that list is completed, I will make a list of QuickBasic keywords.
One important thing that Bxbasic needs to have added is graphics capability. Even GWBasic had simple Draw, Line, Circle and Paint capabilities. At this point I’m planning to use OpenGL for the graphics.
I don’t want to drop anything out of Bxbasic, but I am concerned with “bloat”. Unlike a compiler, which can produce the smallest, compact executables possible, an interpreter has to grow in size as its capabilities are extended. I don’t care if my compiler is 100kb or 1-megabyte in size. After it compiles my programs I’m done with it. An interpreter is a different story. As you add new features to your interpreter the size of the scripting engine increases along with those features. A simple “hello world” script might be running on a 200kb, 400kb or 1-Meg engine needed to run it, depending on the completeness and capability of the interpreter.
Just how much of the Windows or Linux API do you want to include into your scripting engine. I know, some people keep the interpreter size down by using DLLs. To me that’s not gaining anything. You are just taking that extra “bloat” and hiding it in a DLL.
That’s where Bxbasic is now. I want to add graphics and API capabilities, but, keep the “bloat” down as well.
E.K.V: Beside of developing the tool (bxbasic itself), how important you see developement of user community around a basic dialect? In future, do you have plans for starting to create more surroundings for end-users?
S.A: Well, that’s an interesting question. Right now today, its not that important.
Basic (any dialect) by definition, is supposed to be easy to learn and easy to use. The problem is that the operating systems have become so much more complicated over time. A simple dialect with Goto, Print, If-Then-Else, just aren’t enough anymore. People, (that includes programmers), want to be entertained.
There are so many programming languages available today that meet the criteria of being easy to learn and easy to use, let alone the many dialects of BASIC. I haven’t had time to give it too much thought about building up a community or developing a user group around Bxbasic. Not at this time.
Consider for a moment that VB hardly resembles any Basic I ever used in the past, it costs perhaps more than any other and yet has possibly the largest end-user community.
To build up a community of end-users there are two or three aspects that must be taken into consideration:
When you construct something, then that is your product, whatever it is. In the case of a programming tool, will it do things better or easier than another tool that is equally available?
Bxbasic still doesn’t have an IDE. That was never a high priority to me, to rush out and build an IDE. I have given it some thought, I just haven’t had any time to do anything about it. There have always been too many things that Bxbasic lacked or needed fixing to take time to work on an IDE. I’ve been pre-occupied with developing a viable product to be overly concerned about the other things. Sure, I would like to see a developer’s forum or user’s group, but, I don’t think I’m there yet.
E.K.V: What kind of programs you would like the see programmed with bxBasic, as most?
S.A: I have always enjoyed teaching people. Bxbasic is a product of both learning and teaching. I would like Bxbasic to remain an easy to learn and simple to use, teaching and learning tool. That doesn’t mean it should always remain a subset of QBasic.
I would also like Bxbasic to be able to program games. That means the addition of at least a minimal graphics capability. For beginning programmers, learning to programming even simple, to even more complex games, can be a very useful learning tool.
A beginning programmer may not want to run right out and construct a database or spreadsheet program. At some point, Bxbasic may incorporate more complex programming concepts. But, I don’t want to make it so that the absolute beginner can’t begin learning to program with Bxbasic from the very start.
As a console app, if Bxbasic were ported over to Linux, it should be capable of doing CGI, without too much work. I’m interested in complex math, so I want to be sure Bxbasic has a rich set of math functions. I’ve always wanted Bxbasic to be able to perform scripting, much like JavaScript. The ability to do GUI programming is a corner I will have to turn in the near future.
I’d like to have a couple of fork projects of Bxbasic:
E.K.V: I do remember from some of our ealier conversation, that you have mentioned it should not be hard to port bxBasic for linux. Do i remember correctly?
S.A: From what I’ve been led to believe, that is correct. I use LccWin32 as the project compiler, as opposed to gcc, but, the C code is still C. Unlike BASIC, C generally doesn’t come in different flavors.
Almost all of Bxbasic is Ansi-C. The exceptions to that are the platform specific portions dealing with the Windows console, i.e.: conio.h, windows.h, winuser.h.
I have not attempted to port it myself, due to time constraints, but, someone familiar with porting win32 console programs to Linux should have no problem doing that.
For testing purposes, I have compiled various versions of Bxbasic using Dev-C++ without problem. That compiler uses MingW.
E.K.V: So if someone got interested, do you need a help to do the pure linux port of bxBasic, or possibly even a co-developer?
S.A: Oh, I have no problem with that at all.
As I have mentioned previously, Brian at QDeparment did a port for the Pocket PC and Tom Chandler, also at QDeparment did an Allegro port.
With Tom’s Allegro project, I actually did help him a little bit. My part was mostly in keeping the code straight and answering Bxbasic and C related questions. He did all the hard work.
I couldn’t tell you the first thing about Allegro, other than that it’s a graphics tool kit. It produces some pretty good GUI stuff. What I found interesting about that package is that I didn’t have to compile a new GUI version of Bxbasic. Allegro handled all the GUI stuff internally. Additionally, from what I have read online, Tom has also done a port for the Minix3 operating system. I don’t know anything about Minix3 except what I’ve read online.
In the early stages of Bxbasic, people indicated to me that they wanted to build a Linux fork, but, I’ve never seen any code produced for it. It was always part of the original plan.
So, if someone wants to go ahead and fork a Linux port, they are more than welcome to. It would be nice to maintain some communication between the projects, so that they both have similar characteristics and functionality.
E.K.V: There is time after time talk about how there is too much different basic dialects. Peoples wants to program their own interpreters or compilers, not to code with them. How you generally see the “scene of basic programming” from this point of view?
S.A: Well, if that’s what people are saying, then I guess I have to admit that I’m a part of that problem.
Yes, I will agree that today there are maybe too many options when it comes to programming languages. But, I don’t think that is any reason to stop developing compilers or interpreters.
Supposedly, (as legend has it), in 1899, the head of the US Patent Office recommended that the Patent Office be closed because “everything that could be invented has been invented”. I don’t know if that actually happened or not, but, certainly the statement wasn’t true.
I’m not willing to apply that same philosophy to computer programming. When I started programming, everyone wanted to design a “killer app”. That was the terminology used back then. Over the years there have been some really great killer apps and they just keep coming. New computer technology invites new development and that development is being done with new development tools every day. New hardware requires new tools.
I think, perhaps many programmers want to know how interpreters and compilers work, but, after they satisfy their curiosity, I don’t think they want to stick with it. I think that is why we end up with so many un-finished projects and sub-sets of Basic.
E.K.V: So basicly, it is not up to what you code, as long as you enjoy for coding it?
S.A: For me, programming is a thing of passion.
I love the mental concepts that are involved. It’s a mind thing. Programming can be a great mental challenge, like playing chess or something, (not that I play chess). You have to maintain a lot of variables in your head while you play out many different what-if scenarios.
I love the complexity of it all.
Many people can’t handle computer programming because they aren’t able to do the mental gymnastics required. Programming is like being handed a Rubik’s cube and then being asked to solve it. I think you have to enjoy puzzles to be able to enjoy programming, the way I do. Or, at least it gives you an advantage.
There are times when I am stumped on a problem and have to just put it away for a while until the solution comes to me. Sometimes the solution doesn’t come, but, what does come is a different way of looking at the problem. When that happens, you end up with a completely different set of variables to work with.
I enjoy finding solutions.
E.K.V: Is there something you would like to say readers, basic programmers who are reading this interview?
S.A: Today we have faster computers with greater amounts of accessible memory and many specialized languages with which to test their limits. I don’t think a person should learn only one language and simply stick to it. I think that would greatly limit ones programming skills and versatility. Many programming languages can do almost anything and the newer Basic dialects are certainly among them. Each language and dialect has its own flavor, or way of doing things.
Personally, I love programming in Assembly Language. But, I don’t do most of my programming in assembly language. There are times when a higher level language like Basic, C/C++, Java or any one of the hundreds of other languages are better suited for a given task. You have to find the tools that work best for the task and then narrow it down to a particular dialect or flavor that suits your needs. Sometimes it’s a matter of which platform the program will be running on that decides which tools you will be using.
Despite the fact that there are a number of Basic compilers available, I have found that interpreted Basic is a great proto-typing tool. By that I mean that you can rapidly design and debug a concept and get a working model constructed, that can later be compiled or transport to a different language, if needed.
I think, from the days of the earliest computers, there has never been a “one size fits all” programming tool or language. There’s always been a need to develop newer and better tools. When I look back at some of the early programming languages, I don’t see things of beauty. I think how awful it must have been to be one of those early programmers. They recognized the need for better and more versatile programming tools.
That quest has never ended.
E.K.V: Thanks Steve. This was a pleasure.