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

241–250 of 346 posts

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

#241

Post by jabradoodle »

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…

I don't think either language offers a way to send a form to the repl, that is a function of the tooling.

This is certainly easy to do with Cider and I imagine the main tooling in other editors is equally competent.

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

#242

Post by realharo »

ColonelPhantom wrote: post #231
TheOtherHobbes wrote: post #224

Earlier quoted context omitted.

LISP continues to be a very interesting language. But REPL development is a mixed blessing. There are many situations where you want to start from a blank slate with no previous state. LISP would be a more practical language if it included a trivial option to make that possible.

In that case, can't you just restart the REPL? Or give the program a main function that you run?

Won't you also be more likely to write code based on data that you happen to have in the current situation, but not for data that covers every situation?

E.g. code that accesses an optional property as if it was always present, because it happens to be present when you're writng the code, etc.

That seems like a possible pitfall when relying on a REPL heavily, but I haven't used such a language myself, so can't speak from experience.

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

#243

Post by em-bee »

dleslie wrote: post #135
em-bee wrote: post #47

Earlier quoted context omitted.

examples please, because so far i have only seen this from common lisp and smalltalk. there is also pike where i can reload classes or objects at runtime, thus avoiding a full restart, but it's not as closely integrated as in smalltalk and you actually have to build your app in a way that allows you to do that.

JavaScript immediately comes to mind.

how do you do it? in the browsers debugger? maybe, but that is not integrated with your actual source files, so you have to be careful to track your changes and copy them to your source. that may help in some cases but isn't really practical.

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

#244

Post by pjc50 »

db48x wrote: post #64
tikhonj wrote: post #28

Earlier quoted context omitted.

Because language popularity is, at best, loosely correlated with any intrinsic qualities of the language itself.

See also advertising. C++ and Java had enormous advertising budgets, while Common Lisp had virtually none. For years, virtually every programming book and magazine was touting C++ and then later Java. Every conference, every keynote, everything a CTO might ever read or notice was telling them to use C++ or Java.

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.

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

#245

Post by pjc50 »

em-bee wrote: post #47
dleslie wrote: post #41

Earlier quoted context omitted.

Lots of languages that are not lisp have this ability.

examples please, because so far i have only seen this from common lisp and smalltalk. there is also pike where i can reload classes or objects at runtime, thus avoiding a full restart, but it's not as closely integrated as in smalltalk and you actually have to build your app in a way that allows you to do that.

It's not always usable, but Visual Studio offers this for C# (works most of the time) or C++ (works in fewer cases because of the terrible header model)

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

#246

Post by nmlrpzt »

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…

As others here, I don't understand how those features (seamless continuation of a program with the exact state) could possibly work in Python.

What I do know is that the Python community has a propensity for claiming that approximations of complex features by gigantic hacks work and are sound, while they are not.

The Python community also has an extreme tolerance for unsound and buggy software that is propped up by censoring those who complain. Occasional complaints are offset by happy (and selected) marketing talks at your nearest PyCon.

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

#247

Post by nmlrpzt »

mathisfun123 wrote: post #173
lispm wrote: post #171

Earlier quoted context omitted.

This works in compiled Lisp code.

It works in code compiled from c++ too: define and associate a signal handler for sigkill, call a function whose symbol can't be runtime resolved by the linker, sigkill is sent and caught, define your function (in your asm dejure), patch the GOT to point from the original symbol to wherever the bytearray is with your asm, and voila. I'll say it again: what exactly do you think your magical lisp is doing that defies t…

So you update a single function without updating the global state, using a vile hack. In CL the entire state is saved.

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

#249

Post by harshaw »

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.

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

#250

Post by netbioserror »

temporallobe wrote: post #32

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.

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.
Post reply on HN