Live data from Hacker News

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

log.schemescape.com

211–220 of 346 posts

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

#211

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

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.

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

#212
post #168

Earlier quoted context omitted.

Common Lisp programs run by default in a way that calls to undefined functions are detected. Here the Lisp simply tries to look up the function object from the symbol. There is no function, so it signals a condition (aka exception). The default exception handler gets called (without unwinding the stack). This handler prints the restarts and calls another REPL. I define the function -> the symbol now has a function de…

>Common Lisp programs run by default in a way that calls to undefined functions are detected. Cool so what you're telling me is that by default every single function call incurs the unavoidable overhead of indirecting through some lookup for a function bound to a symbol. And you're proud of this?

Do you think Python or Ruby or PHP are any different? And yet, not one of them actually chose to use this in a sane way, where a simple lookup error doesn't have to crash the whole program.

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

#213
post #115
post #88

Earlier quoted context omitted.

Java supports live debugging and profiling.

But that’s not the same thing at all. If you’re debugging an exception in Java, you cannot continue execution as if the exception had not been thrown at all. With Common Lisp’s condition system you can.

Umm.. you can throw an exception, you can return to previous call frame, you can reload modified classes. If you want unlimited code modification, you can use dcevm https://github.com/dcevm/dcevm

https://www.jetbrains.com/help/idea/altering-the-program-s-e...

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

#214
post #186

Earlier quoted context omitted.

I thought you know Lisp? Now you are surprised that Lisp often looks up functions via symbols -> aka "late binding"? How can that be? That's one of the basic Lisp features. Next you can find out what optimizing compilers do to avoid it, where possible or where wanted.

At no point in time did I claim to know lisp well. I stated my familiarity at the outset. But what you all did was claim to know a lot about every other interpreted runtime without a grain of salt. >Next you can find out what optimizing compilers do to avoid it, where possible or where wanted. But compilers I am an expert in and what you're implying is impossible - either you have dynamic linkage, which means symbol…

What you're missing is that, unlike any other commonly used language runtime, compilation in CL is not all-or-nothing, nor is it left solely to the runtime to decide which to use. A CL program can very well have a mix of interpreted functions and compiled functions, and use late or eager binding based on that. This is mostly up to the programmer to decide, by using declarations to control how, when, and if compilation should happen.

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

#216
post #87

Earlier quoted context omitted.

Isn't all this stuff a vector for malicious code and security vulnerabilities in production ?

No.

Can you explain why this is not ? Code injection in production environments is generally considered an easy attack vector. Lots of CVE's around this in other language SDK's that have been ironed out over the last decade and half. I don't think Common Lisp gets "special protection" here or does it ?

Unless you are restricting this to only development in which case there are a lot more languages other than common lisp that support hot-reloading/re-definition.

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

#217
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).

That is a typical consumerism: "Give me everything ready to use and then I'll use it."

How about bringing some value to the community?

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

#218

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.

I think the times when your tech stacks mattered in the slightest are mostly behind us.

Also: it's good you concocted some arcane shit that works like a charm, but now nobody - except the ones whose pay you express in number of zeroes - is touching it.

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

#219
post #207

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

> There are many cons Can't have Lisp without cons. (sorry) What do you miss in Lisp when working in C#?

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.

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

#220
post #74

Earlier quoted context omitted.

The repls you mention are not like lisp repls. You're being downvoted because your comment makes it sound like you've never programmed a lisp but have strong opinions nonetheless.

Not the OP but would somebody be able to summarize HOW are the lisp REPLs different then to me? I've written limited amount of clojure and common lisp just to play around and I don't recall any difference between Clojure REPL and the REPL I get for say Kotlin inside IntelliJ idea. Maybe the ability to send expression from the IDE into the REPL with one keybind but I cannot say it's not possible with the Kotlin one ri…

Watch this video on Lisp interactive development approach. I've recorded it especially to answer the question:

https://www.youtube.com/watch?v=JklkKkqSg4c

Post reply on HN