Lem: A Common Lisp editor/IDE with high expansibility
github.com
github.com
In the case of others, I’ve observed much less patience. Patience maybe isn’t even the right word; perhaps it’s just an unwillingness to invest in something that doesn’t really communicate an obvious return. Many of my coworkers, especially those who want to edit a little bit of Lisp but don’t want to make it their life story, really wish there was a better editor.
Many of them Python programmers, or even technical folks with a non-programming background, really aren’t sold on this whole Emacs thing to edit a weird language. Out of the box, you have to look up the plethora of cheat sheets and commands and figure out why GUI Emacs doesn’t see your PATH and why changing the font doesn’t stick and ....
They do appreciate the likes of Atom, PyCharm, Jupyter notebooks, etc. with big beautiful GUIs with big beautiful menus and slick websites and “out of the box” support for what they need to do. Pop-up suggestions, dedicated terminal windows, etc. “Obviously” Emacs can do these things, if not better and with more breadth, but it’s all hidden behind The Model of Emacs Thinking (TM).
I really look forward to efforts like Lem improving. I hope they try to do at least one thing really well—editing and interacting with Lisp—and not 100 things poorly (e.g., trying to replace Python editors out of the gate). A great Lisp editor will be such a boon for the language, maybe as important to its rebirth a decade ago as Quicklisp was to it. Lisp is such a wonderful tool, and I want folks to see the great industrial uses it has. Selfishly, I also want to see more contributions to my own Lisp projects on GitHub. To the extent Lem can facilitate that, I’m entirely on board.
(If you’re looking for some cool things to hack on in Lisp, try quilc [0], qvm [1], or maybe even Lem itself!)
An investment in emacs seems to require a 10+ year time horizon, which means betting that it's going to grow and not decline, the numbers seem against that. I think what I really want is atom/light-table to get a lot better but the second died at birth and vscode is going to kill the first whilst having an uglier inner model that is less friendly to extensibility. I really wish Mr Granger had stuck with Light Table instead of running down a blind alley of VC money. There's a great quote that the threat to emacs is the browser, since it's a completely scriptable environment, I guess jupyter/light-table/atom embody that.
I still use spacemacs for running shells and editing files kind of ad-hoc.
I haven’t used VS Code much, but it’s extensions seem pretty rich.
What things can an extension do in Atom that it can’t do in VS Code?
Note that I can't really claim you are wrong. People do seem to be converging on these tools rather heavily. I just can't see how it is capabilities that is driving it. Looks more like standard marketing.
The acs-jupter Org client augments Org's code cells with dynamic completion and inspection provided by the (potentially remote) kernel. The sessions can be managed per-subtree, enabling me to maintain various contexts within one Org file.
It's hard to truly internalise that this isn't necessary in Emacs, that you can actually achieve a level of productivity and proficiency with elisp that the moment something annoys you, you can and should just fix it once and for all. That discipline is hard in any codebase, but it's especially hard with your editor that you don't really think of as just a pile of code that you are personally charged with maintaining.
To an extent much of Unix is like this. In the early days it's exhausting and can be overwhelming - so much stuff seems suboptimal to your workflow and almost infinite customisability feels like a bit of a Fuck You when you just want to get stuff done. But then you realise you've had Linux installed for more than 20 years and there's stuff you could have fixed in your teens and never thought of again. At some point you should really just commit.
Basically just like the surviving commercial Common Lisp IDEs have been doing the last 30 years.
I'd say it's more like the relation with a person. If you have no choice (your boss) you do whatever is needed, mostly. If you have choice but still you're very interested (for some reason) you put up with some quirks. Otherwise, you'll rather be with someone kinder.
I admit that even for Common Lisp, I usually just use VSCode to edit with a separate repl (I always define a function (ll) that reloads the code I am working on so this is not inconvenient). Off topic but I now also mostly use VSCode for Haskell, Python, and Julia. Still love Emacs, just don’t use it as my main driver anymore.
In fact, of course, doing it once is a pipe dream. Everything with vim and emacs 90% works, and you can spend infinite amounts of time chasing the other 10%.
It provides a single user.el file for user-specific configuration, but as it stands it is an excellent "emacs with great defaults".
I still use vim often but since I'm not a vim power user, the vim emulation mode/plugin for any particular editor is generally good enough for me.
I am getting interested in Swift also since the Swift ‘turtles all the way down’ version of TensorFlow is under development and looks good.
Beyond that Lem it is quite fast and there is the OpenGL [1] front as unofficial contribution. It could be embedded as a Lisp IDE inside of a game called Lisp Hacking Experience that was never made.
The amount of good reasons for doing that it can be enumerated by thinking about the common lisp ecosystem as I said earlier.
BTW, emacs is great but it not have good defaults enough for modern Common Lisp development, Lem it's awesome as default for Common Lisp ;). Not having any beginner friendly editor for Common Lisp it was one of the reasons that I teaching Lisp was so difficult.
Edit: Portacle is a good Emacs dist, but it is still emacs, so don't push the discussion with this in mind. It's pointless. And Portacle it's great in your own way (https://portacle.github.io/)
cl-lib.el is not discouraged, it's widely used by Emacs itself and pretty much every substantial Emacs Lisp library out there.
What's discouraged is using an older version, cl.el, at runtime [1] because it replaces existing Emacs Lisp functions and pollutes the namespace. Even that's ok to use at compile time though.
Lastly, cl-lib.el is not cumbersome to use.
[1] https://www.gnu.org/software/emacs/manual/html_node/cl/Organ...
Maybe a few, but not full neither even so many. Thanks for pointing about cl vs cl-lib.
Emacs is good for Lisp development, but both “raw” Emacs itself and most of the packaged customization versions (Spacemacs, etc) are fairly ‘opinionated’ about Lisp, and that opinion usually falls close to: Lisp is great, but Common Lisp is a little/some/much too much, so our choices often lean away from CL’s. (Lisp-1 vs. Lisp-2, dynamic vs. lexical scope, etc.) This means that you’re customizing in a nearby language, but one that dislikes some of the things that you liked when you chose CL, so there’s some impedance mismatch going on. That said, you can get a great CL dev environment from Emacs, but you’ll want to install a bunch of add-ons first, probably including a non-Emacs lisp interpreter and a package to bridge Emacs and that other lisp. True fans of CL would really like a full-blown Emacs with real CL at its core, and periodically people try to make those (Hemlock, etc), but they usually don’t catch on.
Emacs Lisp is a Lisp-2.
Emacs Lisp has lexical scope.
When writing code in Emacs, Emacs Lisp for all intents and purposes can be seen as a subset of Common Lisp, not an entirely different language like you present it to be.
Please try not to propagate this sort of misinformation again in the future. The things you claim are obviously wrong to anyone who has ever used Emacs Lisp, even once. Have you ever done that?
In Common Lisp a subset would mean that all programs of that subset would run unchanged in a full CL implementation. Emacs Lisp isn't like that.
More tragically, over time, Emacs Lisp implemented Common Lisp features - even though Richard Stallman does not like Common Lisp's features like keyword arguments - but not in a source compatible way. Emacs Lisp got CL features and operators via libraries, often with incompatible naming, but still can't be programmed in straight Common Lisp.
There's an additional concern. As Lisp users ourselves, we remember how the CL culture was gutted by the wave of nastiness that rolled into it about 15 years ago. No trace of that is ok on Hacker News. Dismayingly, your comments have contained traces of it in the past as well as in this thread.
In fact, you have posted so many uncivil comments to HN already that we're going to ban you if you keep doing it. If you'd please read https://news.ycombinator.com/newsguidelines.html and take the spirit of this site to heart from now on, we'd greatly appreciate it. This means erring on the side of respecting others, assuming good faith, and providing correct information to teach readers rather than humiliate fellow commenters.
You might also find these links helpful for getting the spirit of this site:
https://news.ycombinator.com/newswelcome.html
https://news.ycombinator.com/hackernews.html
cl-lib is cumbersome to use, especially since the CL operators now have a different prefix (since Emacs Lisp has no packages). This means I can not use any existing CL code in GNU Emacs - the operators are partially there, but all renamed.
That's cumbersome.
I am a long-term Emacs user but I think we really need an optional editor which can be extended in Common Lisp rather than Emacs Lisp. What I really like about Lem is the KISS principle ("Keep it simple, stupid") since Lem is based on curses which is good for portability.
I have no experience with Roswell. Is it possible to use QuickLisp packages? Or do you consider to switch from Roswell to quicklisp? That would make installation of Lem much easier!
FTW you don't need to install Roswell to try Lem, you can use cl-launch instead
--- xx
#!/usr/bin/clisp
(format t "yup")
---
and then on the command line:
> chmod a+x xx ; ./xx
yup
Caveat: You have to comment out the hashbang if you want to (LOAD 'xx) in the repl, or it will puke unceremoniously. It would be nice if repl devs allowed the LOAD function to simply treat it as a ; symbol since it wouldn't break anything and is more consistent with the cli behaviour.
I've only done this with clisp, so maybe other Lisp variants like sbcl et al already do this. YMMV.
EDIT: Realized the script came out all on one line. Fixed.
And take advantage of Common Lisp, no Electron needed.
I just started working as a developer, and so far enjoying using it, despite not having experience with other languages in a professional capacity, or with large projects. The less my hands have to leave the keyboard the happier I am :).
I do use evil-mode, but I should probably get more comfortable with emacs keybindings as time goes on, especially since emacs has some useful keybindings in the context of s-expressions from what I recall.
[1]: https://franz.com/support/documentation/10.1/doc/eli.htm
Bold move, putting heresy right up front.
We should always be experimenting and finding better ways to do things, but not every such project has to start with Rethinking the Modeline and Echo/Input Area. :)
When you use Lisp to make an IDE to edit Lisp. Emacs like software is what you get.
Why do you think Lisp IDEs look like some Emacs? Because you happen to know them and haven't seen the other ones.
Many Lisp IDE's have an Emacs editor, but are not based on Emacs. For example the MIT Lisp Machine has Zmacs, but that's mostly used for editing text (and some functionality around it). Zmacs is also used as a component in a few other programs, like the Mail client. Other than that most Lisp Machine programs are neither based on Zmacs nor have a Zmacs UI. Examples: file browser, font editor, terminal, Lisp repl - none of that feels/looks like Emacs.
Interlisp-D / Medley from Xerox didn't look like Emacs at all.
The Allegro CL IDE doesn't look like Emacs.
LispWorks uses an Emacs written in Common Lisp, but for example does not share the buffer handling (in LispWorks buffers have their own windows all the time and they can't be changed). Additionally much of the LispWorks IDE is not based on an editor paradigm (inspectors, debugger, preference windows, ...).
Since 15 years most (not all) open source CL developers used GNU Emacs + SLIME as the IDE. SLIME replaced older tools for GNU Emacs. There wasn't much competition for SLIME - it also was relatively easy for Lisp programmers to add IDE features to an editor extensible in some Lisp dialect - it's much more difficult and more difficult to make Eclipse or Intellij a decent Lisp IDE, and the results so far are clunky. SLIME OTOH is quite usable as a Lisp IDE.
It would be about time to have a better Lisp IDE than GNU Emacs / SLIME - especially one which is more graphical. But then, we now have the javascript web and GUIs are again different.
As an example to the contrary, both the Allegro CL and DrRacket would be UIs that are not similar Emacs.
A question I'd really like to find the answer to: Why is there so much crapware for CL?. Why doesn't the community come together behind the few, really good, libraries but instead almost everyone goes out and does his own thing, the end result being an ocean of crap.
Corporations and small teams sometimes create software that is more cohesive and might be what you’re looking for, but this has never happened for a “community” of any reasonable size.
One of the biggest things holding Linux behind today is the lack of a common vision. I think it’s no coincidence that Linux on the desktop really took hold only after Canonical started promoting Ubuntu. With Cqnonical retreating into the server space and basically abandoning desktops, I fear we are about to enter another era of Linux desktop stagnation at a time when arguably we need it most (OSX and Windows are increasingly becoming tied down, and the fastest growing OS is ChromeOS which isn’t just tied down but is also potentially a privacy nightmare).
Competition and a common vision don’t need to be mutually exclusive.
look at the context. its easy to understand in todays environment why someone would write a somewhat-finished personal project, put it on github, and try to get it noticed. personal itch, self-teaching, self-marketing, etc
whats less clear is how you get together enough time and bodies to spend the substantial effort to make something well documented, tested, and more broadly useful. especially in a lesser-used language.
open source has definitely 'won', but i dont think that issue has been adequately tackled. the story seems to be that you get to step #1, and get enough traction that you can hopefully build a functioning set of contributors.
[as aside lisp also has a reputation, unfounded or not, for encouraging people to develop a bespoke private universe thats hard for other people to get a handle on]
The came young students who had access to a brand new Lisp Machine in the MIT AI Lab (thanks to the welcoming spirit of Marvin Minsky and others). They implemented EINE (EINE is not Emacs) and ZWEI (ZWEI was EINE initially) and then Zmacs. -> Weinreb and McMahon. Bernard Greenberg wrote an Emacs in Maclisp for Multics. Hemlock was written in Spice Lisp. From then on a bunch of editors were written in Lisp.
Don't let you be discouraged. Learning to write well architectured programs is best done by writing programs.
I applaud those who put their thoughts between nested parentheses and turn them into working code...
> Don't let you be discouraged. > Learning to write well architectured programs is best done by writing programs. > I applaud those who put their thoughts between nested parentheses and turn them into working code...
We should appreciate jobs like lem! They are trying, thinking! And this HN section??? JUST COMPLAINING! What are you doing for helping? WTF.
Lemonodor-fame is but a hack away!
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
I'm pretty sure all of that does not translate in me not telling you anything.
One can get very far with it, but for some the combination of above is enough reason to look for alternatives.
Why we should support this type of software and attitude? There is something wrong with it.
This is the Lisp Curse:
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html#mai...