I don't claim to know the context in which that AI slop communication happens. But when people are really interested in what you ask them, they usually give their own opinions in their own voice.
I don't know much about curmudgeons, but perhaps there might be a group on HN who downvote just to perform their curmudgeon act. They exploit HN's rules to stay invisible and undetected.
As a non-native speaker, I cope with language barriers. To overcome those barriers, it is tempting to use an LLM to help you with unknown words or expressions.
But the use of LLMs may change your original intention. The LLM may flatten, cut corners, or expand what you did not want expanded. Hence, the focus of the message and the spark in the original thought are both destroyed. It is saddening to be linguistically limited. LLMs help bridge the gap, but you have to fight to keep your own identity alive.
Since you are also commenting libraries, I think that FSet (1) for inmutable memory,and perhaps a comparison with clojure, and the quick-lisp package manager could be mentioned.
The page indicates that there is not function for documentation in common lisp, but
(documentation 'documentation 'function)
"Return the documentation string of Doc-Type for X, or NIL if none
exists.
System doc-types are VARIABLE, FUNCTION, STRUCTURE, TYPE, SETF, and T.
Also http://rosettacode.org for computer tasks implemented in many computer languages to allow you compare syntax and code.
I know that the purpose of the page is to compare syntax of common lisp, racket, clojure, and emacs lisp.
But some examples could be more idiomatic, for instance instead of
(defun add (a &rest b)
(if (null b)
a
(+ a (eval (cons '+ b)))))
One should avoid eval and use endp instead of null:
(defun add (a &rest b)
(if (endp b) a
(apply #'add (+ a (first b)) (rest b))))
The use of cl:eval alone is enough to make me believe that the CL column was never reviewed by an experienced CL programmer. I am now more suspicious of the other columns, which are languages I'm far less familiar with.
> I am now more suspicious of the other columns, which are languages I'm far less familiar with.
It's not bad but for Clojure for example it says "nil is like null in Java" but null in Java is not falsy.
And it also says that destructuring is "named parameters" but it's not so: it's just destructuring (and there are two examples of destructuring given: one for the "named parameters" which aren't named parameters, and one for "parallel assignment" of local variables).
Nothing bad but it's not possible to go into much details in such a table.
Almost. It should be (+ a (apply #'+ b)). Common Lisp is a Lisp-2, so a + in the argument position is assumed to be a variable named +, not the function named +, unless you specify otherwise.
No, the idea is to assume for this example that + only can be used with two arguments and define a new function that can be used with any number of arguments.
All major Common Lisps support tail call optimization with proper declarations, with the exception of ABCL because it runs on the JVM.
And those declarations are all identical or almost identical, so it's easy to write an implementation-specific macro to guarantee TCO if you need to do so.
Some algorithms are easiest to express and read with looping constructs. For those algorithms, use looping constructs. Other algorithms are easiest to express and read with recursion. For those, use recursion. You shouldn't be afraid of recursion just because ANSI doesn't say TCO is guaranteed. You should be afraid of it if your code needs to run on ABCL, but otherwise, recur on.
I think it is fair to say that the CL community is divided on whether or not relying on TCO is idiomatic.
I prefer to write my state-machines as transitioning with tail-calls, and I do get called for it. It's relatively easy to switch something written in that manner to using a loop with a trampoline, so I do so when my collaborators request it.
I wouldn't argue about things that are a matter of taste normally, except that I've had the experience where I've turned down optimizer settings in order to debug some code better and then the had stack overflow.
Sigh and yet it continues to be true. You can make a pragmatic decision and rely on tail call optimisation for your specific case, but if you are writing a CL library, then it is not idiomatic to use recursion in the same way that you would for Clojure or Scheme.
Even with SBCL, for example, it doesn't have tail-call optimisation for all architectures at all optimisation levels.
Thanks, very good explanation. One question: One could mix both kind of policies, are there hybrid policies? (with samples both from the inner and outer distributions?), if so, how are they named?
Policies are not of two types. There is just _a_ policy. On- and off- policy are properties of the training process. If you learn a policy using data which was generated using another policy, it is off-policy. If the data was generated using the same policy, it is on-policy. The distinction matters because (very loosely) the nudges that the other policy's data tell you to make are based on the other policy's existing shape, which might be different from your current policy's shape. Typically, an algorithm itself is called off-policy if it does not care about the source of the data. Example: Q-learning. An algorithm is called on-policy if it requires the source of the data to be the policy itself. In practice, you always use a mixture of both, and apply techniques such as importance sampling to mitigate the off-policy data mismatch.
To answer your question, yes, you can use any mixture of data for your training process. Whenever you use off-policy data, depending on your objective, you might have to use some technique to "fix" your updates.
Just an anecdote: I was designing a project for LLMs onboarding and orchestration. Claude chose to read only the first 40 lines of each file. Later, in another session, looking for causes of low quality result, Claude detected the fault and changed the code to perform an AST analysis, so now the analyzer takes documentation lines and functions signature (input/output) as input.
Claude's initial approach was really poor.
One has to wonder how many times Claude code has to be modified/reviewed for improvement, or whether it is possible at all to make good code with it.
Edited: Generalization:
Claude can fix a localized, identifiable poor decision (e.g., "only reading first 40 lines") because the fault is discrete and traceable to one piece of code.
But real software quality problems often arise from many small, individually reasonable decisions that collectively produce bad outcomes. No single one is obviously "the fault." In that scenario, a tool that generates low-quality building blocks piecemeal may never converge on good code, because each piece seems fine in isolation.
I think it's taught to look at source code through a peephole for the sake of context preservation, but I feel like this could be a good use-case for some sub-logic or even a full sub-agent. Like, here sub-agent, you skim that file and tell me a summary, and highlight any areas related to X and Y so that I can look at them in my main context. You can also periodically observe the main work stream and interrupt me if you realise that something in the file you're thinking about is relevant to what I'm working on or might change the direction of what I'm doing.
I think what you suggest is like a local second order approximation, that can help. But, I think that the real problem is a global one, is about architectural taste, how the many local pieces interact and their friction. Currently that demands human expertize.
> I think it's taught to look at source code through a peephole for the sake of context preservation
Yes, to a (real) fault. Less than one in fifty times it ignores an instruction or piece of data in a file has it seen the instruction or data before ignoring it. The other times, it's done this sampling nonsense.
Results are night and day using the 1M token models and reading the full files.
The irony is that as marketing automation becomes 'complete', its effectiveness drops to zero because everyone is using it. When everyone has an AI SDR, no one answers their email. The only thing AI can't automate is the proof of work: the real relationships and the reputation that makes a customer believe you’ll still be around in six months.
Anyway, to answer your question: Autonomous Multi-Channel Agents (e.g., Emma, AgentsVerse) are close to what you asked for. They don't just draft posts; they identify "just-funded" leads, scrape LinkedIn, and run autonomous ad optimizations.
Edited: Just to clarify, I mentioned Emma and AgentsVerse as examples of where marketing automation is heading, not tools I've personally vetted for the specific capabilities listed.
reply