15 ms·

It's 2023, so of course I'm learning Common Lisp

373 points by behnamoh 3y ago

jbottoms 3y ago
Then Prolog should be somewhere on your list also.
kaveh808 3y ago
If you're into 3D graphics, this could be a fun Common Lisp codebase to look at. I have tried to keep it simple and comprehensible. https://github.com/kaveh808/kons-9 https://github.com/kaveh808/kons-9
- whartung 3y ago
  Look up Kaveh’s CL tutorial videos on YouTube. They’re really good.
  - bkomarath 3y ago
    I think you are replying to him.
    - kaveh808 3y ago
      My Youtube channel: https://www.youtube.com/channel/UCHNK9EcrAwP7djlwQN4C_tg https://www.youtube.com/channel/UCHNK9EcrAwP7djlwQN4C_tg
      - the-smug-one 3y ago
        Well, did you watch the recommended tutorials? Or are you one of those artists that don't watch their own work :-)?
        kaveh808 3y ago
        If that was intended for me, I rarely watch my own videos. Only when I want to check on something. Don't like the sound of my voice. :)
ilrwbwrkhv 3y ago
Steel Bank Common Lisp is the workhorse which led me to build profitable software companies. I don't think I would be as productive without it. The repl driven workflow is amazing and the lisp images are rock solid and highly performant.
- haolez 3y ago
  It looks awesome, but I'm too lazy as of today to go back to Emacs. I usually just use VSCode close to the defaults for my (mostly) Python and JavaScript development. I don't code full time, since I'm on a CTO role.
  - ilrwbwrkhv 3y ago
    I don't know if you're interested in Sublime Text or not but https://github.com/s-clerc/slyblime https://github.com/s-clerc/slyblime is pretty good. VS Code also has Alive which I heard is good although I don't use Electron apps.
    - haolez 3y ago
      Thanks a lot! It does indeed look good. Btw, what made you choose Common Lisp instead of Scheme (Guile, Racket, etc) or Clojure? What made it more business effective? Genuine curiosity :)
      - ilrwbwrkhv 3y ago
        I dislike the JVM and the other lisps did not have the code performance and stability I needed.
  - nbf_1995 3y ago
    You may be interested in https://github.com/nobody-famous/alive https://github.com/nobody-famous/alive which brings the power of slime to vscode (Mostly, it's relatively new and missing some features, but getting better all the time)
- deleted 3y ago
nine_k 3y ago
The scoop: Scheme and Janet are great, but the author wants a more standalone language. What makes the difference is the breakloop, a full-blown REPL that opens when an error in a program occurs. Not a stacktrace, not a debugger; just build from the point where it's currently broken.
- peanutz454 3y ago
  This sounds so amazing, why is Common Lisp not the most popular language out there? (asking as someone who almost never writes code)
  - Blackthorn 3y ago
    It's questionable whether it's really much better than just a debugger with a core dump (what I usually work on, it's not any better). It is, however, a pretty snazzy feature.
    - em-bee 3y ago
      with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required. smalltalk can do the same btw. i had been working on a small website where a specific request from the browser would fail. instead of sending a failure message the request would just hang. in the mean time on the server in my pharo smalltalk window an error would pop up. when i fixed the error, the download of the request resumed in the browser as if nothing had happened other than a delay.
      - Blackthorn 3y ago
        > with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required. We like to make sure everything running in prod is verifiably built from source in-repo. So that's the thing, while it's a really snazzy feature for sure, the value over the rest of the world is on the questionable side. At least for our use case, but I think it's true for most use cases. edit: Also really curious about your smalltalk and pharo experience. Sounds fascinating!
ungamedplayer 3y ago
Me too buddy. I'm not even sure how I got to this point, but I can't go back.
- schemescape 3y ago
  Care to share what you’re using CL for?
  - ungamedplayer 3y ago
    I automate my workflow for approval of rhel kernel content to customers. Keeping the wheels on the delivery of 12 different streams of kernels to customers. It also controls the workflow of delivery of intermediate "hot fix" kernels between scheduled releases when fixes are needed immediately. I also use it for gathering metrics on gitlab ci and internal pipelines, alerting if the system is stalling or performing outside acceptable limits.
Zambyte 3y ago
I don't see why the author says: > I had previously abandoned using Scheme because, frankly, I ran out of free time for exploratory programming. But they find Common Lisp acceptable. In what way are Schemes more "exploratory" than Common Lisp? Isn't that exactly what the author says they like about CL (REPL driven development)?
- schemescape 3y ago
  Sorry that was unclear. What I meant was: a while back, I was exploring Scheme (motivated by SICP) and then ran out of free time. Now, I’ve got some free time again and want to try Common Lisp because of the REPL-driven workflow. It wasn’t meant to be a comment on Scheme vs. CL.
  - em-bee 3y ago
    i found the repl driven workflow intriguing but i could never get into it. i am not an emacs user and the vim integration wasn't as good as slime promises to be and i couldn't really get comfortable running lisp from within vim. not ssure, i probably didn't try to hard. smalltalk on the other hand made this a lot easier. not repl driven but having an actual UI to manage code and handling errors it provides the same ability to fix issues at runtime without restarting but with a nicer interface to manage the code.
  - Zambyte 3y ago
    I see, thanks for clarifying!
  - gorjusborg 3y ago
    Thanks for clarifying. I recently went into the lispy rabbit hole for a while. Scheme is so beautiful. CL seems more willing to compromise for pragmatism.
    - db48x 3y ago
      Yes, CL is extremely pragmatic. And Scheme was invented specifically as a pedagogical tool, so everything is much cleaner. At least until you install scm-utils, and find that it added an entire computer algebra system and physics simulation system and so on. :)
robomartin 3y ago
Let me preface this by saying I used LISP professionally in the '80's for about ten years. It's a great language. It is right up there at the top of my list with Assembler, APL and Forth as languages that taught me so much more than the typical C-like language path most people are exposed to today. And, yes, I used those languages professionally for years. I have always said it is important to learn these non-C languages. However... > I've spent some time contemplating future-proof programming languages because I want to ensure that code I write will be usable in the future. I think it is clear that it will not be long until you can use an AI-based tool to translate any program from language A to language B. And, in fact, likely improve, maintain and extend it. For example, you might be able to have the AI tool write a function or module in assembler targeted at different processors and be able to accelerate critical code in a platform-specific manner that would be almost impossible for most developers to manage and maintain today. I experimented with some of this using ChatGPT. We built a product using MicroPython that require hard real time performance. Sure, MicroPython was not the right choice to begin with. This was one of those projects where we walked into something that morphed and we were stuck. Being that I am perfectly comfortable in assembler, I replaced chunks of code with ARM assembly routings. The performance boost was massive, of course. As an experiment, I wrote a specification for one of those modules and asked ChatGPT to write the code in ARM assembler. It took all of five seconds to get a listing. Let's just say it took me a lot longer. The code was not optimal, yet, it worked just fine. Someone like me, with experience in the domain, could easily take that as a starting point and improve from there. Just for kicks, I asked ChatGPT to write the same code in C, C++, JS, Python, 8080, 8085, 6502, 68K and x86 assembler. That probably took a minute or so. Did not test all of the generated code. All of it looked like it would run just fine. In other words, I believe that, today, the only reason to pick a language is likely something like: It's what I know and it has the libraries, frameworks and support I need. In some cases, it's because it's the only way to achieve required performance (example: Python is 70+ times slower than C). Code longevity is not likely to be an issue at all.
- behnamoh 3y ago
  > In other words, I believe that, today, the only reason to pick a language is likely something like: It's what I know and it has the libraries, frameworks and support I need. I would take it even further and say that in the near future, everyone will have their own beloved DSL completely customized to their needs and the AI will be able to translate any code to your favorite DSL. You’ll code and commit the changes and the AI will take care of that and convert it back to other peoples’ DSL’s.
schemescape 3y ago
Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner. Here's what I've liked about Common Lisp so far: * The condition system is neat and I've never used anything like it -- you can easily control code from afar with restarts * REPL-driven programming is handy in situations where you don't quite know what will happen and don't want to lose context -- for example parsing data from a source you're unfamiliar with, you can just update your code and continue on instead of having to save, possibly compile, and restart from the very beginning * Common Lisp has a lot of implementations and there's a good deal of interoperability -- I was able to swap out implementations to trade speed (SBCL) for memory usage (CLISP) in one case (multiple compatible implementations is one of the reasons I've been leaning towards CL instead of Scheme for learning a Lisp) * Even as an Emacs noob, the integration with Common Lisp is excellent, and it works great even on my super slow netbook where I've been developing -- this isn't as big of an advantage these days with fast computers, VS Code, and language servers, but it's definitely retrofuturistic There's also a few things I don't like: * The most popular package manager (QuickLisp) is nice, but not nearly as featureful as I've become accustomed to with newer languages/ecosystems * Since the language itself is frozen in time, you need lots of interoperability libraries for threads, synchronization, command line arguments, and tons of other things * I really, really wish SBCL could support fully static builds, to enable distributing binaries to non-glibc Linux distributions I'm sure there are more pros/cons, but that's what came to mind just now.
- atgreen 3y ago
  Check out ocicl as an alternative to quicklisp!
- tgbugs 3y ago
  For static builds, if you're willing to run a slightly older version of sbcl daewok's work on building and linking sbcl in a musl environment might be solution you're looking for. I've tried to port his patches to more recent versions but there are segfaults due to changes in upstream. https://www.timmons.dev/posts/static-executables-with-sbcl.html https://www.timmons.dev/posts/static-executables-with-sbcl.h... https://www.timmons.dev/posts/static-executables-with-sbcl-v2.html https://www.timmons.dev/posts/static-executables-with-sbcl-v...
koito17 3y ago
I use Clojure at work but wow do I miss just about everything about Common Lisp whenever I have to debug anything or want performant code. Being able to be in nested errors and click at any part of the stack to inspect lexical bindings is extremely useful, and more importantly, clicking on an object then pushing M-<RET> to copy it to my REPL is much nicer than what Clojure offers (tap>, which I consider a glorified pretty printer even if you use tools like Portal). As for performance, well, Common Lisp lets you statically type things, and SBCL can emit really efficient code if you do this. I find it helpful to run DISASSEMBLE on my own code to see what exactly is being emitted and optimize from there. And more importantly, packages like SB-SIMD and Loopus are a god send for any number crunching application.
- Capricorn2481 3y ago
  You should look at flowstorm for Clojure. It lets you step through and back from a function and you can send maps to the repl with their functions.
- maxwelljoslyn 3y ago
  This nicely summarizes some of my frustrations with using Clojure for my master's thesis. I'm not unhappy with the choice. Clojure allows such a juicy crossover between "everything is a key-value map, mannn" and "If it has :quack key set to true, treat it like a duck" which works really well for entity-component-system game-design-y things. but the development story in Common Lisp ... and my gawd, the CONDITION SYSTEM ... were things that I sorely missed for the last year. and I'm not even that experienced of a CL hacker. It just grew on me so quickly. If only CLOS and the primitive data types in CL played together more nicely than they seem to.
  - rmckayfleming 3y ago
    I know. I've been spending a lot of time with CL, Scheme, and Clojure the past few years, and the ideal Lisp is some combination of them all. There are aspects of each that I miss in the others. CL has the nicest environment and development story (generally speaking). Scheme feels more refined in the small. And although they can be divisive, I really appreciate Clojure's data structure literals.
temporallobe 3y ago
As a Clojure dev, break loops and REPL-driven workflows sound wonderful, and something we could definitely benefit from, which would make it more like front-end coding with JS/TypeScript using the browser’s awesome debugging tools. Sadly, the state of tooling and community support for the Clojure ecosystem seems to be pretty lackluster at present.
- netbioserror 3y ago
  Clojure can kinda-sorta simulate the true REPL workflow, if you're making something like a web server where deep calls down the code hierarchy only happen with each request. So you can rewrite and reload various functions while the server is still running and make requests from your browser again. The caveat is that eventually these redefinitions and overwrites pollute the namespaces and eventually something will break, at which point you reload your server.
trhr 3y ago
When I want "this will run forever," I write it in Rust. When I want "this will compile forever," I write it in ANSI C. When I want "this will live forever," I write it Python 2.7 and make it the backbone of the entire org's infra templating. Bonus points if it's a custom Ansible module.
10g1k 3y ago
There are plenty of old business systems which are critical, can't be removed or turned off, and use LISP, COBOL, etc. Meanwhile, nothing important uses Clojure or other trendy flash-in-the-pan language. If you want an interesting project, sure, use Clojure or something. If you want money, learn COBOL.
- jcpst 3y ago
  Doesn’t walmart use clojure?
- xedrac 3y ago
  I hear this a lot, but have never once seen a COBOL job posting.
  - manicennui 3y ago
    I think a lot of these jobs go to former employees who now contract.
  - 10g1k 3y ago
    That's because gigs in trendy languages come and go, and you might earn good pay for six months, whereas cobol gigs run for 20 years and pay consistently high salaries.
  - asimovfan 3y ago
    https://de.indeed.com/q-cobol-entwickler-jobs.html?vjk=8d36a8c68f360866 https://de.indeed.com/q-cobol-entwickler-jobs.html?vjk=8d36a...
- manicennui 3y ago
  It's not as though the company that bought the consultancy that employs many of the core Clojure people runs a bank with Clojure.
- Capricorn2481 3y ago
  If we're gonna go off what has the most businesses built on it, LISP wouldn't even be in the top 20
opportune 3y ago
I see a lot of “coding” talk in the blog and comments from the author here, but few mentions as to what kind of software they’re building or what use cases they’re targeting. My hot take is that the reason functional programming never took off is that, while it certainly is fine for writing programs, most software these days is not “program running locally on my pc/server from the command line until it completes” and is instead “program that starts, reacts to input from user, then gets closed by the user” or “program that starts, then responds to network or other automated I/O (to serve web pages, to monitor something, to emit logs, etc) then stops when the other software tells it to”. This is a lot harder to do in a purely functional style, or at least it is in most opinionated functional programming implementations I’ve used, because you’re no longer “just” evaluating some expression but instead initializing state, reacting to I/O, then updating state and/or performing further I/O potentially while using parallelization to perform monitoring/listen for other things/perform further I/O and state updates. Of course it’s not impossible to do these things with Lisp but from my couple of semesters of exposure of FP in undergrad and use of FP features in C++ and Scala professionally to solve these kinds of problems… it seems quite hard to get FP to work for these applications, and that lack of suitability is what discourages me from diving more fully into FP
- lukego 3y ago
  I'm using Lisp for simulation. It's really wonderful being able to poke and prod long-running computations while they run. I missed this too much when I tried using Julia.
- vippy 3y ago
  It took me a while to grok monads, and the IO monad, and longer still to figure out how to compose them in safe ways, and manipulate execution order, etc. But: now I can write typesafe applications, and I produce fewer bugs when I work in non-FP languages (I get paid to write Java.) Lisp is a starting point. Haskell is where it's at. I recommend learning the style, even if you never produce production code in it.
  - xedrac 3y ago
    Yes, Haskell is magnificent for learning FP. I used to think Haskell was terrible for IO, but my tune has changed dramatically since I started working with it full time.
xedrac 3y ago
There is something very playful about lisp that is so intriguing to me. I've come to rely heavily on powerful type systems at work (which is amazing), but lisp feels like unbounded imagination flowing at my fingertips.
dutchblacksmith 3y ago
Big fan of Lispworks (Yes, there is a free version). Using it in production, as many others. Using Quicklisp in experiments. Not direct in my codebase. Lisp will always be there. Learning Lisp will make you a better programmer, while having fun.
Roark66 3y ago
I'd be interested in if you considered Guile first and what made you decide in favor of common lisp. Few years ago when I decided its finally time to learn lisp I looked at few variants and Guile seemed to have the benefit of: fairly vibrant(but somewhat hermetic) online community, a sizable manual that describes most frequently used APIs (you can learn the language itself very quickly, but it's the knowledge of the APIs you need to do anything in the "real world"), and being actively maintained and extended. So I chose Guile. For those that don't know these terms Guile and common lisp are two implementations of the same scheme language (simplifying a lot).
- schemescape 3y ago
  When I looked, I got the impression that Guile didn’t run on Windows, and that’s a platform I needed to support.
massimosgrelli 3y ago
Always been fascinated by Lisp, but I never spent enough time to enjoy its elegance and applications. I went through Lurk, a Lisp dialect, a Turing-complete programming language for recursive zk-SNARKs in the last year. I started to grasp a bit of its potential in solving real-world problems, but still too little to understand why it's so right for solving some problems. I'm curious about what other projects you guys are successfully and better solving because of Lisp today.
ghfwlc 3y ago
Common Lisp is still the most pleasant REPL language. The only complaint I have is that too many function names are taken due to the large spec.
- tmtvl 3y ago
  It's fine, you can shadow any function you want: <https://cl-community-spec.github.io/pages/shadow.html https://cl-community-spec.github.io/pages/shadow.html>
massimosgrelli 3y ago
I'm sorry about my basic question. Back in the 80s, AI was betting on Lisp machines — https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine — now, of course obsolete. Is Lisp still relevant in the AI space?
- ShamelessC 3y ago
  Not really no. It’s mostly Python 3. The AI space back then had heavy emphasis on symbolic AI. Modern deep learning algorithms have very little overlap.
anonzzzies 3y ago
I love CL and I really miss it when i'm doing something else. I mean, many things are such a pain in 'modern' languages that it's not even funny, when you compare it to the Lisp experience of even decades ago. There are many cons, but those are simply not as bad as most of the pure technical language/dev env cons in almost everything else. Sure Python & JS have more uptake, more libraries etc, but the experience of developing for them is so much worse. IMHO of course. I have been doing a lot of languages over the years including C#, TS, Py, Hs and more esoteric ones, but I keep coming back to CL (SBCL + emacs + Slime) when I get seriously angry about stuff that is missing or plainly bad in those languages. It makes me relaxed and convinced there is some good in the world after all. I am currently raising for a product we (foolishly so) bootstrapped in Typescript but now we will, for a launch version, redo it in CL. Meaning I get to work with / in CL (and all of the fun stuff; implementing DSL, code generation, working with macros, implementing a static type solver etc) for the coming 3-5 years before we launch. Lovely.
- pjc50 3y ago
  > There are many cons Can't have Lisp without cons. (sorry) What do you miss in Lisp when working in C#?
  - anonzzzies 3y ago
    I would say: 1) painless debugging with Emacs/Slime vs Rider/VS/VSCode 2) performance & consistency of it; SBCL is fast and remains that way, I can leave emacs/slime running for months and it doesn't degrade; vs/rider... they really burn a hole through my laptop and isn't even that good at most things compared, even on really old computers 3) Re-eval; you can re-eval a region, function, file, last expression etc, during running and/or debugging, which is very flexible ; something wrong, change (or write the same function next to it with a fix; very handy), re-eval and when happy , clean up and save 4) data formats... We have had, since 'forever' had 'proxy' tooling that converts any incoming and outgoing JSON to and from Lisp lists. While in code, we only work with s-expressions and it makes life so easy.
- Thiez 3y ago
  Why is Typescript unsuitable for the product?
katspaugh 3y ago
Kudos for the Janet shout out! It's an excellent little language, and Janet for Mortals is an excellent book to learn it. The author has a great sense of humor.
largbae 3y ago
I wonder if LLM assist tools like GitHub CoPilot will further consolidate the programming language landscape. The productivity gains from using a well-supported language might raise the barrier to entry for new or niche ones.
qwerty456127 3y ago
> It's 2023, so of course I'm learning Common Lisp So am I although none of the features mentioned seem useful to me so far (perhaps I will change my mind once I become fluent). I just hope Lisp will make it easier to express my thought in code, minimizing/abstracting all the cruft/boilerplate. To me Lisp expressions seem the most natural way of expressing a thought. As I primarily am interested in writing GUI apps I hope to master Clog or find/develop a good wrapper around some GUI toolkit.
harshaw 3y ago
as a manager type, I wish my engineers were more broadly aware of REPL style development and the massive productivity boost it can have for certain kinds of development. I am used to doing a lot of ruby/python/js in REPL, but the idea of a sort of "break into a repl and implement the missing function and continue" sounds really nifty.
omgmajk 3y ago
I am also learning common lisp in 2023, I like it!
xgdgsc 3y ago
It' s 2023. It' s time to switch [From Common Lisp to Julia](https://news.ycombinator.com/item?id=32745318 https://news.ycombinator.com/item?id=32745318)

373 points by behnamoh 3y ago

Then Prolog should be somewhere on your list also.

If you're into 3D graphics, this could be a fun Common Lisp codebase to look at. I have tried to keep it simple and comprehensible. https://github.com/kaveh808/kons-9 https://github.com/kaveh808/kons-9

whartung 3y ago
Look up Kaveh’s CL tutorial videos on YouTube. They’re really good.
- bkomarath 3y ago
  I think you are replying to him.
  - kaveh808 3y ago
    My Youtube channel: https://www.youtube.com/channel/UCHNK9EcrAwP7djlwQN4C_tg https://www.youtube.com/channel/UCHNK9EcrAwP7djlwQN4C_tg
    - the-smug-one 3y ago
      Well, did you watch the recommended tutorials? Or are you one of those artists that don't watch their own work :-)?
      - kaveh808 3y ago
        If that was intended for me, I rarely watch my own videos. Only when I want to check on something. Don't like the sound of my voice. :)

ilrwbwrkhv 3y ago

Steel Bank Common Lisp is the workhorse which led me to build profitable software companies. I don't think I would be as productive without it. The repl driven workflow is amazing and the lisp images are rock solid and highly performant.

haolez 3y ago
It looks awesome, but I'm too lazy as of today to go back to Emacs. I usually just use VSCode close to the defaults for my (mostly) Python and JavaScript development. I don't code full time, since I'm on a CTO role.
- ilrwbwrkhv 3y ago
  I don't know if you're interested in Sublime Text or not but https://github.com/s-clerc/slyblime https://github.com/s-clerc/slyblime is pretty good. VS Code also has Alive which I heard is good although I don't use Electron apps.
  - haolez 3y ago
    Thanks a lot! It does indeed look good. Btw, what made you choose Common Lisp instead of Scheme (Guile, Racket, etc) or Clojure? What made it more business effective? Genuine curiosity :)
    - ilrwbwrkhv 3y ago
      I dislike the JVM and the other lisps did not have the code performance and stability I needed.
- nbf_1995 3y ago
  You may be interested in https://github.com/nobody-famous/alive https://github.com/nobody-famous/alive which brings the power of slime to vscode (Mostly, it's relatively new and missing some features, but getting better all the time)
deleted 3y ago

nine_k 3y ago

The scoop: Scheme and Janet are great, but the author wants a more standalone language. What makes the difference is the breakloop, a full-blown REPL that opens when an error in a program occurs. Not a stacktrace, not a debugger; just build from the point where it's currently broken.

peanutz454 3y ago
This sounds so amazing, why is Common Lisp not the most popular language out there? (asking as someone who almost never writes code)
- Blackthorn 3y ago
  It's questionable whether it's really much better than just a debugger with a core dump (what I usually work on, it's not any better). It is, however, a pretty snazzy feature.
  - em-bee 3y ago
    with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required. smalltalk can do the same btw. i had been working on a small website where a specific request from the browser would fail. instead of sending a failure message the request would just hang. in the mean time on the server in my pharo smalltalk window an error would pop up. when i fixed the error, the download of the request resumed in the browser as if nothing had happened other than a delay.
    - Blackthorn 3y ago
      > with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required. We like to make sure everything running in prod is verifiably built from source in-repo. So that's the thing, while it's a really snazzy feature for sure, the value over the rest of the world is on the questionable side. At least for our use case, but I think it's true for most use cases. edit: Also really curious about your smalltalk and pharo experience. Sounds fascinating!

ungamedplayer 3y ago

Me too buddy. I'm not even sure how I got to this point, but I can't go back.

schemescape 3y ago
Care to share what you’re using CL for?
- ungamedplayer 3y ago
  I automate my workflow for approval of rhel kernel content to customers. Keeping the wheels on the delivery of 12 different streams of kernels to customers. It also controls the workflow of delivery of intermediate "hot fix" kernels between scheduled releases when fixes are needed immediately. I also use it for gathering metrics on gitlab ci and internal pipelines, alerting if the system is stalling or performing outside acceptable limits.

Zambyte 3y ago

I don't see why the author says: > I had previously abandoned using Scheme because, frankly, I ran out of free time for exploratory programming. But they find Common Lisp acceptable. In what way are Schemes more "exploratory" than Common Lisp? Isn't that exactly what the author says they like about CL (REPL driven development)?

schemescape 3y ago
Sorry that was unclear. What I meant was: a while back, I was exploring Scheme (motivated by SICP) and then ran out of free time. Now, I’ve got some free time again and want to try Common Lisp because of the REPL-driven workflow. It wasn’t meant to be a comment on Scheme vs. CL.
- em-bee 3y ago
  i found the repl driven workflow intriguing but i could never get into it. i am not an emacs user and the vim integration wasn't as good as slime promises to be and i couldn't really get comfortable running lisp from within vim. not ssure, i probably didn't try to hard. smalltalk on the other hand made this a lot easier. not repl driven but having an actual UI to manage code and handling errors it provides the same ability to fix issues at runtime without restarting but with a nicer interface to manage the code.
- Zambyte 3y ago
  I see, thanks for clarifying!
- gorjusborg 3y ago
  Thanks for clarifying. I recently went into the lispy rabbit hole for a while. Scheme is so beautiful. CL seems more willing to compromise for pragmatism.
  - db48x 3y ago
    Yes, CL is extremely pragmatic. And Scheme was invented specifically as a pedagogical tool, so everything is much cleaner. At least until you install scm-utils, and find that it added an entire computer algebra system and physics simulation system and so on. :)

robomartin 3y ago

Let me preface this by saying I used LISP professionally in the '80's for about ten years. It's a great language. It is right up there at the top of my list with Assembler, APL and Forth as languages that taught me so much more than the typical C-like language path most people are exposed to today. And, yes, I used those languages professionally for years. I have always said it is important to learn these non-C languages. However... > I've spent some time contemplating future-proof programming languages because I want to ensure that code I write will be usable in the future. I think it is clear that it will not be long until you can use an AI-based tool to translate any program from language A to language B. And, in fact, likely improve, maintain and extend it. For example, you might be able to have the AI tool write a function or module in assembler targeted at different processors and be able to accelerate critical code in a platform-specific manner that would be almost impossible for most developers to manage and maintain today. I experimented with some of this using ChatGPT. We built a product using MicroPython that require hard real time performance. Sure, MicroPython was not the right choice to begin with. This was one of those projects where we walked into something that morphed and we were stuck. Being that I am perfectly comfortable in assembler, I replaced chunks of code with ARM assembly routings. The performance boost was massive, of course. As an experiment, I wrote a specification for one of those modules and asked ChatGPT to write the code in ARM assembler. It took all of five seconds to get a listing. Let's just say it took me a lot longer. The code was not optimal, yet, it worked just fine. Someone like me, with experience in the domain, could easily take that as a starting point and improve from there. Just for kicks, I asked ChatGPT to write the same code in C, C++, JS, Python, 8080, 8085, 6502, 68K and x86 assembler. That probably took a minute or so. Did not test all of the generated code. All of it looked like it would run just fine. In other words, I believe that, today, the only reason to pick a language is likely something like: It's what I know and it has the libraries, frameworks and support I need. In some cases, it's because it's the only way to achieve required performance (example: Python is 70+ times slower than C). Code longevity is not likely to be an issue at all.

behnamoh 3y ago
> In other words, I believe that, today, the only reason to pick a language is likely something like: It's what I know and it has the libraries, frameworks and support I need. I would take it even further and say that in the near future, everyone will have their own beloved DSL completely customized to their needs and the AI will be able to translate any code to your favorite DSL. You’ll code and commit the changes and the AI will take care of that and convert it back to other peoples’ DSL’s.

schemescape 3y ago

Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner. Here's what I've liked about Common Lisp so far: * The condition system is neat and I've never used anything like it -- you can easily control code from afar with restarts * REPL-driven programming is handy in situations where you don't quite know what will happen and don't want to lose context -- for example parsing data from a source you're unfamiliar with, you can just update your code and continue on instead of having to save, possibly compile, and restart from the very beginning * Common Lisp has a lot of implementations and there's a good deal of interoperability -- I was able to swap out implementations to trade speed (SBCL) for memory usage (CLISP) in one case (multiple compatible implementations is one of the reasons I've been leaning towards CL instead of Scheme for learning a Lisp) * Even as an Emacs noob, the integration with Common Lisp is excellent, and it works great even on my super slow netbook where I've been developing -- this isn't as big of an advantage these days with fast computers, VS Code, and language servers, but it's definitely retrofuturistic There's also a few things I don't like: * The most popular package manager (QuickLisp) is nice, but not nearly as featureful as I've become accustomed to with newer languages/ecosystems * Since the language itself is frozen in time, you need lots of interoperability libraries for threads, synchronization, command line arguments, and tons of other things * I really, really wish SBCL could support fully static builds, to enable distributing binaries to non-glibc Linux distributions I'm sure there are more pros/cons, but that's what came to mind just now.

atgreen 3y ago
Check out ocicl as an alternative to quicklisp!
tgbugs 3y ago
For static builds, if you're willing to run a slightly older version of sbcl daewok's work on building and linking sbcl in a musl environment might be solution you're looking for. I've tried to port his patches to more recent versions but there are segfaults due to changes in upstream. https://www.timmons.dev/posts/static-executables-with-sbcl.html https://www.timmons.dev/posts/static-executables-with-sbcl.h... https://www.timmons.dev/posts/static-executables-with-sbcl-v2.html https://www.timmons.dev/posts/static-executables-with-sbcl-v...

koito17 3y ago

I use Clojure at work but wow do I miss just about everything about Common Lisp whenever I have to debug anything or want performant code. Being able to be in nested errors and click at any part of the stack to inspect lexical bindings is extremely useful, and more importantly, clicking on an object then pushing M-<RET> to copy it to my REPL is much nicer than what Clojure offers (tap>, which I consider a glorified pretty printer even if you use tools like Portal). As for performance, well, Common Lisp lets you statically type things, and SBCL can emit really efficient code if you do this. I find it helpful to run DISASSEMBLE on my own code to see what exactly is being emitted and optimize from there. And more importantly, packages like SB-SIMD and Loopus are a god send for any number crunching application.

Capricorn2481 3y ago
You should look at flowstorm for Clojure. It lets you step through and back from a function and you can send maps to the repl with their functions.
maxwelljoslyn 3y ago
This nicely summarizes some of my frustrations with using Clojure for my master's thesis. I'm not unhappy with the choice. Clojure allows such a juicy crossover between "everything is a key-value map, mannn" and "If it has :quack key set to true, treat it like a duck" which works really well for entity-component-system game-design-y things. but the development story in Common Lisp ... and my gawd, the CONDITION SYSTEM ... were things that I sorely missed for the last year. and I'm not even that experienced of a CL hacker. It just grew on me so quickly. If only CLOS and the primitive data types in CL played together more nicely than they seem to.
- rmckayfleming 3y ago
  I know. I've been spending a lot of time with CL, Scheme, and Clojure the past few years, and the ideal Lisp is some combination of them all. There are aspects of each that I miss in the others. CL has the nicest environment and development story (generally speaking). Scheme feels more refined in the small. And although they can be divisive, I really appreciate Clojure's data structure literals.

temporallobe 3y ago

As a Clojure dev, break loops and REPL-driven workflows sound wonderful, and something we could definitely benefit from, which would make it more like front-end coding with JS/TypeScript using the browser’s awesome debugging tools. Sadly, the state of tooling and community support for the Clojure ecosystem seems to be pretty lackluster at present.

netbioserror 3y ago
Clojure can kinda-sorta simulate the true REPL workflow, if you're making something like a web server where deep calls down the code hierarchy only happen with each request. So you can rewrite and reload various functions while the server is still running and make requests from your browser again. The caveat is that eventually these redefinitions and overwrites pollute the namespaces and eventually something will break, at which point you reload your server.

trhr 3y ago

When I want "this will run forever," I write it in Rust. When I want "this will compile forever," I write it in ANSI C. When I want "this will live forever," I write it Python 2.7 and make it the backbone of the entire org's infra templating. Bonus points if it's a custom Ansible module.

10g1k 3y ago

There are plenty of old business systems which are critical, can't be removed or turned off, and use LISP, COBOL, etc. Meanwhile, nothing important uses Clojure or other trendy flash-in-the-pan language. If you want an interesting project, sure, use Clojure or something. If you want money, learn COBOL.

jcpst 3y ago
Doesn’t walmart use clojure?
xedrac 3y ago
I hear this a lot, but have never once seen a COBOL job posting.
- manicennui 3y ago
  I think a lot of these jobs go to former employees who now contract.
- 10g1k 3y ago
  That's because gigs in trendy languages come and go, and you might earn good pay for six months, whereas cobol gigs run for 20 years and pay consistently high salaries.
- asimovfan 3y ago
  https://de.indeed.com/q-cobol-entwickler-jobs.html?vjk=8d36a8c68f360866 https://de.indeed.com/q-cobol-entwickler-jobs.html?vjk=8d36a...
manicennui 3y ago
It's not as though the company that bought the consultancy that employs many of the core Clojure people runs a bank with Clojure.
Capricorn2481 3y ago
If we're gonna go off what has the most businesses built on it, LISP wouldn't even be in the top 20

opportune 3y ago

I see a lot of “coding” talk in the blog and comments from the author here, but few mentions as to what kind of software they’re building or what use cases they’re targeting. My hot take is that the reason functional programming never took off is that, while it certainly is fine for writing programs, most software these days is not “program running locally on my pc/server from the command line until it completes” and is instead “program that starts, reacts to input from user, then gets closed by the user” or “program that starts, then responds to network or other automated I/O (to serve web pages, to monitor something, to emit logs, etc) then stops when the other software tells it to”. This is a lot harder to do in a purely functional style, or at least it is in most opinionated functional programming implementations I’ve used, because you’re no longer “just” evaluating some expression but instead initializing state, reacting to I/O, then updating state and/or performing further I/O potentially while using parallelization to perform monitoring/listen for other things/perform further I/O and state updates. Of course it’s not impossible to do these things with Lisp but from my couple of semesters of exposure of FP in undergrad and use of FP features in C++ and Scala professionally to solve these kinds of problems… it seems quite hard to get FP to work for these applications, and that lack of suitability is what discourages me from diving more fully into FP

lukego 3y ago
I'm using Lisp for simulation. It's really wonderful being able to poke and prod long-running computations while they run. I missed this too much when I tried using Julia.
vippy 3y ago
It took me a while to grok monads, and the IO monad, and longer still to figure out how to compose them in safe ways, and manipulate execution order, etc. But: now I can write typesafe applications, and I produce fewer bugs when I work in non-FP languages (I get paid to write Java.) Lisp is a starting point. Haskell is where it's at. I recommend learning the style, even if you never produce production code in it.
- xedrac 3y ago
  Yes, Haskell is magnificent for learning FP. I used to think Haskell was terrible for IO, but my tune has changed dramatically since I started working with it full time.

xedrac 3y ago

There is something very playful about lisp that is so intriguing to me. I've come to rely heavily on powerful type systems at work (which is amazing), but lisp feels like unbounded imagination flowing at my fingertips.

dutchblacksmith 3y ago

Big fan of Lispworks (Yes, there is a free version). Using it in production, as many others. Using Quicklisp in experiments. Not direct in my codebase. Lisp will always be there. Learning Lisp will make you a better programmer, while having fun.

Roark66 3y ago

I'd be interested in if you considered Guile first and what made you decide in favor of common lisp. Few years ago when I decided its finally time to learn lisp I looked at few variants and Guile seemed to have the benefit of: fairly vibrant(but somewhat hermetic) online community, a sizable manual that describes most frequently used APIs (you can learn the language itself very quickly, but it's the knowledge of the APIs you need to do anything in the "real world"), and being actively maintained and extended. So I chose Guile. For those that don't know these terms Guile and common lisp are two implementations of the same scheme language (simplifying a lot).

schemescape 3y ago
When I looked, I got the impression that Guile didn’t run on Windows, and that’s a platform I needed to support.

massimosgrelli 3y ago

Always been fascinated by Lisp, but I never spent enough time to enjoy its elegance and applications. I went through Lurk, a Lisp dialect, a Turing-complete programming language for recursive zk-SNARKs in the last year. I started to grasp a bit of its potential in solving real-world problems, but still too little to understand why it's so right for solving some problems. I'm curious about what other projects you guys are successfully and better solving because of Lisp today.

ghfwlc 3y ago

Common Lisp is still the most pleasant REPL language. The only complaint I have is that too many function names are taken due to the large spec.

tmtvl 3y ago
It's fine, you can shadow any function you want: <https://cl-community-spec.github.io/pages/shadow.html https://cl-community-spec.github.io/pages/shadow.html>

massimosgrelli 3y ago

I'm sorry about my basic question. Back in the 80s, AI was betting on Lisp machines — https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine — now, of course obsolete. Is Lisp still relevant in the AI space?

ShamelessC 3y ago
Not really no. It’s mostly Python 3. The AI space back then had heavy emphasis on symbolic AI. Modern deep learning algorithms have very little overlap.

anonzzzies 3y ago

I love CL and I really miss it when i'm doing something else. I mean, many things are such a pain in 'modern' languages that it's not even funny, when you compare it to the Lisp experience of even decades ago. There are many cons, but those are simply not as bad as most of the pure technical language/dev env cons in almost everything else. Sure Python & JS have more uptake, more libraries etc, but the experience of developing for them is so much worse. IMHO of course. I have been doing a lot of languages over the years including C#, TS, Py, Hs and more esoteric ones, but I keep coming back to CL (SBCL + emacs + Slime) when I get seriously angry about stuff that is missing or plainly bad in those languages. It makes me relaxed and convinced there is some good in the world after all. I am currently raising for a product we (foolishly so) bootstrapped in Typescript but now we will, for a launch version, redo it in CL. Meaning I get to work with / in CL (and all of the fun stuff; implementing DSL, code generation, working with macros, implementing a static type solver etc) for the coming 3-5 years before we launch. Lovely.

pjc50 3y ago
> There are many cons Can't have Lisp without cons. (sorry) What do you miss in Lisp when working in C#?
- anonzzzies 3y ago
  I would say: 1) painless debugging with Emacs/Slime vs Rider/VS/VSCode 2) performance & consistency of it; SBCL is fast and remains that way, I can leave emacs/slime running for months and it doesn't degrade; vs/rider... they really burn a hole through my laptop and isn't even that good at most things compared, even on really old computers 3) Re-eval; you can re-eval a region, function, file, last expression etc, during running and/or debugging, which is very flexible ; something wrong, change (or write the same function next to it with a fix; very handy), re-eval and when happy , clean up and save 4) data formats... We have had, since 'forever' had 'proxy' tooling that converts any incoming and outgoing JSON to and from Lisp lists. While in code, we only work with s-expressions and it makes life so easy.
Thiez 3y ago
Why is Typescript unsuitable for the product?

katspaugh 3y ago

Kudos for the Janet shout out! It's an excellent little language, and Janet for Mortals is an excellent book to learn it. The author has a great sense of humor.

largbae 3y ago

I wonder if LLM assist tools like GitHub CoPilot will further consolidate the programming language landscape. The productivity gains from using a well-supported language might raise the barrier to entry for new or niche ones.

qwerty456127 3y ago

> It's 2023, so of course I'm learning Common Lisp So am I although none of the features mentioned seem useful to me so far (perhaps I will change my mind once I become fluent). I just hope Lisp will make it easier to express my thought in code, minimizing/abstracting all the cruft/boilerplate. To me Lisp expressions seem the most natural way of expressing a thought. As I primarily am interested in writing GUI apps I hope to master Clog or find/develop a good wrapper around some GUI toolkit.

harshaw 3y ago

as a manager type, I wish my engineers were more broadly aware of REPL style development and the massive productivity boost it can have for certain kinds of development. I am used to doing a lot of ruby/python/js in REPL, but the idea of a sort of "break into a repl and implement the missing function and continue" sounds really nifty.

omgmajk 3y ago

I am also learning common lisp in 2023, I like it!

xgdgsc 3y ago

It' s 2023. It' s time to switch [From Common Lisp to Julia](https://news.ycombinator.com/item?id=32745318 https://news.ycombinator.com/item?id=32745318)