I've been designing one in my head for the past month, it's become an obsession. I don't know if I'm onto something, or caught a really bad case of the Lisp fever. What's the recommended treating regimen?
I had a friend (Passed away, RIP) who went to MIT and learned how to program on those things. She was really confused when Microsoft went full-in on OOP in the 90s because it flew in the face of everything she learned while there about how to write programs that don't crash.
May as well go all in on that idea and make a name for yourself.
Yeah, that's my plan for the weekend. I'm currently working on a minimal Lisp implementation written in Rust, step 2 is to compile the thing into a free-standing UEFI binary, and give it the ability to execute machine code.
The final goal is something akin to DOS, but the prompt is a Lisp that has access to the entire machine at full privileges and complete control over the hardware. I'm also exploring how to make it possible to rewrite the most core functions from the Lisp environment, so I could, for example, replace a naive "eval" function with native code after boot.
What can you build with the most minimal "operating system" paired the most meta-programmable environment? My dream is to add a simple display, keyboard and have this run on a RISC-V SoC, that simply boots with the prompt:
"> "
(I hate you for making me write this down and adding more fuel to the fire.)
Because I want to follow my vision. There is space for more than one thing in the world. Also, Common Lisp is nice but it's anything but minimal. One of the questions I want to answer is what is the minimum amount of constructs you need to have complete control over your hardware, while able to rewrite the entire kernel at run time. I bet it's not that many.
That said, Mezzano is cool and I should play with it more.
> Because I want to follow my vision. There is space for more than one thing in the world.
That's nice... but I think you're underestimating the amount of work to produce something you actually want to use:
> Yeah, that's my plan for the weekend. I'm currently working on a minimal Lisp implementation written in Rust,
> One of the questions I want to answer is what is the minimum amount of constructs you need to have complete control over your hardware, while able to rewrite the entire kernel at run time. I bet it's not that many.
You should take a look at both PreScheme (part of Scheme48) and Squeak. There's a lot of prior art you can look at without compromising your vision.
I'd also suggest you commit to a (modest) end state you want to achieve. I'm reminded that Linus Torvald's original motivation for Linux was to understand the multitasking hardware in the 80386. His first working development "kernel" ran two fixed tasks that printed something like A's and B's.
So you may be well served by starting with something minimal, but functional and building out as you have time. This also has the advantage that if you run out of steam for the work, you'll still be able to explicitly state you achieved an interesting goal. (As opposed to "Yeah, I started out building a bare metal Lisp, but got bogged down in the interereter and...")
I see your point. But also, reinventing the wheel is just fun. Building things out yourself, you eventually realize why certain design choices were made with the leading implementations as a consequence. I'm convinced the best way to understand something is to try and build one yourself. Even if it sucks.
“Minimum number of constructs you need to have complete control over your hardware” is a bit of a slippery slope when it’s known that one-instruction computers are Turing Complete (“subtract and branch if negative” being one I recall). There’s plenty of mind-bending stuff on esolangs.org
You're right of course, but picking the specific point on the slippery slope you mentioned earlier is why this is an interesting engineering problem (and not a math/logic problem).
At first glance this seems very minimalist in a mathematical/academic sense. For them minimalism is Peano numbers, for a computer guy it's cons and recursion.
But it's worth spending more time with it, so thanks.
Resist! Resist! Your brain is subject to colonization by self-referential idea complexes, but it is has defenses.
We have learned a great deal over decades about how to make languages that enable building reliable, expressive systems. Lisps can draw upon very little of that learning. Types can do heavy lifting, where put to work.
Instead of rebuilding something that was tried in the '70s, learn what they didn't know then, and apply it to something wholly new.
Meh. The fact that software engineers as they get older they are return to older and older technologies has to have a reason... or can simply be explained by declining mental faculties :)
Types are cool, but are way overrated. Correctness isn't the only useful metric to optimise for. They are important if I am running a business and I don't want my crashing software to lose customers, but they are a hindrance if I just want to have fun and break things. Fun and productive businesses have been built on Lisp, BASIC and Python.
Languages aren't continuously getting better. They are on a cycle that repeats every 25 years. We've just entered another strong typing era.
I'm old and this is what is happening to me too. Nostalgia for my childhood computers that plug into TVs is one thing, and I know they sucked in so many ways that I'm happy I have left behind. But the time before my time (the 1970s) had so many interesting ideas that we have all abandoned because a single dominate pattern has become cheap and easy to build upon, but I feel like there's so much to learn by taking those old/abandoned ideas and applying it to modern hardware. That is what I spend my time thinking about and tinkering with.
If you imagine the only or main use for a powerful type system is error-checking, it only demonstrates how much you have still to learn. It is not language design that is on a cycle, but people circling back to what excited them in their youth. But that was not the Lisp, it was youth itself, which you will not find in Lisp.
Types, as I wrote above, can perform heavy lifting in a language that empowers them. New vistas await!
Level 2 senior programmer: types are critical to ensure software runs as intended. You are here.
Level 3 greybeard: who needs typing lol, there is a time and place for them. I am here.
--
This is tongue-in-cheek, not meant to insult you. I get where you are coming from, but you are still giving too much importance to them. The subject matter here is me wanting to have fun, not writing medical software. Can I please have fun by writing a toy language that doesn't have a type system, or does that make me a noob?
I am probably older than you. You literally asked to be discouraged from pursuing this will-o'-th'-lisp. I offered an alternative where you stand to learn something wholly new. I know it is wholly new to you from falsehoods you repeat.
Again: if you imagine types are only or even mainly for correctness, you have much to learn. You can start anytime you like. It will stretch your brain in new ways that are of no relevance to medical software.
> If you imagine the only or main use for a powerful type system is error-checking, it only demonstrates how much you have still to learn. It is not language design that is on a cycle, but people circling back to what excited them in their youth. But that was not the Lisp, it was youth itself, which you will not find in Lisp.
Ironically, this comment reminds me of nothing more than the Smug Lisp Weenies of yore.
I realize that we're all about technical purity over marketing, but I don't think you'll convince people to join your cause by 1) insulting their knowledge and 2) dismissing their interest in an alternative point of view as a way to 'reclaim their youth'. You may be right on both counts - I don't know - but even for someone interested in the technology alone, it's hardly a convincing argument to want to look into more strongly typed languages. (or whatever other technical feature you might want to advocate)
Lisp received decades worth of attention and investment from folks at the frontier of the field, and it's stayed relegated to the margin for almost the entirety of that time. For people that took the time to learn Lisp, it could be a compelling and powerful environment. But the problem has been that to understand the advantages, you have to spend real time and effort to get there. You have to do the reading, do the work, write and evolve software, and accept a different way of working.
The strongly typed functional programming community of today has some of the same sorts of issues and Lisp did back in the day. It's a compelling technology with lots of benefits, but it takes real work to understand and take advantage of. For people that have done the work and already get it, it's an obviously compelling thing - the way things 'should be'. For people that don't, it's an academic ivory tower or worse.
Whatever you believe about your favored technology, it's the way this gap is addressed that will make the difference in whether or not it's successful or not. Lisp never did get it right. (Although Clojure arguably got pretty close.)
I don't mean to specifically offend your sensibilities with respect to your comment, but I can't help but think you're just repeating the same mistake the Lisp folks did. (And no, there isn't a technical distinction between Lisp and whatever that will fix what is fundamentally a marketing and persuasion issue.)
The big annoyance on the elisp front is it makes math slightly more annoying (~80% of my usage of the register).
Trying to evaluate x + y and have vim insert the result is now (+ x y), which is more key-presses. It's a trivial, but slightly annoying in my common case.
Also throwing a bunch of things into an array and indexing into the result, then incrementing a number is more complicated as well (I usually run this in a macro to process a list of things), which is another ~15% of my usage.
There are a lot of things to complain about in vimscript, but infix operators and c-style array indexing has never been at the top of that list.
That being said, in the general case, elisp offers a really nice way to integrate with the editor. Far superior to classic vim-script. It just makes the = register slightly more annoying.
But, asking someone someone to maintain an entire language interpreter just to make the = register more familiar is kinda too much to expect of someone. At least the = register is there, I've never found another vim emulator that even has it.
One trick that makes life easier for lisp is to use something like Karabiner Elements or xcape to turn taps on the shift keys into parentheses. Also, setting up nice keybindings to insert and manipulate parens. Between these two things, I’ve never found lisp any harder to enter than infix languages.
Yeah, it's not the worst thing ever, it's just weird manipulating text in command mode. The standard emacs keybindings do work, but it's not what I've spent the better part of a decade burning into my muscle memory.
Oh well, c'est la vie. Evil + slime/sly is still a better lisp experience than anything else I've tried.
Once you go there, why not put Emacs on bare metal? It'll run that much faster.
You can put in a hypervisor (M-x start-virtual-machine) to run a bloated Linux distro so you can Firefox or Chrome (M-x start-virtual-machine-with-browser), but I'm sure somebody can streamline that even further.
Emacs should separate the command loop from redisplay first. At least with X, another process is managing the display, so I can deal with Emacs crashing or preventing redisplay. If it were the Wayland compositor, I would have to avoid the many Emacs features that perform work in the command loop.
I'd just like to interject for a moment. What you're referring to as Linux,
is in fact, Emacs/Linux, or as I've recently taken to calling it, Emacs plus Linux.
Linux is not an operating system unto itself, but rather another free component
of a fully functioning GNU system made useful by Emacs, comprising a full Lisp system.
I googled for this meme and it turns out it has its own page on gnu.org, "Incorrect Quotation" [1]
And while reading that page I realised that I actually work with GNU, not even GNU/Linux, systems in production every day. Because I'm mostly working on applications deployed in clouds: the kernel is managed, and I'm not sure if AWS even promised that EKS runs on Linux and not something entirely else but very compatible. But GNU userspace is definitely there in my containers.
Emacs running a WM is a disaster. It's also slow as hell. It's hilariously slow.
Suggesting using it as a compositor is sort of like suggesting sawing your own leg off. Makes no sense and is obviously a stupid idea.
FYI i daily drive emacs for everything and have probably written a million lines of code in it through the years, but I'm not gonna pretend it isn't janky as all hell.
Wayland integration is less interesting to me (right now, at least), than the (implied) intriguing possibility of running Pure-GTK Emacs directly on the framebuffer.
I mean, it would work, but debatable how good it would be. The thing with X is that it lets you do more with the video device. Even better if you go the OpenGL way
A long time ago my setup was StumpWM with Emacs with Slime connected to StumpWM's lisp image. The non-trivial part was getting one interface to navigate both buffers and windows using C-x b. It was non-trivial because of the somehow circuitous nature of the arrangement.
At some point I moved to a Mac because I realized that perfecting my window manager setup was just killing my productivity. I hope that one day I'll be able to get back to it – maybe when I retire.
What you use on Mac for window management? Recently switched from Linux Mint Cinnamon, default window management feels like a downgrade, maybe I’m holding it wrong?
It is a downgrade, but it's a conscious trade-off for me. I've been fine with that for the last 14 years. I switched to the Mac to get a mostly adequate environment that I wouldn't be tempted to hack.
The thing I actually care about is navigating between windows by typing something that gets autocompleted. Spotlight or Alfred get me mostly there. In chrome I use Powerswitch to navigate between windows, and there's Cmd K for Slack. Having one interface for those would be grand, but I'm not holding my breath.
> What you use on Mac for window management? Recently switched from Linux Mint Cinnamon, default window management feels like a downgrade, maybe I’m holding it wrong?
You're not holding it wrong, it's just a very primitive desktop environment. No snapping, poor external monitor support, defaults to magically moving desktops in relation to each other, etc.
If you want good window management right out the box, you won't get it from MacOS.
To me the most annoying thing is that when I switch to a window of an application, it moves all other windows of this application to the top as well, covering anything else I had opened, making multitasking a fool’s errand.
I'm going to assume you probably made the right decision for you personally, but why did you choose Mac, rather than something like Linux Mint w/ Cinnamon, or KDE, or especially Gnome? Then you wouldn't have to leave Linux, but you'd have less to worry about configuring. And some objectively less cancerous window management.
EXWM is the natural way to do this, treating X11 windows as Emacs buffers is what it's all about. Or are you trying to get just the buffer switching part without going all the way to EXWM?
Hmm, I can't get an RSS that small even with -nw (to use the client TUI), but leaving that aside, on my box just running GNU Emacs normally I get 88MB RSS, so maybe we just need to update the acronym. ;)
I think it's nuts that the Linux machine I run DaVinci Resolve on today has considerably more RAM than the Windows NT machine I used to use Premiere for editing on 22 years ago had hard disk space.
Back then mine was the "scary" machine in the workshop with its AMD Duron 700 and a whopping 512MB of RAM... and Emacs was just about usable on it!
It seems more nuanced. What does it mean that the command doesn't exist? Every serious Emacs user has their own personal bindings, some of those for their own custom commands. But "M-butterfly" suggests more rare hackery, though seemingly trivial for the hypothetical butterfly hacker: they have a "butterfly" key in their keyboard layout.
> You can type ‘M-x butterfly C-M-c’ to run it. This is a permuted
variation of ‘C-x M-c M-butterfly’ from url ‘https://xkcd.com/378/’.
From the documentation. I don't know why they didn't make it the same, but this is how it is, though maybe because M-butterfly is rather hard to press.
I switched from Vim. In Emacs, I can inline previews of LaTeX formulas in the same buffer as the one that I am editing. This is possible because Emacs has a GUI. Vim cannot do this because it runs in the terminal, and it also doesn’t seem possible to do this in gVim.
Meanwhile Emacs implements Vim’s modal editing through evil mode. So for this use case, Emacs seems to be strictly better than Vim.
The default editor in Emacs is entirely fine, at the very least it isn't a modal editor which is a really outdated paradigm which also doesn't make any sense when most of what you do with a text editor is typing in text.
I used Vim for 5 years, tried various different editors (Atom, Geany, Kate,...), and now for the past 4 years I've been using Emacs. And I'm liking it a lot more than Vim (though that may have something to do with my switching from typing QWERTY to Dvorak).
> at the very least it isn't a modal editor which is a really outdated paradigm which also doesn't make any sense when most of what you do with a text editor is typing in text
Hum... As an emacs user, I'm quite comfortable to disagree here.
When in an editor, you want to both type text and run code. Vi only messes up on the emphasis for both cases (due to the legacy of descending from ed), but even emacs has a "run code" mode.
I've been perfectly happy with vim binds using both dvorak and workman layouts. Sticking with it from the start when you're slowly relearning to type at all makes it feel normal in a week or two at most. The only meaningful change is hjkl since it's positional in qwerty. The other stuff was all over and based on mnemonics like d for delete. If you can get used to C-n, C-p, C-f, and C-b for emacs movement, hjkl shifting around is not at all harder. There's also the fact that in many cases you probably move around with something like e or w or the search rather than smaller hjkl movements.
Modal editing has ergonomic benefits similar to Sticky Keys, I don't see anything dated about it.
I'm not sure I agree writing is done the most either. Moving around is probably pretty high up there. It does depend on the file of course, but for config files or [video] playlist files you probably do more small edits and movements than writing of pure text. Writing email would be the other extreme.
If done right then yes, it will be. EXWM is the best X11 WM after all. Being able to treat X11 windows as Emacs buffers with the same buffer management mechanisms and keybindings is amazing.
EXWM sounds very cool. Thanks for the hint — I never heard about it.
I use swayWM and Emacs (with frames instead of windows) and configured sway to have Emacs-style key bindings. So I mimicked EXWM behavior without knowing about EXWM.
It's definitely worth a try. I used StumpWM for 10 years before switching to EXWM about 5 years ago. One great thing about merging the concepts of Emacs buffers and X11 windows is that there is only one set of keybindings you need to worry about (the Emacs ones).
Exciting and looking forward to the code! C server with an elisp IPC is a good way to go about this, poor man's X11/ICCCM. Sounds like it still has ways to go though. Input handling (mentioned as missing) is a very big part of of what makes EXWM so useful.
Emacs is generally used as a normal program that connects to a Wayland compositor (Wayland speak for window manager). The idea is to instead make Emacs behave as a compositor, essentially connecting directly to Wayland and bypassing other window managers.
