One of the reasons I stopped using it.

Ppl who think this is a good idea should be compelled to maintain some M4 or other configuration "files". These configuration files ALWAYS devolve into a full language if they are actually used. So now you have the language you wrote your app in and then you have another, shittier language for your configs ... that you have to maintain.

Please stop doing this.

What should we do? In this case just express the chart in a natural language. Where there are uncertainties, the LLM should ask questions to clarify and record the results.

1 you didn't google current events before asking the first Q. Try that before asking someone else to.

2 mid-tier LLMs are capable of reasoning through your second Q. Go ahead try that next time.

3 you haven't accepted that 2 is true and the ramifications thereof.

[1] https://en.wikipedia.org/wiki/Online_age_verification_in_the...

[2] https://en.wikipedia.org/wiki/Grooming_gangs_scandal

Hilariously, a commenter asked me for a citation for the epidemic. Commenter: you're not mr current events are you?

The money doesn't go to the start ups - it all goes to large tech companies like IBM, etc, because, obviously, IBM knows about innovation.

The cover is that the government doesn't know tech so it will give money to trusted partners and they will choose who to give the money to because they've been doing such a great job innovating in Canada. Surprise: they gave the money to themselves!

You might have wondered why all these incubators in the crypto era were desperate to get you to go to their office. You might have also wondered: what fool is paying for this nice office in downtown Toronto where the prices are crazy-high? The taxpayer.

All of that money was completely wasted and worse, little of it went to actual start ups.

However, no one will admit this because:

. many people don't know them (the techs) well enough because they're so abstruse. Some people would argue this a necessary feature.

. many people only know them and so can't compare them to something else

. people that do understand them typically have financial or ego reasons to look the other way

. people that do understand them AND are rich and happy are afraid of all the other ppl in this list.

Generalization: any widely use tech must be extremely complex or extremely simple (eg TCP).

It seems obvious. Moreover, in a simple model, it seems like whatever tokens you do add have to have MORE information than the average in the existing window.

In a non-trivial model (and this is the model I would choose), since you are adding them to the end, they likely have to have MUCH more information.

Proof as always is an exercise to the reader.

  ┌─────────────────┬──────────────┬───────────────┬────────────────────┬──────────────────────┐
  
  │ Model           │ Input ($/MTok)│ Output ($/MTok)│ Batch Input (−50%) │ Batch Output (−50%)│
  
  ├─────────────────┼──────────────┼───────────────┼────────────────────┼──────────────────────┤
  
  │ Haiku 4.5       │    $1.00     │     $5.00     │       $0.50        │        $2.50         │
  
  │ Sonnet 4.6      │    $3.00     │    $15.00     │       $1.50        │        $7.50         │
  
  │ Opus 4.7        │    $5.00     │    $25.00     │       $2.50        │       $12.50         │
  
  │ Opus 4.8        │    $5.00     │    $25.00     │       $2.50        │       $12.50         │
  
  │ Fable 5         │   $10.00     │    $50.00     │       $5.00        │       $25.00         │
  
  └─────────────────┴──────────────┴───────────────┴────────────────────┴──────────────────────┘

US-only inference (Fable 5): +10% on input and output

Output is always 5× the input rate across all models

(I have not idea how to format this properly but the ASCII is fine)

There is also a mountain of bullshit eg "[architectural|design] [anti]patterns" that are written mostly (I would argue) to sell something (consulting, hardware, etc). This is typically at odds with a good solution.

There is a relative lack of actual documented architectures that work. Not only do you need the details but also the usage of these systems so as to judge what "good" is.

We will probably just go the HTML route with architecture: take a really bad base and just keep throwing compute, memory, and network I/O at the problem until it works.

Note to self: invest in energy ETFs.

https://www.youtube.com/@YannicKilcher

I was thinking there should be some metric around d(code)/dt . That is, as the software is used, 'bad' code will tend to change a lot but add no functionality. 'Good' code will change little even when it's used mode.