Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

log.schemescape.com

Post reply on HN
Print view View original

281–290 of 346 posts

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

#281

Post by vindarel »

peanutz454 wrote: post #12
nine_k wrote: post #4

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.

This sounds so amazing, why is Common Lisp not the most popular language out there? (asking as someone who almost never writes code)

Only five years ago, CL's web presence was not attractive. This included "official" websites and online documentation (despite all the great books). It's better now (common-lisp.net was reshaped, there's lisp-lang.org, a better Cookbook, the CL Community Spec, more YT tutorials…)

there is no full-featured web framework (although you can write web apps of course),

no satisfactory GUI lib (now Gtk4, Qt5 (hard to install), IUP, nice-looking Tk themes, more low-level bindings to graphics libraries etc)

the package manager came late,

good open-source compilers came late,

less choice in editors (now many https://lispcookbook.github.io/cl-cookbook/editor-support.ht...),

and, well, lots of FUD and a language not for everyone.

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

#282

Post by rwxrwxrwx »

mathisfun123 wrote: post #190
ghfwlc wrote: post #183

Earlier quoted context omitted.

Compared to Python, Common Lisp hardly has any performance issues.

Okay well when pytorch, tensorflow, pandas, Django, flask, numpy, networks, script, xgboost, matplotlib, spacy, scrapy, selenium get ported to lisp, I'll consider switching (only consider though since the are probably at least another 20 python python packages that I couldn't do my job without).

For the sake of anyone reading this thread who isn't in the know: many of these libraries are really written in C/C++ and have Python bindings.

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

#283

Post by LispSporks22 »

mathisfun123 wrote: post #148
vkazanov wrote: post #143

Earlier quoted context omitted.

The answer to all these things should be "just doesn't work in practise", not for real programs anyways. Unlike Lisp, Python doesn't lean itself well to this mode of development. Primitive CLI-like tinkering, figuring out language features, calc-like usage - maybe. But not a single time in 15 years of doing Python across the industry I saw anybody using these features for serious program development, or live coding,…

>Primitive CLI-like tinkering, figuring out language features, calc-like usage - maybe. But not a single time in 15 years of doing Python across the industry I saw anybody using these features for serious program development, or live coding, or REPL-driven development. I swear you people are like ostriches in the sand over this - Django, pytest, fastapi, pytorch, Jax, all use these features and more. I work on DL com…

I think in just about every response you left in these threads, you misunderstood what was being said. Possibly through impatience, or just plain arrogance. I really encourage you to spend some time trying to understand how interactivity/restartability (as in Lisp restarts, not process restarts) is built into the language. Especially if you're specializing in the compilers of dynamic languages.

You might also check out Smalltalk, which has a similar level of dynamism.

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

#284

Post by rmckayfleming »

maxwelljoslyn wrote: post #103
koito17 wrote: post #25

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- to copy it to my REPL is much nicer than what Clojure offers (tap>, which I consider a glorified pretty…

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 SYSTE…

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.

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

#285

Post by rmckayfleming »

rmckayfleming wrote: post #284
maxwelljoslyn wrote: post #103

Earlier quoted context omitted.

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 SYSTE…

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.

CL is the x86 of the Lisps. Successful because of backwards compatibility, but also ugly because of it.

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

#286

Post by schemescape »

bbbobbb wrote: post #280
svetlyak40wt wrote: post #220

Earlier quoted context omitted.

Watch this video on Lisp interactive development approach. I've recorded it especially to answer the question: https://www.youtube.com/watch?v=JklkKkqSg4c

Thanks, I forgot about this aspect of live program editing. Whether or not it's possible (or how close just quick live reload) is to this it' definitely not a first class citizen like you presented. It also reminds me of Pharo (or maybe just smalltalk, I've only played with Pharo) where you build the program incrementally "inside out". It does make me wonder how aplicable this way of programming is to what I do at wo…

Yes, Smalltalk/Pharo also support this.

Being able to interactively update code in response to an error, without leaving the error context and being able to restart stack frames (not just a “catch” or top level, as in most languages) is one of the key features that makes REPL-driven development possible. Or at least that’s how I see it.

It’s not something you always need to use, but it can be handy, especially for prototyping and validating fixes.

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

#287

Post by pjc50 »

db48x wrote: post #265
pjc50 wrote: post #244

Earlier quoted context omitted.

C++ itself never had a marketing budget! The nearest you might find is marketing for implementations back when people paid for programming languages, but the only surviving one of those is really Visual Studio. Lisp has had decades to break out of its niche if it delivered a really advantageous solution, but somehow that never happened.

Yes, and whose advertisements do you think show up in every single one of those magazines? Which implementations get mentioned by every single C++ book? Which organization sponsored every single C++ conference? Don’t forget that they had stiff competition from the advertising budgets of other large companies, such as Oracle and IBM. Also, don’t forget that Lisp machines were once the most coveted development machines…

> But Symbolics had to develop not only the language and IDE, but also the OS, the hardware, the microcode, and everything else all at once

This was forty years ago. Doing LISP advocacy like this just makes people sound like they're that Japanese guy who refused to surrender until the 1970s. The world has moved on; there have been other opportunities; and LISP has not won them either.

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

#288

Post by LispSporks22 »

chlorion wrote: post #65
schemescape wrote: post #21

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 exam…

I have some cons! Last time I checked on it, QuickLisp doesn't support fetching packages over anything except for plain http, with no encryption and no verification mechanism in place to detect files that may have been tampered with during transmission. I think not supporting encryption or authentication for something as important as fetching source code makes QL a non-starter for me and hopefully for anyone else who…

> Last time I checked on it, QuickLisp doesn't support fetching packages over anything except for plain http, with no encryption and no verification mechanism in place to detect files that may have been tampered with during transmission.

I know it's not an excuse, but it was fun as heck booting up "capital M" MacOS (9.2.1) and loading Quicklisp into MCL without any trouble. I'm not even sure that's a supported platform by Quicklisp. https://code.google.com/archive/p/mcl/

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

#289

Post by baq »

schemescape wrote: post #93
mrcode007 wrote: post #83

Earlier quoted context omitted.

SBCL supports static builds by saving core with runtime into an executable file you can then copy around at will.

Do they work across glibc verisons or musl libc? My understanding is that they do not.

If you link against an old version, it'll generally work with a newer one.

Old versions are unfortunately not always compatible with new libraries...

Post reply on HN