Lapel2742

> reasoning produces way better results

I doubt the whole concept of calling it "thinking" or "reasoning". If it's automated context engineering, call it that. The bullshit is in the terms used.

> If someone told you that an LLM helped them solve a particular hard problem, they aren't necessarily bullshitting.

Yes, they clearly are not bullshitting. They would be bullshitting if they would tell me that the LLM "thinks" while helping them.

Autocompletion and inline documentation was a godsend at their time. It solved the particular hard and heavy problem of kilos of manuals. It was a technical solution to a problem just like LLMs.

Because that is not the only experience me an others have with this technology. The whole field seems to be poised by bullshitting.

Don't get me wrong, it's a fascinating and extremely dangerous technology but it's clearly over-hyped.

> hallucinated or unfaithful conclusions

Disclaimer: I’m no expert. An anecdotal example: I asked the reasoning LLM a question, and it laid out the correct answer in its thinking step, only to stop thinking and confidently give the wrong answer. That moment led me to conclude that when LLM evangelists talk about reasoning and thinking, they are essentially bullshitting.

> You believe 57 words are "each and every detail", and that "produce two full, exhaustive lists of items out of your blackbox inner conceptspace/fetch those from the web" are "extremely simple tasks"?

Sure they are. I'm not interested in how difficult this is for a LLM. This is not the question. Go out there, get the information. That this is hard for a LLM proves the point: They are surprisingly bad at some simple tasks.

> Try learning programming.

I started programming in the early 1980's.

> you are standing in front of your dishwasher waiting for it to grow arms and do your dishes in the sink.

No. I'm standing in front of the dishwasher and the dishwasher expects me to tell it in detail how to wash the dishes.

This is not about if you can find any use for a LLM at all. This is about:

> LLMs are still surprisingly bad at some simple tasks

And yes. They are bad if you have to hand feed them each and every detail for an extremely simple task like comparing two lists.

You even have to debug the result because you cannot be sure that the dishwasher really washed the dishes. Maybe it just said it did.

> This works great in Claude Sonnet 4.1: 'Please could you research a list of valid TLDs and a list of valid HTML5 elements, then cross reference them to produce a list of HTML5 elements which are also valid TLDs. Use search to find URLs to the lists, then use the analysis tool to write a script that downloads the lists, normalises and intersects them.'

Ok, I only have to:

1. Generally solve the problem for the AI

2. Make a step by step plan for the AI to execute

3. Debug the script I get back and check by hand if it uses reliable sources.

4. Run that script.

For what do I need the AI?

> No "lists" were being compared.

How would you solve that problem? You'd probably go to the internet, get the list of TLDs and the list of HTML5-Element and than compare those lists.

The author compares three commercial large‑language models that have direct internet access, but none of them appear capable of performing this seemingly simple task. I think his conclusion is valid.

Thank you. In might try it again some day.

> does atuin give me anything significant over my current fzf based C-r

I'm interested in this as well. I currently use fzf and I'm happy with what I've got (except for me syncing would probably be a nice feature to have).

Also: I gave atuin a quick try and found the TUI to be worse than fzf. Why do I need a fullscreen ctrl-r interface? I found that distracting. But maybe that is configurable. I didn't look much further.

I start paying them when they start paying me for my data.

> Does this mean that eventually in a world where we all use this stuff, no new language/framework/library will ever be able to emerge?

If you truly believe in the potential of agentic AI, then the logical conclusion is that programming languages will become the assembly languages of the 21st century. This may or may not become the unfortunate reality.

From reading the abstract.

> Compared to non-users, non-medical cannabis use was significantly associated with 96% decreased odds of SCD (aOR=0.04, 95% CI=0.01-0.44, p<.01). Medical (aOR=0.46, 95% CI=0.06-3.61, p=.46) and dual medical and non-medical use (aOR=0.30, 95% CI=0.03-2.92, p=.30) were also associated with decreased odds of SCD, although not significant.

I'm not a native speaker but if non-medical use of cannabis has a different outcome than medical and mixed use than it seems plausible that there are other - more important - factors at play or do I misunderstand the paragraph?

> Lack of access to the C libraries.

???

I recently started learning Common Lisp for fun (and fun it is!) and the ease of accessing C libraries was one of the things that surprised me in a positive way.

Using https://github.com/rpav/cl-autowrap one can simply write (c-include "file.h") and the API defined in "file.h" is accessible from Lisp. I can't think of a simpler way.

Even without cl-autowrap, FFI using https://cffi.common-lisp.dev/ seems simple enough.