From just reading the TOC, and the first bit, this looks great. Like the author, I have been into Common Lisp “forever.” I do sometimes feel conflicted when I can get something done in Python much faster because I can find a library that solves the problem I am working on. Probably my most honest advice to people is that Common Lisp is very good for research programming, but for many use cases other programming languages are better.
This is why I’ve found myself doing Clojure for everything. Clojure has its own pretty-ok ecosystem, but also benefits from the Java ecosystem, while still giving me some lispey goodness.
Granted, sometimes the mixing of paradigms can kind of clash, and that’s its own can of worms, but at least I never get that “ugh I could have done this with a library in <language X>”
When I reference Java from Clojure, I usually wind up with a thin layer of wrappers around the part of the library I need to make the main codebase feel more properly Lispy. It isn't perfect with the different mental models between the languages, but it helps.
Yeah, and I think wrapper functions are fine and normal.
The part that I do find annoying is when I have to break out macros to make my wrapper usable. When I was using the Java bindings for Apache Spark a few years ago, I felt like I was constantly reaching for macros to do some clever stuff, which is no fun.
Yeah I haven't found any project I've wanted to implement in CL. I usually end up using Python or Go at that level of abstraction. If I want lower-level, C or Rust. However, I interact with Lisp almost daily through Emacs. And I enjoy it quite a bit. Configuring my editor through Lisp is unusually satisfying, and feels sleek.
Take a look at the CL libraries PY4CL, PY4CL2, and CL4PY. I use the first one for some things. It can be useful to bridge over to Python for something and come back with the answer.
> ...because I can find a library that solves the problem I am working on.
I couldn't find it, but is there a "Rosetta Stone" of language ecosystems, where in a "libraries" section it lists Python/Go/Rust/Ruby/Perl/Lisp/etc. library near-equivalents?
I used LISP and APL professionally for, in the aggregate, over ten years. My current opinion on these languages is that software engineers would benefit greatly from learning and understanding them, yet it would be a mistake to use them for any modern work.
When I say "learning" I mean in-depth application over, perhaps, a year, not something superficial. The question is how. I don't really have an answer for that. You have to find reasonably complex projects to be able to spend that much time with a language. That's the problem. I was getting paid to use these languages back then. Who wants to do non-trivial work in these languages today. Not many.
That is interesting. I am wondering though, in what areas does Lisp get used these days?
What would be a good project to showcase the strengths of Lisp, versus other well-known languages?
How/why do people end up learning Lisp, what is the usual route to entry?
Genuine questions, not trying to start a language battle here. I've never used Lisp before so am curious about all of this. To me it feels like one of those exotic old-school languages like Erlang or Perl.
>> How/why do people end up learning Lisp, what is the usual route to entry?
I started learning CL starting around July/Aug 2022. How I got here is close to 2 years ago I read a blog post (I think) that said learning a niche language can help land a high paying part-time job, or, if applying to a position where said niche language is used you don't have to jump through all the Leet code, typical interview circus. Just knowing the language and having an interest was a huge factor in getting hired. It seemed fairly plausible to me.
Initially I started learning Clojure but kept reading stuff about how awesome CL was/is. The JVM kind of turned me off and I like compiled, stand alone applications which can be had in CL.
So here I am really enjoying learning CL. I am in a job/organization that does not use CL and probably never will. The benefits are awesome so I have no plans on leaving anytime soon. Maybe one day I may try to land a part time job using CL but I'm no where ready for that (both in my lack of CL knowledge and lack of time to commit to a part time job).
Regarding what lisp is used for, to quote Kent Pitman:
But please don't assume this is an exhaustive list, and please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and Ecommerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. Common Lisp really is a general language capable of a lot more than these few incidental application areas, even if this web page doesn't totally bring that out.
We use Clojure for large data processing where it shines. It's also good at doing concurrency with it's solid concurrency tools and immutability by default. So a lot of people use it for financial data, fraud, and big data stuff. I think it's less common, but using Re-frame both in a front-end web app and also in a React Native mobile app was a charm. Some of the environments were a little hard to get going but were a dream to poke around and add lots of features quick. For example, the whole Urban Dictionary native app for iOS and Android are in Clojure as well as most of the site.
So I've been using Scheme for a couple of years now and really enjoying proper interactive development (why would I recompile my entire program to run the tests when I can just run the tests whenever I feel like?) and I was fairly happy with it, though I'm always very aware that using less power/time efficient languages is harmful to the environment. So I decided to give Common Lisp a try after repeatedly hearing that it's faster than Scheme and I wound up falling in love with its support for type checking (well, with SBCL's support for type checking).
Now I have my interactive programming with the nicety of having SBCL warn me when I'm passing an integer to a function that expects a string or something like that. Not only does it help me make fewer mistakes while programming, the type declarations also help SBCL generate more efficient code. It's a win-win all around.
I'm also very curious for hear from expert lispers. I've tried to find the sweat spot where lisp would fit better than what I already know: shell for glue and file ops, R for data munging and vis, python to not reinvent things, perl/core-utils for one liners. But before I can find the niche, I get turned off by the amount of ceremony -- or maybe just how different the state and edit/evaluate loop is.
I'm holding onto some things that make common lisp look exciting and useful (static typing[0], APL DSL[1], speed [2,3,4]) and really want to get familiar with structural editing [5]
> I am wondering though, in what areas does Lisp get used these days?
If you consider Clojure a Lisp then I think before the tech stocks crashed there were seven unicorns built with Clojure. Banking, healthcare, analytics, ...
I'd say Clojure can be used anywhere Java can for sure. And Clojure runs on top of ClojureScript too.
Then Clojure is only one of the Lisp dialects and there are "lispier lisps" out there which also their success stories.
If you count Clojure and ClojureScript as kind of Lisp then for instance our whole product (https://orgpad.com) backend and frontend is written in it. Of course there is also some SQL, CSS etc. in between but basically all the meat is in CLJ or CLJS.
LISP was the introductory computer class language at MIT for nearly 40 years. The faculty felt it exhibited the important elements of programming and algorithms. Some students complained they wanted something more practical for getting a job. It appears the newer faculty replaced it with Python.
I dunno if it is MIT but I saw a SICP Javascript edition listed recently. That felt... weird. I watched at least some of the old SICP videos on youtube which are still mind blowing and worth a look. It does list Sussman and Abelson as authors on the amazon page...
The MIT SICP course is pretty amazing. Would be a shame if they replaced it with Python. I use Python every day, but it's far more complicated to use it to demonstrate various properties of programming languages due to its great complexity.
wow, do you understand it can't run on windows? so guess you require student who bought windows computer give up programming? last time, I installed Racket and get sicp module. guess people really need move to JavaScript. at least, they don't need to spend time on this.
My understanding is that the authors of SICP themselves wanted to update the curriculum - not just a language change, but to cover something at a higher level of abstraction.
That's not quite accurate. Sussman says that the more fundamental computer science that he and Abelson had taught up to 1997 or so had become obsolete, because the transistors had disappeared into massive chips and the code had disappeared into libraries. Software and hardware became a matter of integration.
He told the MIT people in charge of developing courses that he and Abelson were quitting, and they should figure out what to do next. The world had moved on to interfacing complex chips to sensors and actuators, and it wasn't easy, because the chips were imperfectly specified. To a certain degree, you tried different things to see what worked. I think he was rather disgusted with the situation, compared to the clarity he had a couple of decades earlier using Scheme.
So, the MIT professors that replaced him went with Python. It had great libraries, and it was amenable to fast turn-around when gluing software and hardware together in the lab.
I had a discussion with Sussman a decade or so ago about this, and what he told me then agrees with what he says in the video.
I did early Lisp development on Symbolics Lisp Machines back in the day. Wrote 3D graphics on them. I didn't realize how special the development environment was until I got my first job, writing 3D graphics in Fortran on VAX/VMS. Spent the rest of my career (Fortran, C, C++, IRIX, Linux) bemoaning all the stuff I missed from my Lisp days.
I did venture back into Common Lisp development (MCL/CCL on MacOS) for my personal projects. Even did my masters thesis in CL by writing a socket connection to Maya and using it as a graphics engine from CCL.
It took me a long time (decades) to get over the "everyone should be using CL" mentality.
Thinking back on things, I have come to realize that Lisp is not a magic bullet: it won't necessarily make you a better programmer, and it won't necessarily make your project more successful.
What Lisp will do is give your developers more power at their fingertips. For better or worse.
The philosophy behind Lisp (and Smalltalk) back in the 70's and 80's was that programmers should be given as much expressive power as possible so they can develop better, faster, etc. The reason why CL allows you to define macros, redefine classes and methods on the fly, use generic functions and multiple inheritance, and recover from errors, is simply that the language designers considered these import enough to do the hard work to make them happen.
I feel that philosophy, backed by the economics of software development, fell out of favor over time. Performance, safety (preventing developers from shooting themselves in the foot), code maintenance by large teams, cost, etc became more important.
Today, the main factors in language choice are (1) the availability of developers, and (2) the availability of libraries/tooling. Going against these currents requires awareness and a strong commitment. To paraphrase an old computer industry saying: no one got fired for choosing Java.
On a personal note, I continue to use CL for my own projects, where the pleasure of development is more important to me than commercial considerations. I have done so for kons-9, my 3D graphics system, and am happy that I did so. I simply would not have been interested in doing the project in C++. I find that CL is a language which supports me in my development, rather than fighting back.
As an added bonus, the features of CL have encouraged me to think differently about the architecture and design of the system. A system built in C++ would simply have converged towards being another Maya/Houdini/Blender (at best, after many years of development). This way, I have a chance to do something different, which is a big part of the fun.
>"I did early Lisp development on Symbolics Lisp Machines back in the day. Wrote 3D graphics on them."
Interesting. Symbolics Lisp Machines seem almost mythical to me. Are there things about 3D graphics development that lent themselves particularly well to that hardware and Lisp in general? Did Symbolics Lisp Machines target certain types of development or industries?
You can find videos of the machines in use online.
This was in 1985. The Symbolics machines did not have any special 3D hardware. The SGI boxes were the first to do so.
The Symbolics did have a "high resolution" (around 1K pixels across) b&w bit mapped monitor with a windowing system and reasonably fast bitblt (copying of pixel areas) which made it possible to do simple wireframe animations.
In addition my machine had a second color frame buffer with 24-bit color, a rarity at the time which allowed me to develop my first 3D renderer.
Lisp machines were marketed as productivity enhancers with an emphasis on (old fashioned) AI. Expert systems and such. They were more complex pieces of hardware design than the emerging Sun workstations which ran Unix, and consequently more expensive.
A while after I graduated, Symbolics released their own suite of 3D applications (S-Geometry & co) which for a while were the best commercial packages out there, probably until around 1988 when Softimage was released on SGI machines (I developed their animation code).
I wrote about some of this in a series of blog postings:
Rule based systems, natural language parsing, planners, expert systems, symbolic math, theorem provers, and the like. Basically not the current ML/NN systems.
Recently, I've seen the acronym GOFAI used for "good old-fashioned AI".
A question I have that's not answered by the link is why would I want to learn lisp? If you were starting a project today, what are some of the features Lisp offers that make it a better choice than any other (more popular) language? And do those features outweigh the lack of community the larger languages have?
If the Lisp way of thinking about and solving problems is a good fit for you, then you should learn it because it will make you happier and more productive. If not, then don't bother.
That's a Catch-22, of course. How will you know if it's a good fit for you unless you learn it?
So that reduces the decision to: if you are curious whether Lisp is a good fit for you, learn enough of it to find out. If you're not curious about that, don't bother.
But you might want a preview of what things make it a good fit for some people. Lisp in general, and Common Lisp in particular, is a good fit for me because its default mode of operation is to start the Lisp running and teach it by interacting with it expression-by-expression how to be the program I want to build. Common Lisp is consciously designed to work this way, and provides a host of well-designed conveniences for it. It turns out that working that way makes me happier and more productive than working any other way, so it's my favorite programming language.
Not very many other programming languages work that way, but to be fair, some do. Examples of some that do are Smalltalk, FORTH, and Factor.
Some languages and implementations provide more support than others for that style of work. The most comprehensive support for it is to be found in Common Lisp and Smalltalk implementations.
If that sounds interesting, then it's probably worth your time to learn Lisp (or one of the other languages I mentioned). If not, then I wouldn't worry about it.
For me, I've always been fascinated with "live programming environments" and that's been the driving force behind me diving into Common Lisp. I've really come to appreciate this way of working: I was recently working on a web-app that talks to a PostgreSQL database. Normally when developing an app that talks to a database, I'll likely poke around and test out some queries using pgAdmin, the command line, etc. In my Common Lisp app however, once I've got a connection-object to the database, I can just write my queries _within_ the running Lisp system and completely remove the need for those other tools. The plus side is that the data I get back is already in a format that Lisp can deal with. The liveness of the Lisp system really allows for "exploratory" programming.
This 100%. We have excellent DB libraries, they make CL a no-brainer for a LOT of applications, big or small.
The simplest app I have in prod reads data from an existing DB, formats it and sends it to a FTP. No UI, it's a CLI. Runs daily with cron. Was easy to build, to deploy (standalone binary), to maintain. Build and forget.
Do you speak multiple human languages? I speak English and French. There are subjective future tenses in French that can be transliterated, but don't really capture the spirit of the writer: one needs to elaborate in English with such verbosity that it takes a page in English to explain a sentence in French. I'm sure the reverse is true were I a native French speaker. My theory as to why so many existentialists were french was because the language was made for it. :)
Same goes for computer languages. I use LISP when I have computer science-y things I want to explore. For example, I was working on a path finding algorithm for fun years ago and I went to LISP because it is much more natural at conceptual programming. But I wouldn't use LISP to create a GUI, even though it can, nor would I try to write performant 3D graphics. But I would use it to craft a game engine (I wrote a frame language in the early 2000's as part of a game engine that I never finished because once i got the agents decision making working I felt satisfied enough).
The right tool for the right job...
Need to munge a file? PERL
Need to write an embedded application? C
Need to write a GUI? A JS framework (or Qt, or Motif/X if I'm feeling nostalgic)
Need to write a fast loop? ASM
Need to write a something stats-related? Python, R, JMP
Need to explore a computer science problem? LISP, SmallTalk (I don't know Haskell)
Need to work on a project that you're forced to? C++ :)
I haven't actively used Common Lisp in years. But for a long time, I used it professionally.
Common Lisp's greatest strength is that it's "the programmable programming language." You can customize everything from the lexer to the syntax, and you can extensively customize or even replace the object model. It's trivial to write code that writes code.
There are some limitations. Haskell, for example, is less customizable but it works very well at high levels of mathematical abstraction.
Now, in practice, I don't often need the specific kinds of power that Lisp offers. Or rather, when I do need it, I don't need that power instantly at my fingertips. Completely customizing your programming language is something you should think long and hard before doing, and the median team will do it very badly. So I'm happy with the tradeoff offered by Rust macros, for example: They're harder to use than Common Lisp macros, so you only use them when you need them badly enough. Even for most above-average teams, I think it's a net win for macros to be a bit obnoxious to use.
But if you ever find yourself on a small team of incredibly talented programming language designers, and you're working in a problem space where no off-the-shelf language can do what you need, then Common Lisp is well worth a hard look.
Paul Graham's "On Lisp" is actually an excellent overview of the kinds of things you can do with Lisp. Norvig's first AI book is also a good demonstration of Lisp, even if the "AI" part is hopelessly obsolete at this point.
Honestly I just really like the ergonomics of CL. A lot of the features totally exist elsewhere, but weirdly you don't see things like implicit return or a total focus on expressions in dynamic languages too often. Also, I'm a weirdo that genuinely finds parentheses pretty. It's the language I use for all my personal projects because it's the language I enjoy using the most. I don't think I'd use it for work though- the benefits are pretty individual, and people in general seem to like C over CL.
And Elixir, from both parents. Ruby is an odd duck in a lot of ways, being so lisp- and smalltalk-inspired. It also only has expressions- another functionalish feature that seems like a total no-brainer. Beyond Ruby though, we just aren't looking at a huge number of dynamic languages with these features.
Absolutely, but not in dynamic languages. Elixir (well, and Erlang) and Ruby are the only non-lisp dynamic languages I'm aware of with the feature. It's not the only thing I like, but it's a major component of the "functionalish" features that I really like and mostly see attached to static functional languages. Rust is fairly mainstream, and I think a step in the right direction. Honestly I suspect that many people who like Rust actually just like a fast systems language with niceties like implicit return and iterators.
rust is interesting but also a decent amount of ruby folk went to rust... i have no clue if they were part of the building of rust or not but the bundler people went to rust and made the package manager for rust too.
the OP was talking about dynamic languages... haskell and scala are not too surprising that they have implicit returns since they are functional paradigms foremost.
I hear Julia is quite lisp-y in general, so that makes sense. I've been meaning to get around to it regardless- it seems like it could be a lot more ergonomic than relying on numpy.
Fun fact: Matz was a lisper prior to creating ruby. He even wrote an email client entirely in Emacs lisp.
Not wrong that ruby took a lot from perl, but it was heavily influenced by lisp and smalltalk and I'd personally argue those are the two largest influences.
It does seem that ruby was specifically designed to grab Perl programmers though. Several features match exactly.
There are macros in other languages but nowhere will they merge with the language as effortlessly as in the case of Lisp's syntax.
The way Lisp is structured means that almost certainly if you're missing language feature X you can bolt it on, stacking the new features on top of each other to make whatever abstraction you see fit.
It's the kind of thing that makes a Lisp head amused when someone talks about the genius of C# and LINQ (as an example). If you need an abstraction in Lisp, you can almost certainly build it in an ergonomic fashion that just doesn't have a parallel in other languages.
It's one of those powers you don't fully appreciate until you have it and then every other language seems hilariously inadequate in comparison. With great power cones great responsibility and it can all crumble with a lack of discipline (hence why I'm also a fan of ridiculously restrictive languages like Go), but honestly the sort of meta programming possible in Lisp has no equal I know of.
Maybe try Nim. It's a statically typed compiled language and sports a macro system that allows for direct manipulation of the AST. If you don't need to write full blown macros, Nim also offers templates, which are a simpler form of Nim's macros: simpler to write, but not quite as expressive.
This macro checks SQLite table/column references. Aka, if you try to access user_id when the table doesn’t have that column, the “user_id” text in your code will appear as a syntax error in your IDE and when you run the code.
The typed racket project is a bigger example. They added a typechecking system to the language, including a new typescript like variant.
I’m not aware of any other language where 10 lines of idiomatic code right in your codebase can add a new IDE warning.
Haven't you ever thought "hmm, I could do this job faster if I had my own plugin/extension here?"
Lisp is really good for that, when used within Emacs. Extensions are very very simple, basically just the simplest functions inserted into your .emacs file.
My uni used scheme to teach us about recursion. Honestly I don't get it, why not just use Python? That would have been much more useful and applicable IMO.
Python doesn't offer tail call optimization, which makes it a poor fit for a lot of the instruction you'd want to provide on recursion. Especially paired with its default recursion limit (1000?) which means you can't run to any interesting depths anyways, tail recursion or not.
Besides, if you're studying CS at a halfway decent school you'll learn a half dozen languages before graduating anyways (if not more), what's one more to you?
Teaching recursion doesn't mean teaching to do everything with recursion, though. Normally with a language like Python (or, back in my school days, Pascal), you learn stuff like loops first. Recursion is demonstrated on use cases that are not easily done by a loop - e.g. drawing a snowflake.
I was actually not doing a CS major so I would have prefered learning Python. Ended up learning it on my own, so much more useful as a language.
Also, we did not even learn tail call optimization :) so while the argument is valid (I guess it's easier to learn scheme than erlang, ocaml, etc.) it wasn't in my case.
If they were teaching you recursion with Scheme and didn't teach you about tail calls and tail recursion, then you got cheated. That's usually the second thing you learn about recursion in Scheme after learning how to make recursive calls. It's essential to actually making efficient recursive routines in Scheme.
Before there were tens of thousands of open source developers across a dozen or so language ecosystems using collaborative source control and the hard won, but sometimes forgotten, wisdom of decades of internet systems development; we had to build so much more of our stack ourselves. It was much less about finding the appropriate "libraries" or "frameworks" -- their were not that many to even choose from.
You would have to build the layers of your stack from first-principals, or perhaps second-hand mimicry of third hand descriptions. Understanding your problem, and building exactly the tool needed is a very different approach from picking the tool with the momentum, growing developer base, checklist of features, and knobs to twiddle to somehow get something approaching a solution to your problem.
In that setting, Common Lisp has a very powerful feature set; macros, CLOS, interactive debugging with restarts, dynamic redefinition and a fast runtime made to be interactively modified. It is a few days work to make a minimalist ORM, a HTML template language, or a functional query language and engine and proceed to tune it for purpose.
I think we are approaching an inflection point. The software ecosystem complexity, and the specialization of developers into frontend, backend, or specific frameworks and the absolutely unfathomable and delicate chains of transitive trust in the layers and layers of abstraction will become a liability .
Doing "more" of the same, throwing more bodies at it, rewriting the world because your UI or ORM needs a reboot, trying to attach checksums and technical proxies for dependencies as a substitute for the basic fact that you need to know what code you are running and why to be a responsible software vendor; none of this will work.
Truly powerful languages and runtimes with appropriate technology fit for purpose are the way out of this conundrum and the best path to being a responsible and effective computer programmer.
Doing "more" of the same, throwing more bodies at it, rewriting the world
because your UI or ORM needs a reboot, trying to attach checksums and
technical proxies for dependencies as a substitute for the basic fact that
you need to know what code you are running and why to be a responsible
software vendor; none of this will work.
You're assuming that the "bodies" being thrown are going to continue to be human. But what if they aren't? We've already seen what can be done with the very early, relatively primitive AI programming assitants that we have today. What happens when we're competing against an army of Java/Python/Go programmers, all of whom have extensive AI assistance?
I love Lisp. All Lisps. Common Lisp. Scheme. Clojure. Even elisp. And, for a long time I thought Lisp was the future. I thought, like you, that the ever expanding size of codebases written in more conventional programming languages would necessitate a switch to something more functional and more amenable to building non-leaky layers of abstraction because that would be the only way to continue to build without introducing at least one bug for every new feature.
However, the advent of LLM powered coding assistants (like OpenAI's Codex, or Github's Copilot) has made me reassess my view. LLMs benefit from having more training data. Now, the thing that I thought would kill Java/Python/Go codebases, i.e. the sheer number of lines of code required to do even the simplest thing, turns out to be a strength. Because each line (and all its variants) now represents a datum point in the training set for the AI.
Can Lisp be enhanced with AI support. Sure it can, in theory. But in practice, there's far less Lisp code out there. Primarily this is because far fewer people use Lisp on a regular basis. But it's also because, for any given task, far less code is required to accomplish it. Just like Java's greatest weakness turned out to be a strength in a world where we have AI assistance, Lisp's greatest strength turns out to be a weakness.
I'm going to continue to use Lisp wherever I can. If not at work, then in my projects at home. But I'm far less sanguine today about the eventual dominance of Lisp (and Lisp-like languages) than I have been at any time in the past.
I appreciate the irony, but the kind of AI that Lisp was designed for (i.e. automated reasoning, expert systems, etc) is really not the same as the kind of AI that we have today. The AI we have today is very much a "worse-is-better" [1] AI. There's no elegance. No craftmanship. Just scale and raw power. And just like worse-is-better programming languages conquered Lisp, worse-is-better AI approaches conquered the classical approaches that were pioneered along with Lisp.
It might be ironic, but I don't see any particular contradiction in saying that worse-is-better AI magnifies the advantages of worse-is-better programming languages.
I paid for a house for myself, and one for my family with lisp, oh and a small cabin in the woods and a couple touring motorcycles. It was clojure specifically. It was precisely the automated reasoning and expert system you say is not the same kind of AI. We did some of that too, but it was peripheral and at most was an input and support for the captured and encoded and refined knowledge of human experts. That project helped pay for many houses and send kids to college, and otherwise help hundreds make a living.
Before that, I did some java and ruby, which was fun and helped pay rent. But before that I helped pay for many houses and even apartment buildings with Common Lisp. That project has paid for houses and school and living for many dozens of people over the last 20 years. It's still going.
I am not interesting in conquering anything, or winning anything, or what momentum or the power law, or economies of scale, or momentum or other efficiencies of industrial software production. People trot out those arguments all the time to explain why something can't be done, or why they can't do what they want to do, or why something they hate is winning or inevitable.
Believe in yourself and your compatriots, and if you wanna do it with lisp, find some better compatriots.
I heard somewhere that lisp programmers tend to start overly ambitious projects and never finish them. This applied to me when I was most interested in lisp.
This books reads to me like this observation turned into a practical joke.
The draft of this book suggests years of work to populate all the exercises and it has unfortunately hardly been edited since 2015.
I just looked at the author's github page and it fits this stereotype almost too well.
I am like this too and I would really like to know why this is and why people like us flock to lisps.
Please don't start programming language flamewars. We (and Lisp!) had enough of those a long time ago, and part of the idea of HN is to avoid this kind of thing.
> The biggest secret to Lisp is that it is actually the simplest programming language ever created---and that, coupled with its expressiveness and elegance, is why it is favored exclusively by the best programmers in the world.
This is clearly a very opinionated book.
Personally I find Haskell, while perhaps not as simple, both more expressive and more elegant. But I don't imagine it is favored by the worlds best programmers.
The problem with almost all LISP tutorials, books,... is there's no guide on how to install toolings at the beginning. Instead, there's just praise and praise.
Literally everything you're asking for is in that link. The author has the opinion that you don't need fancy IDE features which is an arguable point but they do list what editors for each OS work in their experience.
I first leaned lisp in college (1964) and have not touched it much since then. But now that I am retired I am going to give it a shot. What extensions in vscode should I use? I installed steel bank and quicklisp. Thanks,
"Clojure for brave and true" has in my opinion an excellent section on Clojure tooling in emacs (which I wish i read when I was starting out with emacs).
It is a strength (they do cover tooling), but also a weakness. Throwing beginners into learning emacs, as well as a new language, and likely a new programming paradigm, is a massive ask. I think it is mistake for Clojure that Brave and True is the most recommended book to start out.
i use evil, because muscle memory. I havn't spent the time to train myself to learn something different. I probably never will because I still use vi/vim on remote machines.
doom emacs was a game changer for me and allowed me to pretty quickly switch from neovim. Since investing more in the ecosystem, I wont be letting go of emacs anytime soon
Let me clarify. I want an editor to behave the same as every other editor on my system. That means standard shortcuts for basic operations, for starters, the use of standard OS dialogs etc. Last I tried Emacs, you had to spend considerable time browsing the docs to figure out all the little things that need to be set in the config to get 90% there.
That is fair. Emacs does have a CUA mode[1] for more standard shortcuts. But the OS dialogs will not look native, and it makes sense if that experience does not work for you.
I see that in your professional capacity, you're an engineer on VS Code, so I bet that you know it well enough to make it work for you for Common Lisp, too. For all the oft-cited reasons, I cannot use VS Code. But it is great if it works for you.
FWIW I don't consider VSCode to be a particularly good example of native integration, either, although at least it tries. But, well - Electron.
As for CL itself, I dabbled in it in my time, and I found it more interesting to broaden the mind than useful for practical applications. The dearth of quality, well-maintained libraries is the main stumbling block for serious use. It's not that it's impossible - it's just that the effort involved in putting everything together exceeds whatever benefits accrue from the language itself being more powerful than usual.
That aside, though, the discussion was about how getting started with CL for someone new is more complicated than it needs to be in part because the ecosystem is so centered around Emacs for code editing. In general, people who get interested in CL are already devs - but Emacs isn't all that popular even among devs these days; I see Sublime far more often, for example. But all CL tutorials actively push Emacs - and for good reason, since it really is the best option available! - which makes the barrier of entry that much higher for people coming from, say, JS or Python.
Curious to know how big the cross section of people is that are ready/eager for CL, but don't want to touch Emacs. I think its rather nice this might act as a screen, they are both tied together, even if mostly spiritually now.
In general though, I'd say switch your focus to Scheme, and use Dr.Racket, if you really really don't want to use Emacs.
