The problem to me is that the Reals which aren't computable are absurd. We've never used any of them in all history. We can only put names on a very special few, those are countable, and we don't even know their value very well.

And the main way we prove that the Reals are uncountable is to use a proof by contradiction. It would take too long to spell it out, but they aren't really just contradicting "Reals are Countable". It's "All that other stuff we think is true AND Reals are Countable" that gets contradicted.

Once you accept the Reals, the Axiom of Choice is not simply obvious any more. And if you go down that path you get things like the Banach-Tarski paradox. To me THAT ought to be a proof by contradiction that we've made a mistake somewhere.

More interesting than that though: If the universe we live in requires non-computable Reals to describe it carefully, then it says something very weird about determinism. In order to compute a future state of a system, we need to use numbers we can't compute?!?

:-)

I asked a question about a series of tokens - bam, denied and downgraded. There's no cyber security or public risk here, but Fable doesn't want me to learn how things work.

I asked a question about quantization in models - bam, denied and downgraded. I edit my question to make it clear I'm talking about Google's Gemma QAT models. Oh, that's fine then, and it answered the question helpfully.

Anti-competitive bullshit. I hope they fail.

However, I thought things like Chaitin's Constants (you could make one per programming language) are real numbers you can name but not compute. I think you could do this from any undecidable problem.

Of course there only a countable number of those Reals. And they still don't seem useful for much more than naval gazing.

See Karpathy's "Cognitive Core" idea. (I don't have a good link)

Amusingly, a friend had Claude write some BrainF*ck the other day. Non-trivial algorithm, and it made working code on the first try.

> reduces it down to its minimum entropy -- it cannot be compressed further.

I think you could make a lot more money elsewhere :-)

https://en.wikipedia.org/wiki/Kolmogorov_complexity#Formal_p...

I completely agree. Nothing says humans need to read in exactly the syntax the model wrote. We could give the model a typed lisp, or forth, or rebol, or whatever works best, and it could be formatted into LaTeX with infix operators for the humans.

This was true before LLMs though. So many people love curlies or love indentation, love 2 spaces or 4 spaces. Programmers have been married to text files as the authoritative source, using grep to search, patches to update. The expressions could be rows in a database. Then finding and formatting are done as views from that.

> I know quite a few non-technical people that started vibe-coding this year and got good results for their ideas.

Me too, but a few of them hit limits. A couple months ago, I'd say vibe coding fell apart at 2k loc or something. It goes further now, but I think it's fragile after you take the "one shot prompt" and try to make significant changes once the pattern is set. There's probably a way to push these limits much further out so that non-programmers can do more, focusing on what they care about, and not bogged down in programming details they don't.

Maybe these well known cases could be hidden in the API, but it's easy to come up with other examples. I forget what Clojure calls it, but they have some notion about things where they're mutable during "birth" and then locked down.

Someone smarter than me knows how to do this right.

I wish we had a language that was targeted specifically for LLMs to write and humans and LLMs to inspect:

- Simple robust syntax

- One obvious way to do things

- Static type checking

- Purely functional encouraged, escape hatches for performance

- Inspect-able, testable, and reviewable in small pieces

- Something like formal predicates, preconditions, post-conditions, assertions, or effects typing

Giving LLMs all the surface area of Python, JavaScript, TypeScript, or C++ seems like a huge mistake. It's amazing it works as well as it does. Well written Haskell is beautiful, but there are way too many ways to write Haskell:

https://people.willamette.edu/~fruehr/haskell/evolution.html

I'm a programming languages nerd. I was paid to program in over 20 different languages over my 25 year career. I read up on many more languages along the way, and I wrote pet projects in a few of those. I've written a couple assemblers, compilers, and interpreters for my own languages.

I think literally everyone should be taught to program in elementary school. It's arguably one of the best ways to teach logical thought and careful organization of ideas. I like Alan Perlis's quote: You think you know when you can learn, are more sure when you can write, even more when you can teach, but certain when you can program.

With all of that out of the way, I think there are interesting questions to ask going forward:

If you were starting a business for a great software idea, with your own savings on the line, would you hire 10 AI hostile programmers to implement the idea or 2 AI friendly people and get them some subscriptions to the top models? Remember: if it doesn't come together, it's YOUR money on the line.

What are the best programming languages for LLMs to program with? Could someone design a better language that fits their strengths and weaknesses? I think the most popular human languages have way too much affordance for concerns that don't apply to models. I think letting LLMs program in human friendly languages makes the results more difficult for humans to inspect. There's a slight chicken and egg problem based on the training sets used by large models, but this can be addressed with LoRA tuning and similar techniques for open weight models.

How can we make LLMs scale better so that people who don't like to program can get better "vibe coding" results? Tools like Excel are huge force multipliers for so many people who aren't interested in writing traditional code. I think it should be possible for non-programmers to solve their own problems and trust the results without becoming programmers.

Anyways, I've got my own partially formed answers to those questions, but I'd like to hear what other people who aren't still suffering stages of LLM programming grief have to say and ask.

Most of that paragraph is objectively false:

    fn main() {
        let i = 1;
        let j = 1;
        print!("i: {:?}\n", !i);
        print!("j: {:?}\n", !j);

        // spooky action at a distance
        let v = vec![1, 2, 3];
        v[i];
    }

I remember a story about people who stutter not stuttering while singing.

The SVD staying in Reals when you have Real data is a nice feature.

Metaphors are good as a pedagogical tool for explaining topics where you're an expert and are (within reason) certain the parallel conclusion is valid. This can bridge the gap for students.

In other situations, they're a terrible argument strategy or manipulative rhetorical tactic, and the reader or listener should question every single detail if they bother to entertain it at all.

Are LLMs really like drugs that might hospitalize you? Is the government actually concerned about the well being of the people? Can you regulate LLMs as the FDA does pharmaceuticals given that they're trivially copied as files from other countries?

So what are the current leaders in the field supposed to do to stave off competition? They should convince the public that they do have a doomsday device, claim it must be regulated, and then they can profit from their duopoly because it's exceedingly expensive to break into the high end of the market. The government has its own nefarious incentives, not limited to collecting fees and using the unrestricted versions for surveillance or black hat stuff.

Bah, I think this debate was already old when I first saw people arguing it on comp.lang.lisp in the 90s. I don't have a dog in this fight other than to reject the notion that Common Lisp is "coherent" and not "organically grown".

The original Scheme belongs in the category of languages like Standard ML and SmallTalk, where a small, careful, and talented group designed them with focus. Common Lisp seems like a bunch of smart people with competing interest and legacy baselines tried to meet in the middle. To the extent CL is more pragmatic, it's another example of "Worse is Better".