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

321–330 of 346 posts

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

#321

Post by em-bee »

pjc50 wrote: post #245
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.

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)

but you wouldn't be able to use that on your production server, would you?

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

#322

Post by em-bee »

regularfry wrote: post #293
db48x wrote: post #115

Earlier quoted context omitted.

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.

The question was whether you can debug a live service while it's handling live traffic. Not whether you can fix it. Java can definitely do the former, and definitely can't do the latter.

my question specifically was which languages/runtimes allow you to actually make changes to the code in a live process without restarting it.

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

#323

Post by rwxrwxrwx »

mathisfun123 wrote: post #307
rwxrwxrwx wrote: post #282

Earlier quoted context omitted.

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.

i said ported not implemented; the likelihood that any of those libraries sprout lisp bindings is about as likely as them being rewritten in lisp. so it's the same thing and the point is clear: i don't care about some zany runtime feature, i care about the ecosystem.

Stop moving the goalposts: your answer to a commenter who stated that Common Lisp was faster than Python (a fact) was a list of packages, many of which are (1) not even written in Python and (2) some of them actually do have Common Lisp bindings.

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

#324

Post by ristos »

aidenn0 wrote: post #318
ristos wrote: post #311

Earlier quoted context omitted.

Ultralisp, Rowsell, Qlot, Quickdocs, etc. Virtually every modern project build/install instructions reference Quicklisp. You have no idea which dependencies you need to pull and from where, which can be a real PITA for a large project. A lot of project code I've looked at also has Quicklisp references in the actual code for whatever reason, usually for testing or building or whatever else, so to run those you need Qu…

Before QL, you looked at the .asd and searched cliki for each name. You can still do that if you like (and can use Google as well). Sometimes the readme had better instructions, but often they didn't work. In fact, each project in the QL repository includes a link to upstream, so you can use that to find your sources if you like I literally once rewrote the 20% of a library that I personally needed because it was fas…

> Before QL, you looked at the .asd and searched cliki for each name.

Only very few libraries are on Cliki, and the links "upstream" just link to the repo that almost always says to just use Quicklisp for installation. Quicklisp has a quicklisp-projects repo where the project sources are all in one place, but it's not very helpful for what I've been talking about.

> Your original comment reads like there used to be all these awesome package managers

Sorry I don't want to engage with flamebait... I commented on this thread to raise awareness for issues and interesting things that I think people here might find useful, because there's still a lot of interest in lisp.

If you really think I'm wrong, do a writeup and share it on HN with everyone. You can go to the awesome-cl repo to find the most popular libraries in the ecosystem, and show how easy it is to avoid using Quicklisp to install/build/find the deps/run tests for all those repos. It would really help and I think it would save a lot of people time. For something like the Nodejs ecosystem, for example, such a writeup would probably only take like an hour tops because of the maturity of the npm package manager.

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

#325

Post by SanderNL »

freilanzer wrote: post #295
SanderNL wrote: post #263

Earlier quoted context omitted.

Given the myriad other variables that go into a successful software business, the choice of stack and its various modes of expressing whatever transformation on whatever data it is you are mangling is so exceedingly minor a consideration that I'm close to experiencing it as professional negligence to even fuss over it to the degree it is being fussed over by many people. I'm not dissing Lisp by any means by the way.

I understand your point and it's quite true - but hard problems require adequate tools and I wouldn't choose Java, for example, non-crud stuff.

You would never program Minecraft in it, right?

Probably for the best, but you can and he did and it’ll make you a billionaire all the same.

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

#326

Post by pjmlp »

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…

You can kind of do the same as DISASSEMBLE in Clojure.

There are some helper projects like https://github.com/Bronsa/tools.decompiler, and on the OpenJDK JitWatch (https://github.com/AdoptOpenJDK/jitwatch), other JVMs have similar tools as well.

It isn't as straightforward as in Lisp, but it is nonetheless doable.

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

#327

Post by SanderNL »

Sterm wrote: post #309
SanderNL wrote: post #251

Earlier quoted context omitted.

That's not a good faith interpretation given the near infinite amount of options for conjuring up your favourite moneyprinting system of choice besides "machine code". SBCL is about the most arcane option you can pick and even that can work, which I think actually proves the point: it doesn't matter to any significant degree (anymore).

How else is one meant to read that language doesn't matter? You can hook into anything that runs in Linux since it's abi is rock solid so the excuse of not being able to use the usual tech stacks doesn't hold water either.

You can use RoR, .NET, SBCL, Python, Erlang and 6502 assembly if you so desire. Sure “machine code” is one option, but that doesn’t engage with the argument in any meaningful way IMO.

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

#328

Post by kazinator »

mathisfun123 wrote: post #175
_19qg wrote: 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?

This is not necessarily the case.

Firstly, functions that are in the same compilation unit that refer to each other can use a faster mechanism, not going through a symbol. The same applies to lexical functions. Lisp compilers support inlining, and the spec allows automatic inlining between functions in the same compilation unit, and it allows calls to be less dynamic and m more optimized. If f and g are in the same file, where g calls f, then implementations are not required to allow f and go to be separately redefinable. So that is to say, if f is redefined only, the existing g may keep calling the old f. The intent is that redefinition has the granularity of compiled files: if a new version of the entire compiled file is loaded, then f and g get redefined together and all is cool.

Lisp symbol lookup takes place at read time. If we are calling some function foo and have to go through the symbol (it's in another compilation unit), there is no hashing of the string "foo" going on at call time. The calling code hangs on to the foo symbol, which is an object. The hashing is done when the caller is loaded. The caller's compiled file contains literal objects, some of which are symbols. A compiled file on disk records externalized images of symbols which have the textual names; when those are internalized again, they become objects.

The "classic" Lisp approach for implementing a global function binding of a symbol is be to have dedicated "function cell" field in the symbol itself. So, the compiled module from which the call is emanating is hanging on to the foo symbol as static data, and that symbol has a field in it (at a fixed offset) from which it can pull the current function object in order to call it (or use it indirectly).

Cross-module Lisp calls have overhead due to the dynamism; that's a fact of life. You don't get safety for nothing.

(Yes, yes, you can name ten "Lisp" implementations which do a hashed lookup on a string every time a function is called, I know.)

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

#329

Post by kazinator »

sireat wrote: post #159
lispm wrote: post #156

Earlier quoted context omitted.

How does it look like in Python? In Lisp: CL-USER 43 > (+ 1 (foo 20)) Error: Undefined operator FOO in form (FOO 20). 1 (continue) Try invoking FOO again. 2 Return some values from the form (FOO 20). 3 Try invoking something other than FOO with the same arguments. 4 Set the symbol-function of FOO to another function. 5 Set the macro-function of FOO to another function. 6 (abort) Return to top loop level 0. Type :b fo…

Hmm, what advantage does Lisp offer here over Python? >>> 1 + foo(20) Traceback (most recent call last): File " ", line 1, in NameError: name 'foo' is not defined >>> def foo(a): ... return a + 21 File " ", line 2 return a + 21 ^ IndentationError: expected an indented block >>> def foo(a): ... return a + 21 ... >>> 1 + foo(20) 42 >>> Mind the hilarious indentation error, as I had not touched the old-school REPL in ag…

The advantage is that Python has just diagnosed the error and aborted the whole thing back to the top level, whereas in the Common Lisp, the entire context where the error happened is still standing. There are things you can do like interactive replace a bad value with a good value and re-try the failed computation.

In lispm's example, the problem is that there is no foo function, so (foo 20) cannot be evaluated. You have various choices at the debugger prompt; you can specify a different function, to which the same arguments will be applied. Or just specify a value to be used in place of the nonworking function call.

Being able to fix and re-try a failed expression could be valuable if you have a large running system with hundreds of megabytes or even gigabytes of data in the image, which took a long time to get to that state.

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

#330

Post by [deleted] »

mathisfun123 wrote: post #198
lispm wrote: 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…

[deleted]
Post reply on HN