Perhaps you may find like-minded folks in the functional-thinking community:
I was trying to figure out what you meant by "declarative" because CSS is declarative. (My understanding is: "declarative means you say (declare) what you want, but not how to get it." Usually SQL is the poster child of declarative languages.)
I think you're really talking about a mix of preferring data (vs actions/calculations) and DSLs (which aren't necessarily declarative)
Eric Normand has some thoughts you might appreciate:
I think data can be very powerful. For example, someone explained to me:
> I've been helping my non-tech father with Home Assistant. I've honestly been shocked with how far "community extensions" + "user configuration" can take you. Every time we hit a bug, I go "time to hit github" but without fail chatgpt and him are able to tweak a setting to get it working.
If you make your system configurable (config==data), you can skip the whole compile/build step!
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.
I think actions vs calculations is a better framing here. It's not just about avoiding imperative code or nondeterminism. It's about being extra careful with actions because the order and number of times they run matter.
Here is an example of a calculation written imperatively. It remains easy to reason about because the actions don't leak out of the function:
function add(ns) {
let total = 0
for (const n of ns) {
total += n
}
return total
}
On the other hand, a deterministic state machine like `a = AddMachine` is harder to reason about because it still matters how many times the action `a.transition(1)` is called. (Note it is possible to implement the state machine as calculations.)
I think the real question you're asking is: why isn't AI coded software replacing well-known incumbent software (office, adobe, etc...)
Because I see AI coded software everywhere: HN has been complaining about the recent influx of Show HNs due to AI. Take a specific product category: there are about two new dictation apps on Show HN every week.
Here are my theories:
- adobe/office are simply too complex for AI to replicate (as of now). Theo Browne has been testing all the frontier models with a relatively simple fish game. The results have been subpar, at best. I don't think anyone would prefer the AI-generated games over the original. Even if the AI-generated version was free.
- Most AI-coded software won't be distributed like classic software. Instead of a bag of hundreds of features (adobe/office), AI will be used to create the specific 5% of the features a single user really needs (home-cooked software). The software may even be per project or even per task. Why spend 20X to 100X the tokens/time when you only need a small subset of the features?
- AI may not be able to replace human "taste" or design. There is a lot of design that went into adobe and office. I don't think AI can fully understand all the "why's" of these designs. We can already kind of see this with open source: Gimp and LibreOffice are alternatives to adobe/office. Yet most people prefer the paid options.
- Even if AI solved coding, there are other barriers like marketing.
Some examples:
- I built my perfect window management system with the help of AI. It suits my very specific needs very well, but it's nowhere near ready for distribution. So this is AI-generated software no one else will ever probably see.
- Going with the home-cooked meal analogy: there is a dish served at all Chinese restaurants in Korea: jjajangmyeon. However you can't find it in China because that dish is only found at home, not at restaurants in China.
My first impression is it's very similar to the stock iOS weather app Apple provides by default (feature/layout-wise). I couldn't see any major differences based on the description here or in the app store. That's what kept me from even trying it.
So my advice is to highlight the major benefit over the iOS weather app that ships with every iPhone.
The only major difference I could see is the data source. Did you intentionally not use Apple WeatherKit? (If so, what was the rationale?)
Apple hardware uses a unified architecture. That means the CPU and RAM are integrated together: it is very difficult/impossible to strip the RAM from these systems.
This unified architecture makes Apple hardware very good for AI work, where latency between RAM and CPU is very important
Even the SSDs (which are normally more strippable) use a proprietary hardware form factor.
I think the article mentioned the real draw:
> Apple noticeably promoted the ability to link multiple Mac Studios together into a single, more capable system for running large frontier AI models, a feature aimed at business and developer customers rather than everyday consumers.
(Couldn't read the source cited, might have more info: The Information)
I have been considering adding labels/filters based on sentiment analysis to my HN reader. I wonder if your classifier-based method would be more effective.
I added filters that blur posts from new HN accounts based on age/karma thresholds (as suggested by another HN user). However, instead collapsing, I just blurred them. This allows quickly peeking via hover. My reader also highlights posts with higher points/comments, and those orange highlights survive the blurring.
That’s very nice. Feel free to integrate if you want :) Just request https://classify.stylometry.net/violations/49458161 or whatever item ID (as long as it was posted later than a few weeks ago) and it will return the scores for that post/comment and all its children.
Wow that was quick :) Meh, I feel like comment points have become somewhat untethered to comment quality (at least assuming threads are roughly sorted by comment score). It’s a good heuristic usually but it’s wrong often enough for it to be difficult to rely on.
I want to improve the classifier scores too. There’s some parameters in the loss function I could play around with more when training which basically optimize for more false negatives or false positives. Problems with no ground truth are very frustrating lol (though I suppose dang/tomhow’s manually written warnings could be treated as labels instead of using labels from GPT, but I suspect there’s not enough of them).
I was trying to figure out what you meant by "declarative" because CSS is declarative. (My understanding is: "declarative means you say (declare) what you want, but not how to get it." Usually SQL is the poster child of declarative languages.)
I think you're really talking about a mix of preferring data (vs actions/calculations) and DSLs (which aren't necessarily declarative)
Eric Normand has some thoughts you might appreciate:
- How a problem might take 1000 SLOC to solve directly, but only 10 SLOC with a DSL (plus up to 500 SLOC for the DSL itself; still fewer lines total) https://ericnormand.me/podcast/magical-leverage-languages
- Data vs calculations vs actions: https://ericnormand.me/podcast/what-is-an-action
---
I think data can be very powerful. For example, someone explained to me:
> I've been helping my non-tech father with Home Assistant. I've honestly been shocked with how far "community extensions" + "user configuration" can take you. Every time we hit a bug, I go "time to hit github" but without fail chatgpt and him are able to tweak a setting to get it working.
If you make your system configurable (config==data), you can skip the whole compile/build step!
reply