The tl;dr is don't do that either.

Ok they are all phones that run apps and have a camera. I'm not an "AI power user", but I do talk to ChatGPT + Grok for daily tasks and use copilot.

The big step function happened when they could search the web but not much else has changed in my limited experience.

I'm not against monetizing advertisement for the 1st use case either.

they could even input/train it on their own work. I don't think someone can use AI to copy your art better than the original artist.

Plus art is about provenance. If we could find a scrap piece of paper with some scribbles from Picasso, it would be art.

also remember when GPU usage was so bad for the environment when it was used to mine crypto, but I guess now it's okay to build nuclear power plants specifically for gen-ai.

this what happens when you centralize all decision making to people who have no local knowledge of the community they are administrating, and predicate their jobs on following a checklist, usually as implemented by buggy software, instead of making a judgement call based on experience and circumstances.

Imagine when OpenAI has their 23&me moment in 2050 and a judge rules all your queries since 2023 are for sale to the highest bidder.

best practices usually come from giant companies with tens of thousands of engineers like google (who doesn't seem to be keeping up with competition btw) and amazon (which is notorious for burning out people).

what science or evidence drives the best practices?

I suggest this is a good notation for data structures like, stack.push(10) or heap.pop()

I'm suggesting we don't use this notation for things like rules to validate a file, so I suggest we write validate(file, rules) instead of rules.validate(file).

Then we can express the rules as a data structure, and keep the IMO unrelated behavior separate. Note then we don't need to worry about whether it should be file.validate(rules) perhaps. Who does the validation belong to? the rules or the file? the abstractions that are created by non-obvious answers to "who does this behavior belong to" are generally problems for future changes.

problem is more when you have types that "do things" and "have responsibilities" (usually to "do things with other types they hold pointers to, but do not totally own"), such a type is very difficult to maintain because there's now:

- a boundary of its responsibilities that is subjective,

- responsibility of building collaborators and initializing the type

- dealing with test doubles for the collaborators.

It's okay to create a new data structure that combines some primitive data types in a "struct", like an array that tracks its length.

But we don't want to "build abstractions and associate behavior to them" (just associate behavior to data structures like push/pop).

Abstractions have a maintenance cost associated with it ie, another developer or possibly yourself must be able to recreate the "algebra" associated with that type (your thought process) at the time of making modifications. This creates some problems:

1. Since there's no requirement to create a cohesive algebra (API), there was probably never a cohesive abstraction to begin with.

2. Requirements may have changed since the inception of the abstraction, further breaking its cohesion.

3. Since we largely practice "PR (aka change) driven development", after a few substantial repetitions of step 2, now the abstraction has morphed into something that's actually very tied into the callsites (verbs), and is essentially now tech debt (more like a bespoke rube goldberg machine than a well-designed re-usable software component).

You can introduce types if you follow the open/closed principle which means you don't change abstractions after their creation (instead create new ones and then delete old ones when they have no callsites).

IMO the "microservices" architecture is kind of a failure from an economic perspective. On top of many of the talks like this one [0], which discuss things technically, microservices gave us "tech companies" employing 5-10 eng + PM + EM, which inevitably leads to "org building" and office politics, bloated engineering teams (anecdote: Musk reducing much of X staff).

I think we'll see a trend toward monorepos + high velocity programming utilizing LLMs like copilot, enabling higher productivity with smaller teams.

[0]: https://youtu.be/LcJKxPXYudE?si=zPsbuFBWqhH1QhKh

it may be that a bug only shows when hundreds of transitions are performed (like an overflow or bug due to large data), but that's more stress testing. many bugs have repros involving a few state transitions.

relational algebra is a useful tool in my opinion because much of programming involves adding/removing things from sets or testing for their membership in a set. also relations are powerful as they can express recursive ideas like which widgets are contained within others (from the GUI example).

relations also allow defining invariants at a high level which must be true at any state. (eg, there should be no state like: audio_buffer_is_empty and audio_playing)

additionally we have languages such as SQL or for example https://alloytools.org/applications.html that can help programmers specify this in a familiar way.

If you create a query language, then the state can be verified to match expectations at any point.

I'm not sure why we don't program like this.