The Canon Cat was a text-oriented system written in Forth, by the way.
Also, that is really readable, nice Forth. I’ve always liked Forth from a theoretical perspective, and even used it briefly as a primary language back with JForth on the Amiga, but I haven’t touched it in years. Very cool.
If you like readable Forths, come join us psychos on Factor. Depending on your background, you may find it one of the best Forths ever…or think that it completely misses the point. But either way, it’s a really awesome and fun environment.
FYI, the security cert on the Factor web site expired 46 days ago.
(Edit: I see there’s a github issue for this from a few weeks ago.)
Yeah, I know; I don’t have root on the server, so I can’t fix it, but I’ve been trying to get in touch with someone who can for about a week now.
I played around with Factor, and I love the language itself. The semantics and type system are beautiful.
I can’t get past the Smalltalk-like distribution-as-an-image. I need my programming environment to play well with git and grep and sed.
(If Factor does and I’ve been misinformed, feel free to correct me).
You’re not misinformed that Factor uses images, but I think you’re confusing the concept of images with Smalltalk’s particular source code storage mechanism.
Images, in general, are just a language-specific format for precompiled source code. That’s it. They’re directly analogous to .class files, .pyc files, and similar, if you just had a single file per program instead of one per class. (So, maybe a .jar or a Python egg would be a better analogy). This simplifies deployment and doesn’t really impact development. Lots of languages have used image files, including most Lisps, all Smalltalks I know of, and, obviously, Factor. Factor’s images are somewhat unusual in that they contain raw machine code instead of bytecodes (which in turn is why there’s one image per architecture), but they’re run-of-the-mill in any other sense. Our app build system can concatenate the image to the VM, which gives you a static executable in all practical senses—with native-compiled performance to boot.
Images are completely unrelated to how you store your source code. Factor just uses loose files, exactly like every mainstream programming language. So sed, grep, git, and all your normal tools will work just fine. In fact, Emacs and Vim are the two main editors we use, and I’ve begun putting together a Visual Studio Code environment as well.
Smalltalk does two weird things that Factor doesn’t that probably are what you’re remembering. First, unrelated to its use of images, it stores all of its source code in an append-only database, rather than in loose files. That’s what you’ve hit in the past that broke your normal tooling. Second, its images, in addition to storing the compiled version of the source code, also contain a snapshot of the program’s RAM at the time the image was created. This has a side-effect that having all of the source code to a Smalltalk system may be insufficient to represent a Smalltalk program; data that would normally be constants encoded in source, or settings defined by a configuration file, may simply be loose values kept in the image. Neither Factor, nor any modern Lisp I’ve seen, works this way.
You may or may not like Factor, but I’d definitely encourage you to give it another shot, based on your concerns. I think your experience with Smalltalk gave you the wrong impression of how Factor works.
Thank you for that very detailed response. In my world, “images” have always referred to Smalltalk-style snapshots-of-memory. While I love Smalltalk, it got to a point where the impedance mismatch between it and the rest of the world was just too great.
I’ll definitely have to give Factor another look. Thanks again.
For a while there was a lot of buzz around Factor, but that seems to have slowed down. Has the community withered or are people just writing about their work less?
The founder abandoned the project to work full-time on Swift, and one of the other major contributors has been much less active due to family issues, so we’ve definitely slowed. That said, there’s been a lot of really cool stuff going on. There’s a new parser written by erg that is a lot faster and will let us do things like powerful code refactoring and faster compiler passes, there’s been a lot of work on cleaning up and speeding up the VM, and I’ve been working on and off to try to clean up some of our libraries. So, slowed, yes, but still very much active.
Hm, there are two erg, both coders: https://duckduckgo.com/?q=Emden+R.+Gansner (graphviz, standard ML, etc) and https://duckduckgo.com/?q=erg+doug+coleman (factor, swift, etc).
Amiga fans represent! :)
Does anyone know which forth variant this is meant to run on?
According to #2, it runs in the author’s own forth!
Ooh it’s a FORTH 94! Interesting!
The OLPC produced laptop (the XO) had a forth bootloader that had a mini-clone of emacs in it as well. I’m constantly impressed with what those folks accomplished with that hardware.
On a related note: Apparently the last stage of FreeBSD’s boot loader is scriptable in Forth.
lt’s regular old Open Firmware. It’s also incredibly annoying coming from someone who has an XO-1 - it’s a major piece of NIH when they could have used a normal BIOS (for the time) or UEFI, (the hot newness) as trying to boot anything beyond Sugar is very painful.
It’s not regular old Open Firmware (unless OF got patches during the XO-1 development, quite possible!)
And it’s not NiH when you invented the hardware. That forth has native access to the onboard webcam, the wifi, it has read/write access to the NAND… It’s a dream machine for a hobbyist child.
I inherited my aunt’s C64, and look at me now! My son is getting that forth-in-a-box. Unfortunately, my C64 came with a book and the XO-1 does not… :(
I edited the manual that shipped on the XO. Unfortunately not in time for the original G1G1 launch, but was available in subsequent OS updates.
That wasn’t what people wanted. They wanted a rewrite of emacs in a language that was multicore capable! :(
Actually, the emacs-dev crew is very aware of this and are working on ways to make the core multi-threaded. The key difficulty has very little to do with implementation and a LOT to do with testing. There is a positively vast corpus of elisp out there that would all need to be individually validated in a concurrent version of emacs.
Pretty tall order to fill.
I’m sorry to be disrespectful, but this is the most disappointing “Emacs clone” I’ve seen to date. I understand it’s a personal project and only a week old, but at least dial back the expectations and call it “Emacs-like”. If it can’t load (and use) my .emacs file then it’s not a clone.
The whole phenomenon of “cloning” Emacs in different languages makes very little sense to me.
Uh, the standard of “it should be able to read my .emacs” is absurdly high for calling something a clone. Even during the heyday often a .emacs would work on GNU Emacs but not XEmacs or visa-versa and they were both fully-fledged implementations.
To be honest, I’d be surprised if any non-fork of GNU Emacs could ever (correctly) interpret a .emacs initially written for GNU Emacs without significant modification.
I’m fully aware of that, but that’s what it means to “clone” something.
I don’t see the big deal in admitting there’s no intention to support ELisp and calling it Emacs-like. Calling it a “clone” implies a much more impressive level of effort and support for existing Emacs code which most of these projects simply aren’t going to do.
I’m also aware that 30 years ago there were numerous incompatible “Emacs” implementations, but that was a long time ago and nowadays Emacs is synonymous with GNU Emacs (and maybe XEmacs), and everybody who sees “Emacs clone” will be thinking of GNU Emacs.
The word ‘possibly’ tells me that @dwc has a refined definition of ‘clone of emacs’. EDIT: actually the phrase came from larsbrinkhoff, the author of this fmacs… And that guy is also the author of ‘emacs-cl’!
I could be wrong!
For me, ‘an emacs’ is something that binds key-presses to functions, and some of those functions can edit functions… Really that’s it. That basic functionality is what emacs is built on top of. (See ‘temacs’.)
Forth is known to be good at building a lot from a little… :)
The word ‘possibly’
I took this to mean “maybe in the future”
OK so people are mis-using the word “clone” a bit. Probably should be saying “an emacs-LIKE editor written in FORTH.”