Not quite. The FSF says it's GPL compatible, but they do not recommend it:
> This is a lax permissive non-copyleft free software license, compatible with the GNU GPL.
> We do not recommend this license. If you want a lax permissive license for a small program, we recommend the X11 license. A larger program usually ought to be copyleft; but if you are set on using a lax permissive license for one, we recommend the Apache 2.0 license since it protects users from patent treachery.
This is funny but it cannot be called an implementation of `ed` because it only implements the tiniest fraction of ed. It doesn't have super basic commands like `a` (to append text), or `,p` (to print all lines), or any range support at all, let alone more advanced stuff like regular expressions.
So it's nowhere close to a POSIX-compliant implementation of ed, and not just for trivial reasons like that it cannot read/write files or execute shell commands.
OS.bf is the project to get operating systems to an effective minimum
of features. It's written entirely in Brainfuck, an industry standard
in minimal, portable, architecture-independent, axiomatic
technology
I've said it here before, brainfuck is the most forward-compatible language. If you want to write programs today that will still run 10, 100, 1000 years from now, brainfuck is the language capable of that guarantee.
And yet, I'm reluctant to call it the language of the future.
There is also https://brainfuck.org/epistle.html, so we're pretty safe about the set of features that Brainfuck needs. At Brainfuck Enterprise Solutions, we're relying on a safe set of features any modern Brainfuck implementation provides, so we're safe and happy.
Yeah, unicode is a whole compatibility nightmare that I refuse to contemplate in the context of this shitpost. Don't quote me on this, but 30k 8-bit cells should be enough for anybody.
Luckily, you don't need Unicode, and we've endorsed the no-Unicode move in Brainfuck Enterprise Solutions. If one needs non-ASCII text, there always are ASCII encodings, like ArmASCII and romaji.
I clicked through to see if github had syntax highlighting for brainfuck, and wether it detected brainfuck in its graph that shows a project's language breakdown. I was not disappointed.
430 lines of overly verbose BF to boot. You could delete 1/3rd to 1/2 of them by simple tricks the author hasn't used for readability reasons.
It's not the worst language if you're willing to work within the constraints and frankly, more readable than a lot of C++. My own editor (written many years ago, no meta interpreter) was 113 characters.
Yes, there's always space for optimization in Brainfuck programs. We haven't used some of the optimization opportunities for readability, as you've said. But we might have missed some optimization spots too, so feel free to open an issue or pull request if you know how to fix that!
Also note that 430 lines is the code compliant with our bd.style: heavily commented, unambiguous, modifyable. You can always minify the code and it'll be some 1K commands, which is pretty small for a text editor.
You can always call it Brainf* or BF—we do that when communicating with outside clients. Works alright, especially after they see how much power it adds to our programs.
I was going to ask how comments work but then I noticed comments are in [] so BF instructions (like , . etc) are not executed because all cells are zero. At least for the initial comments
"Not being Ken Thompson is a struggle every working software engineer has to contend with."
Funny.
Also brainfuck always is intesting, hard for no other reason.
Some people just hate themselves. Really .. that's the only reason for something like this. But props for doing it, you are better hackers (old school variant) than me, bf-enterprise-solutions.
Unfortunately, ChatGPT is too weak of an AI to work with Brainfuck code due to Brainfuck having too high-level of a semantics for an AI to grasp it. So yes, we have dedicated human coders in our company, and they are happy not to use hip AI do replace themselves!
