Getting Started with Lisp (2019)
smalldata.tech
smalldata.tech
The author misses the third, most classical, and constantly useful option: doing it all yourself. Despite the scary name, there's not all that much to do, and this approach is the most widely supported in the community. The checklist is:
* SBCL/CCL (from your package manager or from official binaries),
* Quicklisp (by downloading it from https://quicklisp.org/),
* Emacs (in any preferred way),
* Slime/Sly (manually, or via `(ql:quickload quicklisp-slime-helper)`, or via using an Emacs distribution, such as Spacemacs with its common-lisp layer, which already contains preconfigured slime/sly).
There, you're good to go.
Using some sort of toolkit which enables interactive and incremental programming (such as Swank/Slynk on the Lisp side and any Slime/Sly client on the editor side) is an ABSOLUTE MUST while doing Lisp. If you're allergic to Emacs and therefore can't use Slime/Sly, use:
* slimv/vlime for vim,
* Alive for VSCode,
* Slyblime for Sublime,
* atom-slime for Atom.
The approach he tried is using as simple as one can. I guess the only thing missing is if you were mac and windows user ...
It provides a good middle ground between configuring Emacs manually by installing SLIME, Paredit, etc. yourself with M-x package-install commands and installing Portacle. It promotes a do-it-yourself approach to setting up Emacs for Common Lisp programming quickly while understanding each step of the set up process and each line of ~/.emacs well.
Get the community editions of either Allegro or LispWorks and taste what the actual experience of Common Lisp development environments used to be like.
Emacs + Slime already has a REPL, compilation and/or loading of select forms or whole files, syntax highlighting, auto-indentation, completions, debugger, inspector, stepping, cross-references, and most of the other fancy things that are usually associated with IDEs. What do Allegro and LispWorks have that Emacs + Slime don't? What are their selling points? What features make them unique?
LispWorks also has an interface builder but only works on Windows I'm afraid. I wouldn't say their IDE offers much over Slime if you are a power user, but I really like their function/class browser over using all the slime-who-* commands and how easy to use their debugger is. What sets it apart is that thanks to CAPI it is trivial to build graphical user interfaces to make your own development experience a bit nicer: for example opening up a filesystem dialog instead of asking the user to retype a string, building a graphical monitor to provide insights on the performance of your Lisp image... You get the picture. It feels very Smalltalk-ish.
The debugging, tracing and profiling facilities were a lot better than what sbcl+slime offered and there were lots of fancy things like prefilling of inline caches for CLOS.
(Not as good as its ancestor, Macintosh Common Lisp, which also had a GUI builder and other cool stuff, but recommending OS9 apps these days is probably pushing it)
Talking about GCC, of course.
EDIT: real -> other
While the OP, by "Lisp", means "Common Lisp" - you're aware that following this old meme of "Clojure is not a real Lisp" only causes interpersonal fires and brings no real benefit, I hope?
If you're interested, search for "is an acceptable Lisp" and/or "is not an acceptable Lisp" and read all the articles, their comment sections, and the Hacker News dumpster fires that ensued. Maybe they would be amusing if only they weren't happening in my language community.
(defun main
()
(format t "Hello world")
)
(defun main ()
(format t "Hello world"))
Why is that? Space efficiency? As an outsider, I find the "wrong" example more readable.
It's like bicycle riding. As a beginner one thinks those supports wheels at the sides of the bicycle are absolutely necessary. One is constantly struggling to keep upright. Once you can ride a bike without them, one asks if they were ever necessary. Then one never thinks consciously about keeping balance.
(defun plus (x y)
(+ x y)
)
(defun plus (x y)
(+ x y))
I would argue that Python is closer to Scheme than Common Lisp is.
Even in Common Lisp, the names typically used are “first” and “rest”, not “car” and “cdr”
Also, it's a style error to use FIRST and REST when one operates on cons cells, because those imply a different meaning - that one operates on lists. Sure, the language doesn't care whether you use CAR or FIRST, but the programmer does - and they might know that you treat a cons cell as a pair unto its own, rather than an element of a linked list.
Almost any language has convenient ways to get the first element of a sequence, and all but the first, even C, this is not unusual at all to lisps.
When was the last time you saw recursion on list[0] and list[1:] in a production Python program, or even a tutorial?
That's because lists are mutable in Python.
Do it on tuples and they retrieve and do not copy.
Of course in C, one can simply do `ptr[0]` or `ptr+1` which also only retrieves.
> When was the last time you saw recursion on list[0] and list[1:] in a production Python program, or even a tutorial?
That is purely a difference of culture, not of what the language facilities, both Scheme and Python allow either style.
Lists are not mutable in Clojure, they are “technically mutable” in R6RS Scheme, but it requires opening up a specific module that many Scheme implementations do not even provide unless compiled with specific flags.
This comment is going to get downvoted heavily here, but it's high time every one accepted the fact that the Lisp family is almost dead and move on.
This has some obvious negative consequences, such as high feedback loop time - in Lisp, the compilation delay is usually imperceptible, especially when compared to running javac or python.
The "it's high time every one accepted X" is a meaningless comment because it presents an opinion as if it were a fact. Therefore, please accept my downvote.
*if such toolkits exist, please point me towards them - I've always wanted to see one in practice.
My development style is highly iterative and I tend toward functional paradigms. I build up a Python program by evaluating lots of small pieces, slowly building those into the structure of my program. I don't write code into a saved file without first evaluating it in a linked REPL session.
Python does not support the same style of connecting to a live process, like Lisp does. Nor does it have the same facilities of redefining components in a running system.
The surface level actions look similar between my Lisp development and my Python development.
not sure what you have in mind, but i use 'elpy' regularly within emacs, and typically test/load functions incrementally into a python repl buffer, or interact with the repl directly
This is enabled by the fact that code in Lisp is also written in the form of lists. Code is data, data becomes code if you write a macro to process the data.
For example, is the following data or code?
(book (author "Jonathan swift") (title "A Modest Proposal"))
It definitely looks like data. But it can be made into code using an appropriate macro.
What probably Lisp trails in is type inference and bleeding edge libraries.
SBCL type inference is actually getting better and better over time, giving you pretty effective gradual typing. Additionally, a Common Lisp implementation called SICL is in the works, with an advanced compiler and type inference engine.
to chime in, it also can be made into 2 systems - one which defines 'book' as an in-memory object which can be inspected, and one which, say, defines a remote database object - your 'language spec' is the syntax, and you can implement multiple implementations, or replace subsystems as you build up the bigger thing - e.g. 'now my hashtables are persisted to disk', etc
and thus because you see no enlightment in learning lisp
> it's high time every one accepted the fact that the Lisp family is almost dead and move on.
Doesn't track for me. I believe there can be value in things that I personally don't perceive value in.
> I see no "enlightment" in learning Lisp
> the Lisp family is almost dead
You're conflating popularity with value, and the two are very different.
Moreover, you're missing the fact that most of the features that were invented in Lisps (like GC, lambdas, first-class functions, and REPLs) are now wildly popular, with every modern language having taken several ideas from Lisp.
Furthermore, you don't seem to understand that a language is not the sum of its parts. Python, Java, C++, and the rest of the languages that have been grafting on Lisp features do not have the unifying design philosophy that Lisp does, which is precisely the "enlightenment" that you don't think exists.
Finally, by the nature of "enlightenment", you can't see or understand it until it hits you. As someone who is stubbornly refusing to learn Lisp, you by definition cannot judge whether or not you might have a galaxy-brain moment if you attempt to learn it. (it's perfectly possible that you'll learn it and have no moments of revelation, but you can't even tell whether or not that will be the case until you try)
There are essentially 2 possibilities:
- you need huge or specialized libs not available elsewhere: Python, Java, etc.
- you need extreme speed, binary size or memory control: C, Rust, etc.
For everything else, lisp will be better.
Watch someone like Notch code in Java; it's possible to achieve it without whatever language feature people think is essential. However, if it's easier to achieve in Lisp, then Lisp will always have value. The enlightenment isn't essential for application development, but it points the gun away from your foot surprisingly often.
The enlightenment comes from the Zen master understanding why those languages are halfway through Lisp, and grow oneself how to improve them to reach parity with the master copy of the universal God language.
> much of the things that made Lisp attractive before are already available in Python, Java, etc. and I see no "enlightment" in learning Lisp.