Crush/BRiX: An Experimental Language/OS Pair

An anonymous reader writes: "Brand Huntsman (the creator of the Bochs Front-End, among other obscure things) has been developing an integrated language/operating system for the past few years now. The Operating System is called BRiX, and it uses a language called Crush, which is woven tightly into the core of the OS. On his project web page he has posted the source code to his preliminary compiler, which runs in Linux and outputs optimized assembly from Crush source code. The Crush language itself is heavily influenced by Forth, LISP, and Ada, and provides strong typing and extensive namespace security." Update: 08/19 00:03 GMT by T : Note, the project page URL has been updated, hope it now works for everyone :)

Comments

Re:Project homepage at sourceforge

[Pilferer]

You *know* this is gonna be a slick OS when the webpage has a "brightness adjuster".

Sounds like the same mistakes as lisp...

[Ungrounded Lightning]

The Operating System is called BRiX, and it uses a language called Crush, which is woven tightly into the core of the OS.

And thus is the same class of mistake as were made in lisp, mad, smalltalk, fortran, forth, and a number of others made once more.

Integrating the language and the OS kills portability, robustness, and security. Integrating the development enviornment with the software under development risks breaking the environment as you develop your target application and sucking the whole environment, bugs and all, into the target.

The languages I named had one or both of those problems. Sometimes it was useful, or "elegant". But always it was an albatross around the neck. I don't know if this new pair has the environment/target confusion. But the anonymous poster brags about combining the OS and language. So (if he's not just mischaracterizing an interpreter/P-code compiler) it certainly has that problem.

The key to successful programming is isolation. Single-mindedly chopping the problem into tiny pieces and walling them off from each other, then putting a few tiny holes in their individual prisons to let in and out ONLY the things they need to know and manipulate.

"Modularity". "Data Hiding". "Strong type-checking". "Interface Abstraction". The list of buzzwords is long. But the battle is constant. The number of interactions goes up with the FACTORIAL of the number of pieces interacting, while a programmer can only keep track of about six things at a time. The more connected the compiler, OS, and target program, the bigger the ball of hair a programmer has to unsnarl to get the program working. One of the things that was key to the success of the C language was the isolation of the runtime environment behind the subroutine interface.

Let us hope it's the characterization, and not the implementation, which has the problem.

Buzzwords

[Macrobat]

I agree with what you say, but I have to point out a couple of things about how you said it.

"Modularity". "Data Hiding". "Strong type-checking". "Interface Abstraction". The list of buzzwords is long.

"Buzzwords" has the connotation of empty talk, but the concepts behind these terms are very strong. In fact, you yourself argue for them in the preceding paragraph:

The key to successful programming is isolation. Single-mindedly chopping the problem into tiny pieces and walling them off from each other, then putting a few tiny holes in their individual prisons to let in and out ONLY the things they need to know and manipulate.

You've just succinctly described "modularity", "data hiding," and "interface abstraction." It appears as though you're trying to diss these concepts at the same time you're defending them.