you don't need to call eval for the usual config file setup, only read.

(but you often get something much better when config files are plain lisp code; i.e. they are eval'ed, assuming that the threat model allows it)

this assumes that greatness is a single dimension, and namely, popularity.

yes. and as a long time lisper, i don't think that it's the macros.

i think lisp's magic is a lot more cultural than most people think. i.e. how lispnicks implement lisps and the ecosystem around it. how easy it is to walk the entire ladder of abstractions from machine code to project specific DSL's. how pluggable its parsing pipeline is -- something that is not even exposed in most languages, let alone customizable.

the language, the foundation, of course matters. but i think to a lesser extent than what people think. (hence the trend of trying to hire lispnicks to hard, but non-lisp positions?)

and it's not even an obviously good culture... (just how abrasive common lispers are? need to have a thick skin if you ask a stupid question... or that grumpy, pervasive spirit of the lone wolf...?)

maybe it's just a peculiar filter that gets together peculiar people who think and write code in peculiar ways.

maybe it's not the macros, but the patterns in personality traits of the people who end up at lisp?

does OP mean simply the identity of the message?

idempotency means something else to me.

"Idempotency key" is a widely accepted term [1] for this concept; arguably, you could call it "Deduplication key" instead, but I think this ship has sailed.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

I agree, this whole thread seems to turn the concept of idempotency on its head. As far as I know, an idempotent operation is one that can be repeated without ill-effect rather than the opposite which is a process that will cause errors if executed repeatedly.

The article doesn't propose anything especially different from Lamport clocks. What this article suggests is a way to deal with non-idempotent message handlers.

I'm not sure I follow, though I agree with your definition of idempotency I think ensuring idempotency on the receiving side is sometimes impossible without recognizing that you are receiving an already processed message, in other words: you recognize that you have already received the incoming message and don't process it, in other words: you can tell that this message is the same as an earlier one, in other words: the identity of the message corresponds to the identity of an earlier message.

Its true that idempotency can sometimes be achieved without explicitly having message identity, but in cases it cannot, a key is usually provided to solve this problem. This key indeed encodes the identity of the message, but is usually called an "idempotency key" to signal its use.

The system then becomes idempotent not by having repeated executions result in identical state on some deeper level, but by detecting and avoiding repeated executions on the surface of the system.

We are saying the same thing using different words. I view this as a strategy for dealing with a lack of idempotency in handlers with a great deal of overhead. So I guess I would call it a non-idempotency key since a handler that is not idempotent will necessarily use it. I think this strays too close to a contradiction in terms.

Maybe this is a mismatch of expectations, but I generally think very few handlers are idempotent without such a key. E.g any edits or soft-deleted are impossible to handle in an idempotent way without auxiliary information (idempotency key or timestamp or sequence number).

Again stopping the execution of the handler based on an ID is not idempotency, but rather a corrective measure due to the fact that the handler is not idempotent. Idempotency is a property that says the handler can run as many times as I like, as diametrically opposed to the notion that it can run only once.

that in itself could be healthy user bias (if a healthier subset was taking up the vaccine).

did they control for that?

Its a cohort study, so you can only control for confounders. The 2nd paragraph of the discussion addresses the healthy-vaccinee effect you're referring to.

plus that would also mean less incentives to upload personal data to their servers...

to share your location with trusted people when e.g. you are in a dangerous situation.

or to set up a timed SOS signal if you don't disarm it within a given deadline.

i'm a long time lisper, but i don't think this is justified.

implementing prolog/backtracking on top of lisp is certainly possible and not even too hard (see e.g. https://github.com/nikodemus/screamer)

and implementing Coq on top of lisp is also possible.

but IMO the "with ease" phrase is not justified in this context.

if you only mean that lisp will not be in the way if you set out to implement these, then i agree. lisp -- the language and the typical opensource implementation -- will be much less of an obstacle than other languages when chosen as foundations.

is it far fetched to consider that maybe the entire point of Roblox is to be an infamous pedo hunting ground... and as such serve as one of the reasons for ushering in mandatory digital IDs for going online?

it wouldn't be the ugliest problem-reaction-solution history has seen...