Slashdot Mirror
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 :)
"BRiX, like many other operating systems, provides features such as SMP, preemptive multithreading, virtual memory, a secure multiuser environment and an easy to use graphical interface. How it does this and the end result make it very much unlike any existing operating systems. BRiX is a computing environment and not an operating system. It is a combination of operating system and applications all-in-one. "
Use the SourceForge page instead http://brix-os.sourceforge.net/
Nobox: Only simple products.
Because what kind of loser would want to write software that can run on any operating system? And what idiot end user would want an OS that could run software written in any language?
Platform independence is overrated anyway. Proprietary is the way to go!!!
Oh shit! I forgot to click "Post Anonymously"...
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I'm probably going to get moderated down for this, but I couldn't help but notice the similarities between Crush/BRiX and Microsoft's .NET framework.
Crush doesn't use protected memory to protect applications from each other, but instead relies on the language, Crush, to ensure programmatically that it is impossible for programs to interfere with each other. This is almost exactly the same as a .NET application domain (ASPX or IE would be a single application domain); there isn't any enforced seperation of processes or security features running in an application domain - the CLR instead formally proves that the applications running don't violate the security boundaries it's supposed to conform to.
I'm wondering if this is an idea whose time has come, particularly in the field of low-cost embedded development. Instead of including costly hardware and OS support to provide these features, you use software development tools to create software which renders them unnecessary. Or am I just smoking crack?
"Hardly used" will not fetch you a better price for your brain.
LISP has neither strong typing nor namespaces. Forth doesn't have much of anything, bar stacks. Do we really need an Ada clone?
There you see the basic concepts of Brix and Crush. Symbolics had that in 1984. One of the Symbolics people wrote a post-mortem,"The Lisp Machine: Noble Experiment or Fabulous Failure?", which explains what's wrong with this concept better than I could.
I hate to break this to you, but C is just as tightly woven into Unix, as anyone who has tried to implement a compiler for a higher-level language will tell you.
For example: Suppose your language wants to manage a stack differently than C does. Suppose, for example, you want to perform some optimisation where the stack pointer does not point to the true end of the stack (say, in a leaf call). Under Unix, too bad. You need to maintain a true C stack pointer otherwise signals won't be delivered properly.
Unix is just as much a C virtual machine as the Symbolics devices were Lisp virtual machines.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Yes they could, and they do. But for most definitions of "Operating System" it's incorrect.
;-)
Usually OS is used to refer to the kernel and central libraries. The OS takes care of the low level stuff and adds hooks so you can run programs.
IE is not part of the OS for Win32 any more than eg Windows Media Payer. "Explorer" however is, this is easily witnessed when your file browser crashes and takes the GUI with it.
BTW the system in the article does in fact tightly integrate things. It seems like most of the kernel is in fact in the libraries. Also the language handle a lot of kernel/OS stuff at compile time. (Like memory management.)
Other examples of OS which tightly integrate applications and OS are "exo-kernels". These basically tack a small kernel onto an application and let them run as one. (But it's not as useful for multitasking.)
The HURD is also an example of an OS which makes the distinction between OS and user application less obvious.
Basically, claiming that IE is tightly integrated into Win32 only makes sense if you define OS as "The stuff you get when you buy the box". This is not the definition most by people "In the know".