The dependency creep keeps on happening in web frameworks where ever you look.

I was thinking of this quote from the article:

> Take it or leave it, but the web is dynamic by nature. Most of the work is serializing and deserializing data between different systems, be it a database, Redis, external APIs, or template engines. Rust has one of the best (de)serialization libraries in my opinion: serde. And yet, due to the nature of safety in Rust, I’d find myself writing boilerplate code just to avoid calling .unwrap(). I’d get long chain calls of .ok_or followed by .map_err. I defined a dozen of custom error enums, some taking other enums, because you want to be able to handle errors properly, and your functions can’t just return any error.

I was thinking: This is so much easier in Haskell.

Rather than chains of `ok_or()` and `map_err()` you use the functor interface

Rust:

``` call_api("get_people").map_or("John Doe", |v| get_first_name(v)).map_or(0, |v| get_name_frequency(v)) ```

Haskell:

``` get_first_name . get_name_frequency <$> callApi "get_people" ```

It's just infinitely more readable and using the single `<$>` operator spares you an infinite number of `map_or` and `ok_or` and other error handling.

However, having experience in large commercial Haskell projects, I can tell you the web apps also suffer from the dreaded dependency explosion. I know of one person who got fired from a project due to no small fact that building the system he was presented with took > 24 hours when a full build was triggered, and this happened every week. He was on an older system, and the company failed to provide him with something newer, but ultimately it is a failing of the "everything and the kitchen sink" philosophy at play in dependency usage.

I don't have a good answer for this. I think aggressive dependency reduction and tracking transitive dependency lists is one step forward, but it's only a philosophy rather than a system.

Maybe the ridiculous answer is to go back to php.

I've spoken to a german news outlet a while back, and that was my contention too: I don't know if the article will be any good.

My suggestion was as follows:

Start the article by providing the dry facts - the meat of the article - in a super condensed format, so people get it as quickly as possible. Then, ask for money to get the rest - the analysis, the "whodunit", the "how we got there", the background, the bio's, and everything else. And then tell people: "If this interests you, you can pay $0.xx to read the rest of our article about it, including: (insert bullet points I just mentioned)"

The first section acts as proof that the person writing the article did their research; the rest is for those who are genuinely interested in the topic. It prevents disappointment and tells you clearly and transparently what you're getting for you cents.

I don't think the company did it in the end. They're struggling.

That is a correct evaluation of this. I've worked in marketing for a longer while and your instincts are spot on.

In media generation, such as music, streaming, articles, etc the only thing that gets people to fork over money regularly is if they're a fan of some sort. The patronage system. That means they have to like you and come back to you so often that they'll feel a connection - and they'll want to support you out of the goodness of their heart. This is the strategy used by streamers, by buskers on the street, and by content creators of all sort.

The main issue with applying this to articles is that most news is discovered by way of google news, or a similar hub site, which sometimes will present news from you - but it won't happen often enough to create such a connection. One may ask if the frequency of this happening is deliberately that low, compared to social algorithms on other products, where return visits are encouraged - if you like a tweet, you get more tweets from that same person; if you like a short, you get more youtube shorts from that channel; and so on.

Ultimately for news you have to be so large that people will come to you on their own, without being funneled through google news. This works for huge news sites - the register, NYT, Golem, etc. There is no way for a small site to break through like that. I think the last time I've seen this get pulled off successfully - a website started from 0 generating a cult following - was Drudge Report.

A randomly generated program from a space of programs defined by a set of generating actions.

A simple example is a programming language that can only operate on integers, do addition, subtraction, multiplication, and can check for equality. You can create an infinite amount of programs of this sort. Once generated, these programs are quickly evaluated within a split second. You can translate them all to English programmatically, ensuring grammatical and semantical correctness, by use of a generating rule set that translates the program to English. The LLM can provide its own evaluation of the output.

For example:

program:

1 + 2 * 3 == 7

evaluates to true in its machine-readable, non-LLM form.

LLM-readable english form:

Is one plus two times three equal to seven?

The LLM will evaluate this to either true or false. You compare with what classical execution provided.

Now take this principle, and create a much more complex system which can create more advanced interactions. You could talk about geometry, colors, logical sequences in stories, etc.

The thing I would appreciate much more than performance in "embarrassing LLM questions" is a method of finding these, and figuring out by some form of statistical sampling, what the cardinality is of those for each LLM.

It's difficult to do because LLMs immediately consume all available corpus, so there is no telling if the algorithm improved, or if it just wrote one more post-it note and stuck it on its monitor. This is an agency vs replay problem.

Preventing replay attacks in data processing is simple: encrypt, use a one time pad, similarly to TLS. How can one make problems which are at the same time natural-language, but where at the same time the contents, still explained in plain English, are "encrypted" such that every time an LLM reads them, they are novel to the LLM?

Perhaps a generative language model could help. Not a large language model, but something that understands grammar enough to create problems that LLMs will be able to solve - and where the actual encoding of the puzzle is generative, kind of like a random string of balanced left and right parentheses can be used to encode a computer program.

Maybe it would make sense to use a program generator that generates a random program in a simple, sandboxed language - say, I don't know, LUA - and then translates that to plain English for the LLM, and asks it what the outcome should be, and then compares it with the LUA program, which can be quickly executed for comparison.

Either way we are dealing with an "information war" scenario, which reminds me of the relevant passages in Neal Stephenson's The Diamond Age about faking statistical distributions by moving units to weird locations in Africa. Maybe there's something there.

I'm sure I'm missing something here, so please let me know if so.