E.K.V: Practically only way i know how to start these things, is to ask some stats about You. So Peter, give us some details about you, who, where and what?
Peter van Eerten: For the ‘who’, my name is Peter van Eerten, currently I am 40 years old. Originally I am a philosopher (MA Arts) and did my thesis at Leiden University on Kierkegaard’s existentialism. Currently I work as consultant in the world of telecommunications. In my spare time I read a lot and try to develop my philosophical ideas by studying certain medieval thoughts and by speaking with fellow philosophers. Next to these things I like music very much, especially classical stuff and electronic ambient.
For the ‘where’: I live in Holland, in a city which is called ‘The Hague’. It is famous for a number of things, but especially the historical buildings, some of which go back to the 15th century, I like very much. It is also the place where the greatest of Dutch philosophers lived: Spinoza. His grave still can be found in the centre of the city.
For the ‘what’, it all started with the Commodore VIC-20 which I bought in the 80’s at the age of 15. I was obsessed with programming BASIC and later 6502 Assembly. In my memory the VIC-20 BASIC still was one of the best programming languages ever, and many times I wished such a BASIC exists nowadays! However reading through a VIC-20 manual some time ago taught me that the VIC BASIC was kind of unstructured and also very limited. Because of my jobs in the field of informatics, I knew other programming languages quite well (like C, Pascal, newLisp), and their design was far better. So I realised that re-implementing VIC-20 BASIC would be meaningless if it was meant to be used seriously and professionally. The only BASIC I had used since was ScriptBasic. This is a very good BASIC but has the downside of being interpreted and therefore inevitably slow, with eventually visible source code to read for everybody.
A couple of years ago I attempted to create my own BASIC compiler, using Flex and Bison. But this was harder than expected and the project failed badly. Still I wanted to create my own BASIC, and for performance reasons it had to be a compiler, also having the possibility of hidden source code. The idea to create a converter was born when I realised that expressions in BASIC were the same as expressions in C. And the biggest problem when creating a language always is implementing an expression parser. (Bison and Yacc take care of all that very nicely but have other problems which I could not solve.) So why not pass expressions as-they-are to the C compiler? The only additional thing needed is parsing some BASIC statements and implementing small pieces of C code. Functions could be implemented by using C macros, and these can then be nested too, because the C Preprocessor takes care of all that. This lead to the concept of BaCon, a BASIC converter.
E.K.V: Got to say that your reply reflects some existentialism. Do you think that BASIC programming and philosophy does have any similarities?
Peter van Eerten: This is a difficult question, because ‘philosophy’ can mean multiple things: it can mean ‘metaphysics’, ‘ethics’, ‘anthropology’, ‘aesthetics’, ‘theory of knowledge’, ‘logic’, ‘ontology’ and so on. There are many disciplines which all belong to philosophical thinking. Of course, the discipline of ‘logic’ is closest to programming. In fact, there is a programming language called ‘Prolog’ which is based on the theory of formal predicate logic. To me it is a very interesting approach to programming, though very hard to grasp when one is used to the traditional sequential approach of C, BASIC, Pascal, Java and so on.
But compared to existentialistic ideas, I would say there is really nothing in common. Not even the way of thinking! Programming has a discursive character, it is a step-by-step, one-after-each-other approach in which problems are solved one by one. However, the so-called continental way of philosophical thinking, where existentialism was born, has a more intuitive approach, in which certain ideas and insights try to refer to the individual experience in life. So continental philosophy tries to connect ideas to concrete events which sometimes have a personal character. Here, the ‘proof’ of an idea is not based on deductive step-by-step logic, but it is based on the acknowledgement of the individual experience. It does not try to proof and convince, but it tries to clarify and teach. So it is a complete different way of looking at reality and life.
E.K.V: This would be interesting subject to continue, and perhaps we do so in some other environments, but i got to stick in to the original subject.
After using BaCon for a few weeks, the first difference I noticed between other basic dialects and BaCon, was certain syntaxes BaCon has. For example, ‘=’ is replaced with ‘EQ’ and arrays are DECLARED, not DIMmed. Was these made with a purpose like this or is it up to way how BaCon is programmed originally?
Peter van Eerten: As mentioned, BaCon passes expressions as-they-are to the C compiler. This is the reason why BaCon can be considered a ‘lazy converter’. Now in the language of C, assignments are written using a single equal sign. But for comparison, C uses a double equal sign like ‘==’. The EQ statement plainly is an alias for this double equal sign. (Instead, you may write ‘IS’ as well.) The idea is to create source code with BASIC syntax, which converts to C easily and which also should be readable.
For the arrays, the DIM statement needs additional parsing. For example, if you would say “DIM a[5,2,3]” then the values 5, 2 and 3 need to be isolated based on the comma as separator. Then, the C array would be declared as “long a[5][2][3]“. This process I call ‘mini-parsing’, because it relates to analysing only one line of code. In the first versions of BaCon there was no mini-parsing at all. The declaration of arrays plainly is possible using the traditional syntax like ‘GLOBAL a[5][2][3]‘ and BaCon users got used to that.
In later versions of BaCon mini-parsing was implemented for PRINT, INPUT and WRITELN. For DIM it can be implemented as well, however, a problem arises when BaCon needs to pass expressions to the C compiler. As these are passed as-they-are, no additional parsing is performed. Therefore, a reference to an array like a[1,2] in an expression will go wrong, as this syntax is not understood by the C compiler.
E.K.V: Can you promise that syntax is locked and future releases will support end user codes created with current release of BaCon?
Peter van Eerten: For the 1.x series, yes. At most some C code optimisations and bugfixes can be expected. Or maybe an additional feature. But the syntax will remain as it is!
If there is a need to advance to a 2.x release of BaCon, there may be syntax changes. But currently I am not expecting nor planning such a release.
For the BaCon language extensions however, like the Highlevel Universal GUI, these are under continuous development and their functionnames may change slightly over time, though their implementation should remain as close as the original idea as possible.
E.K.V: Now after you have clarified nicely way how BaCon is programmed and that the syntax is locked, I came curious about the development of 1.x series. Even though syntax is locked, it as an example allows adding for a new keywords and such if current ones are not changed. What we can expect from BaCon…let’s say in a year or even sooner?
Peter van Eerten: The slogan for now will be: BaCon is a converter that just works. I consider reliability as a very high priority. Therefore, most work will relate to stability and C code performance improvements.
Main progress therefore can be expected in the language extensions. I have just released an OpenGL extension and am planning an SDL extension. As explained elsewhere, as long as external libraries as implemented in plain C, BaCon can use them. Also I would like to implement a sound library. At last, improvements should be made in converting an extension itself, because now this conversion is done each time for each program, which takes time.
E.K.V: While others thinks that compiler or a interpreter should include everything necessary in itself, others thinks that support of external libraries is more important. Which way you feel it’s better? Built-in gfx library or support for some known external gfx library? Built-in sound library or support for some popular external library?
Peter van Eerten: Well that is hard to say. From maintenance point of view it is more easy to plugin to an external library. Especially when it is the explicit intention to support various types of platforms, like BaCon does. In such a situation, it is better to use a platform’s authentic library, instead of forcefully porting built-in functions to several types of backends. For example, in Tru64Unix the backend for graphical functions would be Motif, in Solaris Openwin and Linux it would be GTK. It would become a full-time job to maintain all these variations. Furthermore it is more flexible and modular to allow a plug-in structure.
E.K.V: How important you see to make using external libraries with basic dialect such as BaCon easy as possible? If we compare common BASIC way to open up a screen; SCREEN (val) or OPEN WINDOW (val x), (val y), and how to open a x*y size window with GTK, there is huge difference after all. At least from a point of view of a end user who has used to general classic “basic ways”.
Peter van Eerten: That is important, of course. But here you see the difference between platforms and their backends of which we just spoke. In the ‘classic’ BASIC the SCREEN command would initiate a VGA screen with a certain resolution, after which graphical commands could be used to create a drawing. With GTK, or better, with the X environment, things work different, because we are in a graphical environment already. So the logic is different too; first we need to define a Window in which a canvas can be created, and only after that graphical commands can be used to draw. (Next to a canvas some widgets can be added, which in the old Commodore Basic/GWBasic/QBasic for example did not exist.) So it is really hard to maintain a fixed API for multiple platfoms!
E.K.V: At this point, ill throw a question from a member of our website for what he hopes you to response.
- “When you started to create BaCon, did you had some specific type of software in your mind for what Bacon is ment to be as a tool to be created? And if not or so, has it changed while you have created Bacon from it’s first line of code up to this day?”
Peter van Eerten: In fact, yes, I had a specific type of software in mind. Originally aCon was intended to create small tools. In my daily work I have to deal a lot of times with plain ASCII files containing lines and columns of plain text, but for large files scripting simply becomes too slow.
For example, when merging or comparing two or more files with plain text, each with over more than 300.000 lines, AWK and Kornshell need ages to do the job. Especially from this background BaCon emerged, and therefore you’ll see a lot of commands related to files and string manipulation.
Some programs which I myself consider good examples of BaCon code are the M3U creator, the file respacer and the Roman number converter; these can be found on the website.
Nevertheless, BaCon can create large programs too, of which the BaCon version of BaCon itself is a good example. This is a program containing more than 3500 lines of code! So I have tried to create a complete BASIC, which allows large programs, including network and external library support.
E.K.V: If you think end-user contributions, is there some specific program you would love to see created with BaCon?
Peter van Eerten: Phew, no idea, really. The meaning of BaCon should be in the situation where some problem can be solved with a few lines of BaCon code. If somebody tells me his (or her) issue was solved quickly by using BaCon, then the project has reached its goal, whatever program it is!
E.K.V: Now I’ll ask you to get back in time when you started to write BaCon. If you could give yourself at that time some hint’s about the incoming project, what those would be?
Peter van Eerten: As usual it is ‘think before you program’. How many times I have reorganized the code I cannot count. Especially when the runtime error checking had to be implemented. This lead to a large rewrite of the C code snippets generated by BaCon. If I only had thought of the program structure a little bit better, this would not have taken so much time! Furthermore I should advice myself to accept that not everything can be done the way I had in mind. Some issues are simply the consequence of passing expressions to the C compiler.
E.K.V: Did you had “this is the way it got to work” plan when you started, and if so, were you forced to replan something from the end user view point?
Peter van Eerten: Indeed I had such a plan, in fact I was imagining a VIC-20/Commodore C64 BASIC like language, but without line numbers. As mentioned, these BASICs turned out to be not as good as they are in my memory. More and more the project shifted towards a ScriptBasic like syntax. Also the decision to pass expressions as-they-are also leads to changes for the end user, like the EQ construct. And for string comparison, this is done with a function, instead of doing that in the more traditional BASIC way. Similar with the concatenation of strings. But after all, these are only small concessions. The important thing is that BaCon is a tool with a BASIC syntax, which can produce binaries.
E.K.V: You have a great product, nice attitude and some peoples who are highly interested about the product. In generally speaking, what are those things with what BaCon comes more known and popular alternative in those versatile (or complex in someone’s opinion) markets of basic dialects? With this question I don’t mean how to become #1 dialect, but instead how to reach a balanced position where good product and nicely active and productive community meets with a good resources of documents for BaCon?
Peter van Eerten: That is hard to say. Firstly, I guess best is people start using it. They could request changes and adaptations, and they probably stumble into a bug somewhere. But improvements and bugs are only found in daily usage!
Secondly, contributing pieces of code and examples for the website would help too, and a redesign of the current website may also improve attraction.
(One might suggest that a Windows port also would increase the amount of users, but that really is outside the scope of BaCon. I do not own a Windows license and besides, there are many Basic-to-C converters available for the Windows platform already.)
E.K.V: Windows port is a thing which will for sure pop-up every now and then. Peoples wants their code to work in all possible platforms, instead of creating separate code for each of them. Did you study syntax of similar dialects for windows, when you created syntax for BaCon to make it easy as possible to port BaCon program to some windows compiler, such as BCX?
Peter van Eerten: Indeed I have looked around first, but I found that many BASIC dialects resembled the C language so much, that one could also program C as well. Especially the so-called ‘object-oriented’ versions of BASIC (the 3rd generation of BASIC languages) have a syntax which is not BASIC-like. Even their keywords and declarations look like C++ or Java.
Also there are many BASIC versions using a lot of GOTO’s and linenumbers. Their syntax is real BASIC, but they have strong limitations in terms of structural programming. These versions are considered to belong to the first generation of BASIC’s.
Therefore I looked for second generation BASIC’s, and the only good syntax I found was the ScriptBasic syntax. In many ways ScriptBasic and BaCon are similar, but they are not 100% compatible. But it is not difficult to port a BaCon program to the Windows version of Scriptbasic.
E.K.V: Depending from who we are asking, responses to question “What is BASIC” can be widely different. In your opinion, what makes a compiler/interpreter as a BASIC compiler/interpreter?
Peter van Eerten: From structural point of view there is not much difference in sequential programming languages like C, Pascal, script, BASIC, etc. So IMHO it all comes down to syntax, where in one language some things can be done more easily than in the other, and v.v. What makes BASIC to BASIC? Not the possibility of creating a loop, or a choice, or a sequence of commands, but simply the way its statements and functions are written.
Probably someone will disagree by saying that if BASIC and C in the end are the same, then why not all programs are written in BASIC? As mentioned, some things can be done more easily in one language and not in the other. For low-level actions it may be better to use C, but for string manipulations BASIC is far easier! Just try to split a string to an array; the C code is long and complicated, while BASIC only needs one statement.
E.K.V: In generally speaking, how much you follow basic programming scene globally, and what you think where it is heading?
Peter van Eerten: Actually, I don’t follow new developments too much. But what I always do is check if there is a BASIC available for a certain platform I am working on. So over the years I have seen many implementations and several interesting ideas. There are in fact a lot of people with nostalgic feelings about BASIC, implementing a old-fashioned interpreter including linenumbers, GOTO’s and GOSUB’s. On the other side there are people who try to “rescue” the BASIC language by creating an interpreter based on modern programming concepts like object-orientation. These interpreters also use a syntax very close to C++ or Java, sometimes to the extent that it is hard to see a difference!
Generally speaking, programming languages are heading towards a situation where a lot of work is automated and a lot of low-level stuff is hidden. It has the advantage of a rapid code production but it has the downside of large programs and installbases, thereby loosing the feeling for the way how things work on low-level where real optimizations can be achieved. So software and hardware are diverting more and more while at the same time better hardware is needed to cope with the large high-level software implementations.
One wonders when it is all going to collapse 
