Older blog entries for mslicker (starting at number 11)

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.

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.

Why the Bush administration wants war

I recommend this article in regard to the recent events.

I've been looking into display postcript (DPS, DGS)a bit. It looks like it could be the free software equivelent of MacOS X's quartz. Although you would need to modify X to get the full effect. It seems you could still implement the X protocol for compatability, but the window system itself would be a superset of X.

If the various desktops could standardize at the level of a postscript based windowing system, that would probably eliminate a lot of redundency in the toolkits. Also it would allow almost unlimited flexability in implementing different types of user interfaces at a more comfortable level than X.