KenPainter

Before Node, in a simpler world, I loved PHP. Some of the syntax was a bit clunky, but it was beautiful in its way. I met good people at user groups.

We also have to look at the design of the tools and the stack. The SQL has to get painted somehow and there are a lot of steps in between.

These steps come from the division of responsibilities, which requires layers of abstractions and associated tooling, each in theory isolating a layer of the stack with nice I/O boundaries, but adding up to a lot of handling to get that SQL query painted in the browser.

Paradoxically, React/Next is the worst possible starting point if you want performance, yet the LLM will reach for it automatically.

This question occupies my mind: given the necessary drive to validate market fit, and with the LLM reaching for common solutions like React/Next and an ORM, among many others, what opportunity is present for those who seek market fit but also develop a simplified stack that offers better performance?

Seems he might have written a paragraph or two, then it reads like straight LLM.

I thought mine was very creative, but it never got off new show hn.

Sorry no C, Emacs. Just some database stuff.

The author describes my own experience, almost detail for detail, in the same problem space. Although Claude did do well for me with Plaid. My database schema was solid, but an LLM building a UI always leads to divergence, until it falls apart under its own weight. The CSS duplication borders on criminal.

Eventually I had to solve it by making a front-end framework where there is only one way to do anything. Now my front-ends don't diverge like that any more. But there is still that nasty CSS expansion...

Kurt Vonnegut said, "damnit you've got to be kind."

Courtesy, compassion, empathy, kindness.

Forget the hypothetical cases from ethics classes. Look around at the people who cross your path and start there.

You said what I was trying to say :)

Re: CSS, it is indeed declarative, that was a bit sloppy of me. My comparison rests on observed difficulties. Valid CSS can contain duplicates, overwrites, or coupled parent-child pairs as in a grid, or mistaken use of properties that have no effect without other properties. CSS allows disciplined decomposition and separation of concerns, but does not enforce it. We all seem to agree this is the RightThing(tm), but it means CSS fails on practical grounds when compared to, for example, SQL DDL. Disciplined use of DDL is baked in, in CSS it must be enforced and requires decisions on how to do so.

It may be easier to describe "what I'm really talking about" by going more concrete. For a browser app, we have two declarative languages and one imperative. A tool like React with jsx allows me to think entirely in terms of code, folding the HTML into code, and tying off CSS to be dealt with on its own. It's a delightful simplification at first glance, that happens to leak like a sieve and forces people to become React programmers instead of browser programmers. I tend to think it is successful because it lets us think in terms of telling the computer to do things, and imposes no required mental model on how you craft your components. React says, "make it more imperative, use more code, think of your HTML in terms of code."

So I go the other way, where I add data binding attributes to HTML. A server request that modifies data always gets a response in terms of data that a small bit of framework code uses to update the DOM according to the data bindings. It is highly constrained in the same sense as SQL, there is only a small fixed set of allowed operations.

This is what I mean by declarative. My HTML data binding attributes say what should be displayed, no app code required. Naturally there are more details, but that should make the idea clear. The driving motivation is performance and developer ergonomics. Performance is amazing. Ergonomics, I can't say - it's easy for me, but I wrote it.

But solutions like these do not gain traction usually. I believe it is because people prefer the open-ended nature of React, which does not require a mapping exercise into the supported patterns before it can be used.

This is probably what I was trying to say about declarative vs imperative. React does not constrain my choices (not at first glance), and allows me to mix declarative HTML into my code. I can write any code I want, and like an LLM, I can fix anything with more code. Declarative solutions, like my own HTML data binding attributes, constrain the user to fixed supported patterns, which may not map to how the programmer thinks of the problem.

Sadly the video is no longer available. Seems like they were anticipating signals. I can see some real opportunity for confusion though, I would see the magic equals as invariants defined outside the flow of code, as mixing them into control flows could lead to lots madcap laughs so to speak.

The largest VFP project I worked on used MS SQL Server.

Foxpro's local DB handling was amazing at pulling down tables, doing complex bulk operations, and pushing the changes. Data transfer was fast, coding ergonomics were great. On top of the extremely low-cost UI creation, it was a no-brainer.

But expectations were changing, everybody wanted to run it everywhere. Citrix bought some time, but the writing was on the wall.

I prefer the strong Anthropic principle: the universe exists so that Terry Pratchett can write Discworld novels.

Two distinct strategies.

For tools and architecture,I design data structures and let the LLM write the code, in small steps. Lots of discussion with the LLM. What Cory Doctorow calls centaur mode - a human mind augmented with a more powerful body. Applies to side projects and $DAYJOB.

For applications, I rewrote a framework of mine that I used 2003-2009. It is highly constrained so the LLM has few options to improvise. I can just tell it what features to add and it adds them without much in the way of slop. I still find code repetition which I just tell it to clean up.

Nothing. Everybody is drawn to activities that bring them quiet satisfaction in both the task and it's completion.

We think we need perseverance when we get discouraged. Setbacks, dead-ends, conflicting priorities, all of these are discouraging. Too many at once or for too long, we get discouraged and doubt the endeavor.

Maybe the endeavor is not really yours. Maybe the other demands truly require more of your attention to lay them to rest, then you return to it.

"Inspiration" is snake oil offered to your lesser self, the self that wants to be on the mountaintop all the time.