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?
It's 2023, so of course I'm learning Common Lisp
211–220 of 346 posts
Re: It's 2023, so of course I'm learning Common Lisp
#212Earlier 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?
Re: It's 2023, so of course I'm learning Common Lisp
#213Earlier 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.
https://www.jetbrains.com/help/idea/altering-the-program-s-e...
Re: It's 2023, so of course I'm learning Common Lisp
#214Earlier 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…
Re: It's 2023, so of course I'm learning Common Lisp
#215It's an excellent little language, and Janet for Mortals is an excellent book to learn it. The author has a great sense of humor.
Re: It's 2023, so of course I'm learning Common Lisp
#216Earlier quoted context omitted.
Isn't all this stuff a vector for malicious code and security vulnerabilities in production ?
No.
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
#217Earlier 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).
How about bringing some value to the community?
Re: It's 2023, so of course I'm learning Common Lisp
#218Steel 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.
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
#219I 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#?
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
#220Earlier 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…