Portacle – A Portable Common Lisp Development Environment | Hacker News Reader

Portacle – A Portable Common Lisp Development Environment

portacle.github.io

254 pointswheresvic188 comments

Portacle is a god send, it basically allows you to directly start development in Common Lisp without having to install separately (and configure):

- SBCL (very fast lisp implementation)

- Quicklisp (lisp package manager)

- ASDF (builder)

- Emacs

- SLIME (Common Lisp mode for Emacs)

- Paredit (allows easier editing of s-expressions)

- and other tools that make CL development a pleasure.

The combination of the tools above are effectively a very powerful Common Lisp IDE.

Do you know if installing Portacle will mess with any existing configurations of those things on Linux? In particular Emacs. I have everything backed up but, since I only plan to play with CL, I don't want the headache if it does.

No, it won't. Portacle is 100% self-contained and does not modify anything outside its home directory.

test in peace, it doesn't interfere with your emacs config or anything else :)

It should not touch anything outside of its own directory. If it does, then that's a bug and needs to be fixed.

So as not to scare people potentially interested in Common Lisp away, you can play around with it using just:

- SBCL (or whatever Common Lisp implementation you can get your hands on)

- a text editor

- (maybe rlwrap)

I started to learn Lisp, and struggled after trying to use:

- Quicklisp (lisp package manager)

- ASDF (builder)

They are very complicated to use and understand.

Then I abandoned Common Lisp...

Then you have Portacle !

Emacs isn't the only editor too: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... Lem is also a ready-to-use editor (ncurses or Electron)(but Emacs+Slime is still the best experience (maybe vim?))

You can follow this guide to get started too: https://lispcookbook.github.io/cl-cookbook/getting-started.h...

And hopefully this Cookbook will help you along the way: https://lispcookbook.github.io/cl-cookbook/

Quicklisp takes a couple commands to install, then it's easy. To install a library: `(ql:quickload :my-lib)`. Thinks of it closer to apt than to pip/npm, so you don't upgrade one lib but a QL distribution.

You don't really have to deal with asdf. It is used to create a project declaration, which can be generated for you (see "getting started", cl-project). ASDF helps in creating executables, it's also explained in the cookbook.

>Quicklisp

Um... basically the only command you need to learn is ql:quickload followed by the name of the system you want to load.

Perhaps you had problems with the concepts of Lisp packages (namespaces)?

> Perhaps you had problems with the concepts of Lisp packages (namespaces)?

Rather unlikely. The namespaces are pretty easy to understand conceptually, and their interface is pretty minimal. Same goes for Quicklisp, very easy to start with, practically one function call needed in most cases.

Now there's ASDF. I know, it's a thing of beauty, but it's not simple to use or to understand.

Well, it's actually that way for good reasons: the problem it solves is complex and hard. The only comparable system I know of is Erlang releases mechanism, which is also a solid tool, but definitely not the simplest one in Erlang repertoire.

Anyway, if someone cites ASDF as a reason for struggling with Common Lisp, I find it very believable.

> > Perhaps you had problems with the concepts of Lisp packages (namespaces)?

> Rather unlikely. The namespaces are pretty easy to understand conceptually, and their interface is pretty minimal.

Packages can definitely give beginners trouble. I don't think it's that uncommon for newcomers to Lisp to have REPL sessions like this:

    CL-USER> (ql:quickload :iterate)
    (:ITERATE)
    CL-USER> (iter (for i below 10) (collect i))
    ;; Error: 3 undefined functions and two undefined variables

Then they find out they need to use the package first:

    CL-USER> (use-package :iterate)
    ;; Error: 3 NAME-CONFLICTs saying that the symbols ITER and friends
    ;; are already accessible

Then they throw their hands in the air about how frustrating Lisp tooling is. For a less obvious example, imagine they had just been using LOOP normally at some point in the past in that REPL session before trying to bring ITERATE in. Once you understand how symbols and packages work, it's easy to see why it works the way it does, but it's also easy to see how a beginner could get totally lost.

Can you expand a little on the difficulties you faced? When I tried quicklisp, the instructions in the homepage were easy to follow to install it, search packages, install them, and load them. I haven't tried making a package, or get it included in the repo. Was that where the difficulty you faced was?

Fine to setup. But I don't understand how to reload a project after closing the REPL. More generally, too many tools to master and understand... And didn't find a simple tutorial to start with the ecosystem.

If you're talking about Quicklisp, to reload it after closing the REPL, you just need to run:

    (load "~/quicklisp/setup.lisp")

and then you'll have the quicklisp functions available. Running:

    (ql:add-to-init-file)

will add something like that to your REPL's init file, so you'll have quicklisp available from the get-go. After that, to load a package like "cl-opengl", whether it's installed or not, you just need to do:

    (ql:quickload "cl-opengl")

This is in the homepage, under a section titled "Loading After Installation"[1].

[1] https://www.quicklisp.org/beta/#loading

Same, except I went to Clojure (and some toy Lisps for fun, like Hy) instead.

> - a text editor

Only if you want to teach people to hate s-expressions and write stuff like:

           )
        )
     )

Writing lisp code is different. Pick a good Common Lisp aware editor.

IMHO: For pedagogical reasons Lisp editors should show parens with a color that makes them transparent and almost hides them into background. Parens are there for the editor to find patterns not people to see and match (except maybe one or two most inner levels). You use proper indentation to see the structure just like you do with Python.

>Only if you want to teach people to hate s-expressions

This must be stressed. It is very important to use a lisp-aware editor. It doesn't have sense to do stuff that a lisp-editor can do automatically, such as auto-indent, and keeping parens balanced all the time.

Also, a good IDE (such as Portacle) gives very good on-the-fly documentation of function parameters/etc, which makes learning CL much faster.

This is why I said WTF when they tried to introduce us to lisp in CS61A... I thought why would anyone want to program in this. Years later and I am now thinking how wrong I was!

A very interesting trend of pre-packaged Emacs distros happening. Spacemacs and doom-emacs are most commonly known for providing general purpose configurations. Portacle looking as a more focused for a specific use case.

I would like to see this applied to other language environments to lower the barrier to entry. Maybe Erlang, Haskell, Racket, Ocaml.

> A very interesting trend of pre-packaged Emacs distros happening. Spacemacs and doom-emacs are most commonly known for providing general purpose configurations. Portacle looking as a mor

Bozhidar Batsov's Prelude[0] is another excellent one. It's got a lot of good pre-selected choices, and almost no bad ones. I can highly recommend it.

[0] https://github.com/bbatsov/prelude

Prelude is extremely good. It's the best way to get up and running with helm, and only the support for langs you care about (thanks to prelude-modules.el).

Well now, this is pretty cool.

A portable Spacemacs built with Portacle would be another great step. AFAIK Portacle is ready to be configured, it just needs to be done.

I don't know what Spacemacs does exactly or how it differs from classic Emacs, so I can't really estimate the amount of work required to get it integrated.

I assume it would be non-trivial, however, just based on the experience I've had with the process so far.

Agreed – a very welcome trend, and still not widely known outside of the Emacs bubble.

I've spent a long time going back and forth between Atom/VSCode (too slow on my machine) and [neo]vim (where language integration/autocomplete/file tree/etc. still feel like bolted-on hacks). The I discovered doom-emacs. It's the best of all three worlds: the speed and power of Emacs, the modal editing agility of Vim, the beautiful UI of Atom (after some configuration).

This is good.

Emacs is best thought of as a special-purpose virtual machine, a little bit like the JVM och Python VM. Maybe this will help people understand that something like Magit is not just a Git integration for Emacs users -- it is a full, standalone end-user Git interface that just happens to be written for the Emacs VM.

I'm not too keen on oackaging the VM with an application for easy deployment, but I do hope it helps people view Emacs modes as not just "an X for Emacs users" but rather "an alternative X that happens to run on Emacs".

Calc is another thing a lot of people could use to great effect but don't because it runs in Emacs.

Haskell for Mac is great if you're on macOS: http://haskellformac.com. Highly recommended.

> A very interesting trend of pre-packaged Emacs distros happening.

Back before Eclipse, it wasn't uncommon for emacs to be bundled into development environments. Xemacs is a famous example of this (being forked by Lucid for their dev tools). My recall is that SunWorkshop used to use emacs as the IDE frontend back in the 90s. Allegro Common Lisp also used to include it.

I think I came across other examples, but currently Google isn't providing enough help to 20 year old memories.

I didn't test the thing (I have my working setup, but wanted to see what this was about), but one suggestion anyways: the screenshot shows a welcome message where it says roughly "Hit C-h h for help". I'd suggest you mention "C-h t" there too, it should be the first communion of every new Emacs user.

I wonder how many people press C-h t, get to the following:

C-f Forward one character

C-n Next line

C-b Back one character

C-p Previous line

...and close Emacs, never to open it again.

The tutorial goes on to say:

When you get used to these keys, they're faster than their more familiar equivalents in other applications (Home, End, Ctrl+Left, etc.) because you don't have to move your hands from the touch typing position.

That's such ridiculous micro- and premature optimization - especially given that, since Emacs predates modern conventions, almost nothing is natively familiar - that it boggles the mind.

Emacs keybindings are a standard of their own: they generally work in the shell and other readline based command line utilities. They also work in Cocoa text entry widgets on the Mac.

Those are the keys a usual Emacs users uses maybe hundreds of times in a day. Every laptop I have owned has its arrow keys and Home-PgUp-PgDown-End block in a rather unique place, so even if it's a minor optimisation (it's not), accumulatively it's a very important one. It'd be like replacing a heap allocation with a stack one in a hot function, if that example works like I think it does.

>so even if it's a minor optimisation (it's not)

Has it been measured?

I mean, if they have actually measured:

1) the speed difference of using those shortcuts vs arrow/page-up and co when merely typing

2) the same speed difference as a percentage of the overall programming process

3) the impact of such speed difference in programmer productivity (speed translated to results faster or better code with fewer bugs).

Or it's just cargo cult?

I don't know how can I go about measuring this (tho should not be that hard to come up with a scheme), but I'd rather not bother. One fact is that, on the keyboard I'm looking at, which is a laptop keyboard with a numpad, the home-end bunch are above the numpad, and the up arrow aligns with the enter key, the right arrow becoming a part of the numpad block, right under one. I have to move my hands to be able to use them. I can use the arrow keys with my right pinky, but that requires contorting the hand. Moving my hand either to the home-end row or to the arrow keys takes about a second, and if I'm not looking at them, I usually hit the wrong key, (usually PrtSc instead of home, so also some surprise there), whereas C/M-{FBNPAEfbnpae} are about always right under my hand. I write both prose and code in Emacs, each and every day, and I haven't counted, but I use those keys quite a bit when typing stuff in. Assuming I use them a hundred times a day (quite low of an estimate), I save about 200 seconds/day. Yes that's marginal, in numbers, but in effect, it makes it so that typing is way less burdensome. Not having to relocate the home row enables me to type more accurately without having to see where I am on the keyboard, and to delete mistaken characters when I haven't correctly located F and J under my indices, and I count that a gain, adding to that the many other keybindings in Emacs that use the FBNP keys in some ways.

> Or it's just cargo cult?

Yes, it is. Like much of the rest of programming.

I think it's weird for an IDE to tell me which command keys to use. It should have a set of default keys, and ideally those could be remapped as well.

The biggest benefit of directional keys (up, down, home, end, etc...) is that they are universal across keyboards and languages. Control-F may be great if you're on a VT100 terminal, but maybe I'm on an AZERTY keyboard, or one of those funky square keyboards. Or a Chinese keyboard that's largely input by writing characters on a little pad. Or on a Mac using gestures or Ink. Or a dozen other possibilities.

If I was only programming in Pascal and only on one computer in one environment for the rest of my life, then it would make sense to learn those keystrokes. But like is more complicated than when those were first coded.

> It should have a set of default keys, and ideally those could be remapped as well.

It sounds like you may not be aware that this describes emacs?

And yet I spend a summer immersed in Emacs and the thing I miss most is the navigation commands and incremental search.

It's not premature in my opinion.

vi, too, uses touch-typing home-key navigation. I don't know if I'd trust a developer who claims that both emacs & vi are wrong.

Well I can tell you from experience that it's not a micro-optimization, unless you compare it to vi(m) where the movement keybindings are optimized to h, j, k, and l. Being that movement across the text you're editing is such a common action, it's become incredibly annoying when you have to move your hand away from the home row and search around for the arrow keys with your hand. Different keyboards have them in different places and sizes, so you have to make a slight pause to think of what keyboard you're using to know where to search. I've caught myself having to look at the keyboard sometimes just to find those damn arrow keys. In fact, sometimes they're so badly positioned in the keyboard, that I just prefer to use the mouse instead.

Nothing stops you from using the other keys (cursor, home/end, pg up/dn): they're all bound by default to do those actions too. Personally, I gladly use the shortcuts that don't make me move a hand to the far edges of my keyboards. (one of my keyboards doesn't even have cursor keys, and I get along fine)

What part of "when you get used to these keys" do you not understand? Keeping your hands on the home row is absolutely quicker than using those other keys. So much so that my main keyboard doesn't even have those other keys because I don't need them any more.

The beauty of Emacs lies in how configurable it is. I use Emacs in two modes, when editing a program I use native key bindings (Cntrl-c, Cntrl-v, Cntrl-a, Cntrl-z etc.) and to execute commands I use vim key bindings. I absolutely love this setup but many people here might absolutely hate it, but what matters is that Emacs doesn't care and can be used by people with diverse muscle memories :)

The help buffer includes its own tutorial that is geared towards the essential parts of Emacs and Lisp editing. I feel like Emacs' own tutorial only distracts from what this package was meant to be focused on.

How is Common Lisp for SPA development? I tried to look for anything on either Racket or CL side and pretty much a dead wasteland on that front.

I've used re-frame ClojureScript for a few years now but would like to dip my toes in CL, just can't seem to get a head start. Maybe trying CL on the backend first, but even there Clojure dominates..

There's not much there for SPA development, perhaps because Lispers generally aren't in that field.

That being said, there is Parenscript, which is a Common Lisp subset that compiles server-side to javascript (so it can be used client-side for SPAs, etc). It is an evolved project so it works just fine.

There's a lib for doing React dev using Parenscript, as well.

Besides that, there is JSCL which is an attempt to bring a full CL implementation on javascript. This is very interesting, however it isn't suited for a SPA.

And of course there are a lot of CL libraries for html generation, JSON parsing, web servers, etc.

>Maybe trying CL on the backend first

I'd say CL is just perfect for the backend side, everything you need should be there.

I wouldn’t say that. Clojure has been adopting React as soon as it came out and brought great contributions like Code hot reloading. Something that still has no parallel in JS. Yes, I know about module hot loading with various JS frameworks, but most loose state on reloading.

Well, not saying Clojure is better. Just saying that Lispers totally are on the SpA bandwagon. For example the CircleCI frontend is written in ClojureScript.

Yes, you are correct. It's just that I considered "Lisp"="Common Lisp" in this case.

The Potato open source chat platform has a Common Lisp backend and a Clojurescript frontend. There is a fascinating talk by one of the authors on Youtube [0], and the code is on github [1].

A relatively new Web Application Environment called Radiance may also be worth looking at.[2]

[0] https://www.youtube.com/watch?v=bl8jQ2wRh6k [1] https://github.com/cicakhq/potato [2] https://shirakumo.github.io/radiance/

Why not Clojure on the backend as well?

>Why not Clojure on the backend as well?

It is said that CL provides a nicer experience to the developer (like, for example, clearer error messages, a more interactive development experience, etc.)

Because I believe that Common Lisp is a better language than Clojure. I'd be happy to discuss specifically what I believe the most important differences are in case you're curious.

Clojurescript was chosen on the client side because its integration with Om was very nice and matched the idea of immutability in Clojure.

Now that Om is no longer well supported we have a problem. The client side needs to be rewritten, but none of us have the time to do so. We'll see what happens with the project.

This highlights another benefit of Common Lisp. It's very mature and I don't have to worry about the fameworks that I use becoming obsolete after a short period of time.

There's a fantastic update of the Weblocks framework going on: https://github.com/40ants/weblocks/blob/reblocks/docs/source... it's more or less like React, components based, but server-based. We don't write any JS, the framework does jsonp calls and updates the UI.

I tried it, it works fine, but still very alpha and moving. However, thinking about the possibility to write a SPA all in Lisp (no JS!), and then with easy deployments, executables, easy inclusion with Electron (Ceramic) is extremely exciting.

Great to see Weblocks getting some love! I wrote an app in it several years ago, and was helping maintain it for a while, but haven't had any need for it since.

Are you aware of my fork [0]? You're certainly welcome to take anything from there that you like. I think the most recent work was on the 'bootstrap' branch. I recall that I was going a little bit in a different direction from what the other maintainer wanted to do, but I no longer recall the details.

[0] https://github.com/slburson/weblocks

Commercial Common Lisps like LispWorks and Allegro have relatively good native GUI support.

It's like Visual Studio install for Lisp. I like that the idea of single sane default configuration is promoted over infinite configurability.

This is great! I'm a Clojure guy who had given up on CL before. Will take it out for a spin for sure!

Check out Nightcoders[0] for a similar IDE for Clojure.

[0] http://nightcoders.net

I remember a few similar things, forgot the names, lispbox or something like that. They were very nicely packaged but were not maintained so I'm happy to see new activity in this domain.

Looks like the project could do with some help making self-contained Linux and OSX packages. Is there a good multi-distro way to do that yet? Ideally one that allows self-modification.

AppImage is a Linux way of deploying this, but it does not allow modification of the resulting binary. You could perhaps try to do it with snapd instead.

Given that packaging things in a self-contained manner is pretty much all this project does, I'm a bit confused about your comment. Could you elaborate?

Sure. If you look at the main page they go to trouble to explain that you can't separate the executable from its special folder on any of the three platforms. Especially on Mac that's unusual.

That's on purpose, and required, for a variety of reasons.

First would be that it cannot be put together into a single executable as it is composed of multiple, separate components, that each rely on a specific structure of the file system being present. This is not something I can control.

Second, Portacle is made in such a way that all three platforms can be combined together into a single directory so that it can be run on any system as one, which mandates a shared folder structure.

Third, in order to be self-contained, the Portacle installation directory must contain its own configuration and project directories. It makes no sense to allow you to move the executable outside of this, and it would make no sense to put those directories within the .app on, say, mac.

It needs EVIL for us vim users.

>It needs EVIL for us vim users.

I guess on the future we could have VPortacle, which would be VIM + SLIMV (Superior Lisp Interaction Mode for Vim, the Vim counterpart to SLIME).

Nah, lisp development tools are much better on emacs and EVIL is a very good vim clone.

You should be able to easily install it by putting `(ensure-installed 'evil)` (and evil setup parts) into the user config file, or using Emacs' package-list, which is explained in the help buffer.

Is there anything like this for clojure, with all its tooling rolled into a self contained package? What about for clojurescript?

Clojure For the Brave and True includes an excellent clojure setup for emacs[0]

[0] https://www.braveclojure.com/basic-emacs/

It's a nice tutorial but not a download-and-run app like Portacle is.

And it messes up with our config:

> Delete ~/.emacs or ~/.emacs.d if they exist.

Every time I've tried to follow the setup tutorial in that book I've not been able to get something basic to work, like the REPL or the flycheck parser. It's prevented me from really diving in to be honest.

Probably give Emacs Live (https://overtone.github.io/emacs-live/) or Spacemacs (http://spacemacs.org/) with the Clojure layer installed a try. Learning Emacs and Clojure both at the same time can be kinda overwhelming though and if you are just interested in Clojure and not Emacs you should probably just start with Cursive (https://cursive-ide.com/)

I'll try one of those -- might be good to have something separate. I use Emacs as my main editor and there's already a lot added onto it. Thanks for the links.

Yup, Lightmod (https://sekao.net/lightmod/) works for both Clojure and Clojurescript.

This is nice, thanks for providing it. Is there any intent to allow for Sly to be used instead of Slime (as an option, I mean)?

If you open up an issue we could look into what's required. From what I can tell it shouldn't need much work, just an additional file that configures defaults similar to https://github.com/portacle/emacsd/blob/master/portacle-slim..., and a way to defer the loading of either one until after the user file has had a chance to make its customisations.

Can't wait to get home and try this. Now if we can get this to run in Javascript using WebAssebly that would be a dream come true.

Making WebAssembly better for Rust(Common Lisp) https://news.ycombinator.com/item?id=16585315

Nicely done just by looking at the site. I'll have to check it out later.

Just downloaded this a few days ago and it's really cool.

Would love to see this all in one for Clojure (incl. self contained standalone emacs)

Nice. Is there something similar for python?

I've used a "Portable Python" distribution, that bundled CPython with PyCharm and PIP.

Not emacs but Anaconda is a python distribution with an editor (spyder), a package manager (conda), ... out of the box

https://www.anaconda.com/distribution/

Really slick. Kudos.

supercool stuff

At first I thought: "I bet this isn't as good as SLIME." Then I thought: "I should really be more open-minded." Then I looked and thought: "Oh."

Portacle is a standalone bundle of Emacs + SLIME + SBCL + Quicklisp + Git that is meant to be completely self-contained and therefore maximally portable.

Kinda like the old "lisp in a box" package I remember from a few years ago? It was also SBCL and Emacs and Slime all bundled together as a single "program."

Yes. Portacle is a direct replacement for Lisp-in-a-box and Lispstick. Both are heavily unmaintained and outdated by now where Portacle is under active maintenance.

Lispstick was semi-maintained by me until portacle came out. Any further efforts I make will be to improve portacle.

Reply on news.ycombinator.com