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!
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.
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].
> 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.
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.
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.
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).
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.
> 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.
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).
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.
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.
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.
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.
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.
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.
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 :)
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)
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.
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 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..
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]
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.
It is said that CL provides a nicer experience to the developer (like, for example, clearer error messages, a more interactive development experience, etc.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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.