Older blog entries for mslicker (starting at number 14)

tk, Actually I have converted thte colorForth sources to GNU assembler. You can find the sources and some other things at my colorForth directory (I should probably make web page for this). Some people have created colorForth's with a resolution of 800x600 and some other modifications to get it working on their system (colorForth index).

Here are some screen shots of the editor (full size). In lower left corner you will see a visual display of the stack, in the right corner the function keys (these change depending on the application). 'full' is the last comand typed, which took the screen shot. Of course, the rest is the source code. The funny red shape in the source code is the cursor.

I'm not sure if you need any built-in skills to do colorForth well. Mainly you have to be willing to do things in very different way than you may have done before. Usually we try to break problems into tiny pieces. The smaller the piece, the easier to optimize. Optimization in colorForth is not as complex as register-based machine code optimization. It's kind of like untangling rope. You try to find the most direct computation, with the least number of stack manipulations. Simple RPN arithmetic expressions are examples of optimized colorForth.

I found my own skill has grown quite a bit, from being a colorForth newbie to gaining a certain level of competence. I'm not yet close to the mastery of Chuck Moore.

17 May 2002 (updated 17 May 2002 at 22:11 UTC) »
tk, To me, Smalltalk is clearly one of the more elegant object-oriented languages I've seen.

However, I dislike object-oriented programming in general.

  • Rarely are objects and the relationships bewteen them meaningful to the problem being solved.
  • The problem can always be solved in a more efficient way using the von Neumann model. The dominant archiecture of computers today.
  • I don't like being limited to a single mode of programming.

As a system, Smalltalk is not very promising. The prominant Squeak system is quite large and not that responsive compared to existing systems. Improvement from the users perspective requires consuming less resources, and a faster response, among other things. It could be that the squeak developers went a little feature crazy. Squeak doesn't seem to have a purpose, other than to show how various things might be coded in Smalltalk. Maybe it is possible to have a much smaller smalltalk with adequate performance, and usable applications.

Impovement though, is very much possible. Just look at the slop that passes as functioning C code these days. Impovements to existing systems can be made in speed, resource consumpion, code size, simplicity, and the user interface. All of these can be improved by orders of magnitude, without coding everything in assembly. However it is required that you start from scratch, in an extremly capable language.

In this reguard, the most promising system to me is the colorForth system. The philosophy of this system is to cast off as much bagage as possible and start fresh. The system is %100 original code by Chuck Moore. Performance is excelent. Although the code is not purely optimized for speed like compiled C. colorForth chooses a much simpler compiler instead. In fact the compiler and the entire core software is under 2k. Extensibility is at the heart of the lanugage, so the large range in semantics required by a modern system can be expresed elegantly in the language.

The reason why colorForth can achieve such improvement, is that it relies purely on human ingenuity. The only limit in how good the code is, is in the programmer writing the code. The reason why the compiler does so little, is that the code is already human optimized.

For software to improve, I believe we must rely primarily on our own creative abilility. Automation of creative tasks makes us the slave to the machine.

5 May 2002 (updated 5 May 2002 at 15:20 UTC) »
davidw, I was at the event too. I think it went pretty well.

I get the feeling though, that Chuck Moore is more a novelty among the Forth community than a respected influential figure.

This is unfortunate since what he is doing is really the main stream of Forth. I don't see anyone pursuring the principles of Forth as vigorously as he has been doing. It hard for me to imagine of all people, Forth enthusiasts being the closed minded ones...

I found the discussion of Forth ML interesting. Actually, I have plans for a colorForth web broswer too. Perhaps there will be some collaboration in the future. Chuck has said on the colorForth mailing list that he will release his networking code at his next website update, this should be interesting. I've been working on a jpeg decoder, so this will hopefully complete another part of the puzzle.

13 Apr 2002 (updated 13 Apr 2002 at 20:21 UTC) »
raph, C is generally a clumsy language. Take a simple function in C, say the power function:
int power (int x, int p) {
    int r = 1;
    while (p--) r *= x;
    return r;
}
In colorForth we would do this (without color):
power 1 swap for over * next nip ;

This example does not tell the whole story however. Where in Forth we can extend the semantics of the language. C is stuck with the same syntax and semantics, which become increasingly clumsy as programs become complex. My example in C is very generous in this reguard. Look some object oriented C to see my point more fully.

Anyway, I'm not trying to bash C, only providing a counter example to the argument that programming in imperative language is necessarily ugly, or unelegant when compared with functional languages.

I do program in functional languages, but only ocationally, when I intend to run the program once or infrequently.

When writing system code or application code, it is really worth the effort to take the time and craft the code.

--- Update

Forgot the case when the power is zero. Modified the code. Note the colorForth code would need a more semantically complex "for next", since "for next" only handles a positive number of iterations.

Forth
zhaoway, bigFORTH is a native code forth. I have not used it.

As yet another lanuage to run on Unix, I agree forth is not very interesting. However if you explore it's ideas a bit more you will see that it is a complete computing philosophy. From machine to human interface. The abstractions in the forth language are not arbritrary, but yeild very practical results, unlike the majority of existing languages. Please visit these sites[www.colorforth.com, www.ultratechnology.com ] for more on the philosophy and ideas of forth.

I've been programming almost exclusively in colorForth, which is both a language and operating system. The code for the system is simply a work of art. I chalange anyone to find a more beautiful system written for the PC. This has caused me to revaluate my own work, and I see that in a less complacent time some of my previous work would be contemptible. I'd like to develop a web browser for the colorForth system, so it can be more readily compared with GNU/Linux. I'm working on bits and pieces when I have time.

TWM
davidl, What is wrong with twm? This is what I use in Debian. I find it the most usable window manager, when properly configured.

zhaoway, It gets even better! Not only are virtual machines unnecessary in free software, free software doesn't need APIs, cross-platform code, multiple languages in the same system, or plugins. These are all proprietary concepts which free software makes obsolete.

I don't know whether people working on GNU are ignorant of this, or if they are consciously aware of their subordinate role to propreitary software. The amount of LGPL code, and other development practices makes me think the latter.

In any case I'd like to provide some examples of pure free software. Software free from the constraints of proprietary software. It turns out this code has the possibility of being quite elegant. There are other benefits too, work on free software is more enjoyable and rewarding, complexity almost disappears, maintenance and development time drop dramatically. I think it will require some good examples to show this, at least for some people. Others might already recognize this.

sej, Yes, a source system is not a silver bullet. However for the reasons I've stated earlier I think it is a much better fit for free software. You mention name spaces. Indeed, a well designed system must have very good names. I found the approach of colorForth to work very well. Essentialy there are two name spaces one for macros and another for definitions. Only one application is run at a time. So it is eqivalent to each application having it's own space. Names are very sort, usually an english word (push pop), letter (e), symbol (! +), or letter/symbol (a!) combination. The result is very consise definitions. Clashes don't really occur since any word can be redefined, and each application effectively has it's own space.

It is true one person's bugs could be anothers features. The bugs I refer to are behaviors the programmer didn't expect when writing the software. I have a feeling is it is theoretically impossible to determine whether a program is bug free computationally. I believe it is related to Goedel's incompleteness theorem, although my mathematic knowledge is not yet high enough to say precisely what is the case. So, my conception of a bug free program is more an intuitive sense, for a programmer to understand precisely the operation of his/her program.

Anyway, it's been good discussing with you. Thanks for oportunity.

9 Oct 2001 (updated 10 Oct 2001 at 00:17 UTC) »
sej, I think you misunderstood my argument. My point of view comes from one who has vigorously persued the reuse path. I've outlined the problems that I've encountered in attempting reuse in a Unix/C system, specifically the GNU project. I don't think you can seperate the reuse problem from the context of the language/environment. My conclusion is that in the future we must pursue source based systems, with languages/environments that encourage reuse. These new systems will not be re-writes of the GNU system, they will be extremely focussed and within relm of a single programmer's understanding and modifing of the system. The source code should be immediately available, and compilation should procede in a uniform manner for all code in the system.

--- Update
sej, Perhaps I misunderstood your original message. First you call for more reuse, then you state you have no problem with multiple overlapping libraries as long as they stand on their own. Well, if they overlap in functionality then person has pretty much ignored reuse? The balance you speak of pretty much exists. There are people, with incredible persistence mind you, who will attempt to understand and extend the work of others. I was once one of these people. I assumed this huge barrier of entry to every project was just a fact of life. And so you must carve out your niche, choose your projects, with no hope of ever understanding the system.

Well, since then, I've been shown that learning curve needed for every project in the system is completly unecessary. In fact a single person can have complete understanding of entire system. This is not to say the learning curve is eliminated. The learning curve is understanding the system. Every thing else builds builds upon this knowledge.

Then you go on to suggest we "educate" students to understand and fix and extend others broken software. A question we should be asking is why is practically everybodies free software ridden with bugs? Is possible to release bug free software? Indeed it is. It is a magnificent thing to see too. When someone has understood the problem thoughly, and has executed the solution flawlessly. The possibility of doing this is only within reach when the total system complexity is of a certain level, because effecively to write bug free software you must understand the system completely. If the system is buggy it is impossible to write bug free software. So, I would prefer educating the students (BTW, I am a student) to look to the future. To see the mistakes we have made (and admit to them!!), and start looking at what ways we can produce better software. I think the problem lies mostly in former, admiting that what we produce is rubish, and starting anew. Not to produce the same system, with the assumtion that somehow our previously attempt flawed. But a radically different new system which critically analyzes the flaws in the previous system and addresses these problems directly. And I maintain, if we are to seriously address the problem of reuse, this system should have one uniform space. Not arbritrary barriers between kernel, library and applicaion.

sej: I think you do point to a major problem with free software, more specifically the GNU project.

Most of this software in and around GNU is written in C. The major problem is that C promotes reuse at the libary level, not the source level. This is not a problem by itself, indeed a reasonable set of libraries can devised and maintained. In systems based on GNU however there often many poorly designed libraries, libraries that duplicate each others functionality, overly generalized libraries, libraries that wrap multiple similar libraries. Rarely do these libraries offer a consistent interface.

Over time, you would think that this bloat would reduce to a very compact set of libaries which contain the core set of functionality. But this is not the case, indeed the greatest freedom of free software is ignored, the ability to modify the source. Why people choose to create new software instead modifing existing is software, I think is not just ego. As dan points out, just trying to build someone else's software today can be daunting. Also within each project are different set of coding conventions, sometimes odd use of language (classes in C?), different platform abstractions, and many other intricacies peculiar to a project. And then there is the sheer size of some projects. Try understanding a project like Mozilla, Linux, or X. The result of this is that factoring code into a consistent highly reusable set of libraries very difficult. The problems with applications are similar.

Another major barrier to reuse is the use of different languages. This division, for example, produced two practically equivalent Unix free software desktops, KDE and Gnome. And even then the division is minor since C functions can be called directly by C++ code. Factoring is still difficult if not impossible between these languages. If the languages are even more different than you can forget reuse altogether.

So I've listed some of the problems that exist. What is the solution? Focus. If the project is a Unix make that the scope of the project. If the project is a desktop, design from the hardware to the user interface. The result may be several operating systems, for different uses. The GNU project lacks this focus, it tries to be everything to everyone, this is the source of much of the bloat.

Beyond this I think better languages are in order, and tighter integration of the language to the system. colorForth address many of the problems I have outlined, and many I didn't even mention. And I think it embodies the spirit of free software better than the GNU project. The system is almost purely represented as source code. Not only does this encourage reuse, understanding of others code, and modification, it also promotes a high degree factoring and tailoring of code.

Oddly our software mirrors many aspects of proprietary software, binary distribution, plugins, many isolated libraries and applications. I think the future of free software should be in source code based systems. This is a more natural paradigm for free software.

maelstorm,raph: If your interested in stack languages check out Chuck Moore's site. He's the inventor of Forth which Joy and Postscript are derived.

He recently released colorForth into the public domain. It's both a language and an operating system. It's an amazing piece of software, both for it's simplicity, and compactness. The entire source code based system is less than 64k! With a tiny a kernal of under 2k! The system includes a complete develement environment (editor, compiler, interpretor), various applications and other bits of source code.

His designs (a combination of hardware and software) are definently ahead of their time. His chips are hardware implementations of the forth language. Forth serves as the assembly language and the high-level language, a perfect one-to-one mapping of language to machine. These designs (being asyncrounous) consume a lot less power and are of higher performance that conventional designs. One such design is 5x5 array of forth computers implemented on a single chip.

I can't help but think how different computers would be if these design principles were taken seriously.

Today's operating systems and machines are thoroughly bloated, with no hope of improvement. Hopefully, with the release of colorForth, people will see a system can be both simple and minimal, and be thoroughly enjoyable to use. Meanwhile I have found myself quite happy in the colorForth nitch.

5 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!