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.

It's your turn

The plausible answer is yes, there is an opportunity. One line item in the entire bill of materials for a successful product got cheaper. The other line items are unchanged.

All else being equal, the organization that can leverage the improved code maintenance tools has an edge, but a small one. Code is only part of the winning package.

Getting 404

Try a raspberry pi 5 and tinker. I use it for my daily work. All dev work.

It's great for learning to keep it lean.

Uh... my now-wife. Not ex.

I became single in 2013 and cupid was definitely where the cool kids were. But it was a desktop thing. You sat at a computer and engaged. You invested. Tinder and swiping are a phone thing. No real investment.

Funny thing, 12 years later I met my wife on the zombified corpse of cupid. So... go figure.

You've done the easy part.

Mo's videos are cutting and funny. I've been wondering, "what's he actually doing between videos?" Turns out this is it?

Fair point, and you're right to push back on that. Rereading the post, I can see that I left a lot of context unstated. That's on me.

"Talk Like Claude Day" is proposed as a joke holiday in which participants would endeavor to communicate as if they were an Anthropic LLM. Participants would compete to cleverly combine "Claudisms" in novel and unexpected ways, and in novel and unexpected contexts.

The novelty is the real thrust - and it has teeth. Extending Claudisms to novel situations is what produces the humor. This is about fun, not work.

But what I really should have included was the benefits, because they are load-bearing. The humor here masks a purpose and process that underpin the proposal. As the robot overloads render us all into a permanent underclass, it is necessary to give that underclass outlets. Humor is well known to work - that is the purpose - to keep the new underclass from grabbing the pitchforks. The process rests upon the tendency of people to imitate their conquerors, combined with the remedial value of allowing satire to be directed at the powerful. Process satisfies purpose by allowing the permanent underclass of irrelevant humans to believe they have the freedom to mock their new overlords.

I hope I have cleared up any confusion caused by my earlier confusing points.

But one thing to keep in mind, we still have not cleared up the definition of what a "day" is. Shall I write that up now and add it?

> yes, write up the new complete post

100/month Claude personal.

Your Website seems to be messing with browser history. Back button will not take you back to HN.

Curiosity