Ready.
This is the reflections (philosophy) page for FIX, or zFIX, my inter-platform home-fixing
tool.
It lets the matching of a variety of programming-style(s) with a variety of operating
system/hardware platforms. It is
The programming styles/architectures I provide, are my preferences, and fine for my usage. You may also like them, and use as-is. You may also take them as a starting base, and apply your own changes. Or, you may start some all-new style of yours. Your preference.
Bootstrapping compilers and operating sytems, programmatically crafting bitmapped graphics files, executable files, interactively building software, being at the byte/machine level, yet in several layers of insulation, being user-friendly. At the root of it, only jumping around, defining/using pointers (labels), reading/writing, and including files. This is zFIX'ing. You may also read the FIX programming language page, for a programmer's guide and reference manual.
The architecture(s), and the resulting behavior are mainly in the include files (for definitions and settings). You may also think of FIX as a shell that can switch skins/themes to meet a variety of programming styles, and produce output for a variety of operating systems and/or hardware platforms.
The program itself is only a few kilobyte(s). Small is beautiful.
Every FIX line starts with a back-slash. The FIX processor does not process the other lines. This comes handy when preparing mixed-content pages. I liked this line-skipping feature, although probably they did not explicitly preferred it, when programming with DOS's debug program, and writing readable programs with a lot of comments in them. FIX was an improvement on debug, in several ways, including [re-]defining labels, including other files recursively, etc. But I would like to keep that skip-line feature, and the armchairs on the lines, as if in a theatre, became an integral feature.
That looks like something, like an armchair, which leans on the left wall, and looks at the right. The command-letter that is adjacent to it, then, is like someone sitting in it.
In primary school, and early high-school, on the left sides of my notebooks, which had a separator in them, I used to decorate with geometric figures. (Later, I started using checkered notebooks, and white papers.) As a result, I can expect this may not be distracting, and even familiar, for many kids. Just keep in mind that, any line that is worthy of attention for FIX, has that leaning-armchair at its start. If there are two armchairs next to each other, it is for hiding the content after it (like having been reserved, and maybe, later can be opened to interpretation), until another (single) armchair is met on that line.
FIX is meant to be efficient, versatile (in handling programming idioms, among platforms), and working correctly. A comparison may be with the DOS debug program, with which I coded the initial version(s) of FIX. FIX is a bit more user-friendly, in some aspects, and still improving.
FIX also has some superficial similarities with other languages, but I have not yet fully thought/reflected on those resemblences. The C resemblence was the most relevant, when I was writing with debug. I wanted textually-named pointers, and include files, like in C.
The Prolog-like command-sequences were, if I recall right, was a co-incidence that I liked, and wanted to keep and expand on. It is not the same like Prolog, and not meant to be, though. I propose with my own tastes. Yet, when designing style-layers, this may be something to capitalize on, for a Prolog-like emulation.
The distinction between the command-header, and the command-body, superficially sounds like Lisp's, but I could not relate, really. The structure, a bit similar to Lisp, is based on recursive inclusions, but the stream-consumption of the functions may not be like it - as far as I know Lisp. Let me reflect later on this, too.
The existence of backslashes at start of TEX commands is only a co-incidence. And no paranthesis exist in FIX. I have never used TEX, although I had bought the TEX book (i.e volume one), and read it to some extent. First, I had no TEX software, then we all have word processors and HTML, and I do not need the special (mathematical-formulas) capabilities of TEX. (Incidentally, the only usage of that book was in the learning that the latter "x" in TEX was the Greek letter chi, and pronounced as kh, which I use in representing that sound of arabic in ASCII-coded text.)
Some references that I bought, read, and did like the ideas, may also be cited here - although, surprisingly, I did not use any of them either. The books "Structured assembly language" and "Object-oriented assembly language" by Len Dorfman, and a Dr.Dobb's Journal article "Assembly language macros" by Ken Skier (March 1991) tell about adding IF/WHILE/FOR structures into the assembly language code. FIX implementations would, of necessity, differ, because FIX is not assembly language. FIX primitives are jumps, inlines, and file-includes, not (explicitly) parameterized-macros. Hence, although the ideas are there, I have to, but this time because of necessity, again not use what those other books&article had published. (A Dr.Dobbs article by, I guess, Jeff Duntemann, was also among that I liked the idea, but I never used. You judge to what extent FIX Beta-0 resembles it. It was about "Little interpreters/languages" that were essentially inlines (or calls) of non-decision making code-blocks - at the assembly level. And A C User's Journal article had published about "Executable Strings", let's add this to the number, when I recall old publications.)
Sometimes I also sense some resembles of Turing machines, especially when jumping somewhere, re-setting a value-at-a-pointer, and coming back. But, for me, the resemblence and there.
These are the resemblences for the Beta-0 version. The personality-and-socialization codes I suggest for Beta1 or Beta2, may be all-original. They precede my debug-based thinking of FIX. It was another project of mine, and this is the machine-architecture layer, that I thought of integrating with zFIX, along with the other components. These will mostly be based on my names, their meanings, initials, etc. It starts there, and the documentation grows along with the ideas. (Here, the concept of verisimilitude comes to mind, but it is different. Knuth suggests that for correct-coding of programs, so far as I know, as I had read elsewhere. That is also relevant to the TEX project, by Knuth, but I had read that in a Communications of the ACM citing, did not read what he did about it, myself.
My grow-together programming is for (self-)exploratory design of the programming languages/tools, reflecting the nature of the subjects, where the subjects are both the contents of my names, and also the practical needs of programmers. The end result is expected to be a Designer's Craft, with no resemblence elsewhere, so far as I know. All the menus start with my initials, etc. All this may sound confusing, but when you read the documentation, before bed time, you may not need to read another text for your kids. Just read it aloud, and probably they would enjoy the documentation.
And that may be an ultimate mark of the original design. When something not like others, has my own name, carved into its menus, etc. And the program behavior follows those menu entries, better than most, if not all, other choosable menu-item names.
You may read on my publishing strategy. Mainly, I prefer gradual releasing of content, both for user-responsivenes, and also against plagiarism, to be able to differentiate, strategically.
I am the author of FIX. This means, you may vote for or against my proposals, and influence the preferences made over the course of its development. You may read my proposals, and vote, through the proposals and voting page. If you are a FIX user, the voting may be as valuable as the software itself. That may shape the future of such using.
The main justifications for such an argument come from a few observations:
Even the compiler design, software engineering, database and operating systems textbooks are full of bits of ideas that could be implemented in a language tool. Not to mention those ideas in some corner of a lot of research papers, and those already implemented in some (popular) release of a particular language tool.
In other words, even if you are not really an original type, you have so many already-explained options that, a lack of ideas is never likely to be the problem. The only problem may be what to prefer for implementation.
Yes, original ideas may not be needed. But the case is that, I do happen to be an original, too. In other words, I may every now and then come up with some orignal idea that could ease the existing ways of doing things, while still meeting the established criteria.
As a result, I may also keep suggesting new ideas of my own for implementation. By being active in responding, especially if you are a registered user, or otherwise, at least, an identifiable (i.e., not anonymous) person, this will count as a vote for me to include that in the main release, or make it as an installable option.
One of the most expressed criteria for the programming languages is this one: Small is beautiful. We should make the usual assumption explicit, too. It is: Small is beautiful - other things being equal.
The idea of starting small, then developing to meet the user preferences may be a delicious idea. Indeed, the popular Java platform had been launched with that philosophy, at its conception. But later, the inconsistencies among library versions, the existence of newly introduced features, along with deprecations, made it hard to maintain a program. And this was especially a problem for Java because the problem surfaces at run-time, mostly.
On behalf of FIX, let me explicitly state that what counts is what is documented on this page, and its subpages. Nothing else is.
Even if you discover a feature (or a quirk) I may have implemented into FIX, that should not be used in any way, other than sending me a request for me to officialize it. This is because, on my part, I am very ready to drop such undocumented experimental features, possibly in favor of others to replace it.
Such experimental features may also accompany some bata-releases, just as I make the suggestion for some new idea. Then, it is for your personal trial, before you vote, and unless it is sufficiently popular, it may be made into an optional module, or totally discontinued. The documentation, in such cases, should make it clear that it is an evaluation-only feature.
FIX is a glorified binary editor, that may become all or some of a compiler, an operating system, a shell, a database management system, as well as a base for interfacing a varieties of these, and a (RAD) tool for managing projects with all of these. Not at all difficult, indeed. At the end, what it will be, is only on-demand basis - my demand, and that of the other FIX users. The Java and PICmicro support is also intended to be easily installable modules, that let you easily target those platforms, while/after preparing the code in the DOS and/or Windows environments.