The software industry is sick. I can no longer conclude otherwise, nor keep my calm. So here is a rant... it's 'exponential' because writing this will get me madder and madder.
I am a coder of the inside . The flaws I see on the outside make me want to fix things, and I always end up deciding that the lower levels of a design needs a fundamental rework. Software only works if every part works properly. And it can only be implemented from the inside out: you start with lower-level components, get them to work, then build on top, test again, and so on. Unfortunately, that means that changing things on the inside is hard. But it gets worse...
The work I have been involved in (persistence, scripting, packaging), leads to software which could potentially be of use in many contexts. Due to its nature, much of it is OEM-type , i.e. software that gets included in higher-level code, i.e. tools and applications. The trouble is, coding needs to be done in some language. The trend is to write more in high-level languages these days, and optimally in the most productive (and even portable) of all: scripting languages such as Perl, Python, and Tcl.
But that is nearly impossible for me. The logical steps would be:
- pick a scripting language
- build some cool library / module with it
- release it
There's a show stopper in the above: Step 3 is not usable from any language other than the one chosen in step 1!.
What I need, is a way to write in a high-level way, with all the benefits of scripting, yet leading to software that can be used in a wide range of environments (read: languages).
After a couple of years of agonizing about this issue, I'm almost ready to resort to FORTH , i.e. embed a simple Forth interpreter such as pForth and then write all my own stuff in Forth. Much of the work to get there has already been done in the Minotaur project.
But yikes... do I really have to write FORTH code? That does not sound very high level at all. Or even robust (from a development standpoint). Forth is from the 60's, i.e. before concepts such as OO, libraries, frameworks, and even heap-allocation, were available - and I'm afraid it shows.
For now, I've come to the conclusion that I would be best served by something new, which I am calling Thrive (Threaded Interpreter Vector Engine):
- Forth-like engine
- written as C extension for a couple of scripting languages
- a decent form of memory management (refcounted or GC, undecided)
- support for strings and vectors
- a way to link to existing C/C++ code and/or shared libraries
- minimalistic design for the engine, build everything on top
- As a way to keep things simple, I am currently exploring this approach, as well as a few more concepts:
- creating the entire engine as a single "C" source file for trivial distribution
- generating the C code from a Tcl script to automate the coding of what is essentially a VM
It's too bad that this thing does not seem to exist (or maybe I'm just looking for an excuse to build it?). Tcl is way too monolithic. Python imposes an OO model which does not match the way I deal with data. Perl and Ruby are too hard for me to fully grasp and write. Squeak has a good VM design, but is a closed system. Lua might have been an option. But for now, I decided to go for that single C file which can be distributed even by email, and which I hope can be compiled effortlessly on Unix, Windows, and Mac.
� January 2001