That wall was detailed in 2003 in Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, Chapter Four, "Smart UI Anti-Pattern." The context is the same, the problem is the same, the solution is the same. Even the advantages and disadvantages are the same as what you see in vibe-coded projects.
> A project needs to deliver simple functionality, dominated by data entry and display, with few business rules. Staff is not composed of advanced object modelers.
> [...] Simple projects come with short time lines and modest expectations. Long before the team completes the assigned task, much less demonstrates the exciting possibilities of its approach, the project will have been canceled. [...] And in the end, if they do surmount these challenges, they will have produced a simple system. Rich capabilities were never requested.
> Therefore, when circumstances warrant:
> Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules into them. Use a relational database as a shared repository of the data. Use the most automated UI building and visual programming tools available.
> [...] Yet it is a legitimate pattern in some other contexts. In truth, there are advantages to the SMART UI, and there are situations where it works best—which partially accounts for why it is so common. Considering it here helps us understand why we need to separate application from domain and, importantly, when we might not want to.
> Advantages: Productivity is high and immediate for simple applications; Less capable developers can work this way with little training; Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit their requests; Applications are decoupled from each other, so that delivery schedules of small modules can be planned relatively accurately; Expanding the system with additional, simple behavior can be easy; Relational databases work well and provide integration at the data level; 4GL tools work well; When applications are handed off, maintenance programmers will be able to quickly redo portions they can’t figure out, because the effects of the changes should be localized to each particular UI.
> Disadvantages: Integration of applications is difficult except through the database; There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply; Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options; Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.
> [...] Remember, one of the consequences of this pattern is that you can’t migrate to another design approach except by replacing entire applications. [...] Don’t bother hedging your bet. Just using a flexible language doesn’t create a flexible system, but it may well produce an expensive one.
That is fascinating. thank you for digging out that quote. Maybe I should get into book writing.
> with few business rules. Staff is not composed of advanced object modelers.
That seems dismissive of the people who live day-in-day-out with the problem at hand. In my experience, most people are actually advanced data modelers, but they spend their energy on that on people instead of machines. Makes them less gullible than me but worse at computers, so it's a wash.
> Rich capabilities were never requested.
>
When you have to deal with someone else, especially from a different department or outside team, that you don't trust, revealing your rich inner data model of the situation at hand is not only not to your benefit, but often to your detriment. Especially with a history of IT projects not landing or going wrong. You're not getting those rich requests because you (well, the quoted author) isn't being trusted.
The advice is good, but dated. What do vibecoders who hit the wall need? Teaching people that wanna learn SQl has gotten a lotta people rich. Lemme talk to a thousand of the people vibecoding appa and lemme write their book. (After reading that book from 2003.)
I suspect that vibe coders who hit a wall need the same thing that programmers from 2003 who hit a wall needed. Talk to the business people, get an understanding of their domain and the problem at hand, and model that as a series of anthropomorphic objects that encode the business rules in the language that the domain experts already used (tweaked by the need for disambiguation and clarity). Back in the day, this was software design, a distinct skill (and often job!) from computer programming.
I'd love to read your book, if you write it. Anybody who's talked to a thousand people trying to solve the same problems will have an amazing perspective and a lot to teach.
Analog Mono and Two Slice are really neat. If you like those, you'll probably also like another of my favorite modern pixel fonts: Departure Mono. https://departuremono.com
Came here to say the same, I actually like Departure so much I use it as my coding and Terminal font. I'll definitely be trying out the fonts in the original post.
Yeah my programming font since many years now is a pixel-perfect (no AA at all) modified version of Terminus. I modified it myself: don't even remember with which software (but I've got notes about the modifications I did and what's required should I want to modify something again).
I remove a pixel from the lowercase 's' (the top-rightmost one), I modified lowercase 'l' a bit (so it looks less like the '1' digit), I replaced a few characters like the at sign '@' with those from a pixel-perfect Apple Monaco font, and I like to have an empty hole in the middle of my pipe symbol (which still cannot be mistaken for a colon).
Plus a few mods I forgot.
I'd argue that a pixel-perfect font is "tied" to a range of pixel-per-inch monitors: a pixel-perfect font that's perfect for a 110 PPI monitor may neither work on a 90 PPI one nor on a 140 PPI+ one.
But yeah I'm a very happy camper. I obviously cannot distribute it as I "stole" a few characters from Monaco as is and just replaced them in my modded Terminus font.
I'm not trying to defend the blog post, but I gave Slop Cop 775 words of an essay by Schopenhauer (translated into English) and got "15 patterns detected."
I fear we're approaching the point where AI-written text grows indistinguishable from human-written text, unless the AI-user is exceptionally lazy and uses an obsolete model...
> What I’ve built here is a structured edition — the parsing, reconstruction, linking, indexing, etc. I haven’t published a formal license for that yet.
> By default, minimize button not present in titlebars
This is explained by the ElementaryOS H.I.G.:
> Apps should save their current state when closed so they can be reopened right to where the user left off. Typically, closing and reopening an app should be indistinguishable from the legacy concept of minimizing and unminimizing an app; that is, all elements should be saved including open documents, scroll position, undo history, etc.
> Because of the strong convention of saved state, elementary OS does not expose or optimize for legacy minimize behavior; e.g. there is no minimize button, and the Multitasking View does not distinguish minimized windows.
I didn't want to put a spiked nose ring on the first calf born on my small farm because of the visual shock. Its mother didn't kick the calf off as it grew up. The calf wouldn't stop nursing, kept the cow in milk for far too long, and I believe eventually caused her death.
These are not sapient beings that are capable of looking out for their own well-being. We've bred that out of them over hundreds of human generations.
I think there's a linguistically-driven temporal misunderstanding happening here. A cow couldn't have a calf if it hadn't become pregnant.
But there's so much to the linguistics of animal husbandry and dairy that many folks don't know. It goes way deeper than just the milk-oriented terms in the article: Heifer versus cow, freshening and calving, steer versus ox versus bull, AI (not the LLM kind) versus natural service, the barn, parlor, and pasture, and more. Plus plenty of technical knowledge. If you're not hand milking, how many mmHg of negative pressure should you use? Do you use a surcingle, or a claw, or a robot?
Even in the milk-oriented terms, there are others not covered by the article. HTST and UHT aren't the only options, there's also LTLT. Pasteurization can be done in a pipeline, or in a vat. Smaller vats for home and small farm usage can be multi-purpose: I pasteurized milk and cultured yogurt in mine. Some folks even care about the specific proteins (A1 beta-casein versus A2), which is genetically determined by the cow (and can be bred for).
I’m curious curious, what’s the English term for a female calf that lived more that two years and didn’t experience pregnancy? Never heard such a term in any language.
Asking it to do something isn't exactly complicated. At the very least, it's way easier than actually coding so why would you expect people to struggle with writing? There's no skill required in using LLMs, that's kinda the point.
Someone might feel different about a (future) community owned and managed LLM than one controlled by Altman, Musk, and similar. It would be nice to feel like we're building something together instead of funding the oligarchy and accelerating the collapse of civilization.
> A project needs to deliver simple functionality, dominated by data entry and display, with few business rules. Staff is not composed of advanced object modelers.
> [...] Simple projects come with short time lines and modest expectations. Long before the team completes the assigned task, much less demonstrates the exciting possibilities of its approach, the project will have been canceled. [...] And in the end, if they do surmount these challenges, they will have produced a simple system. Rich capabilities were never requested.
> Therefore, when circumstances warrant:
> Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules into them. Use a relational database as a shared repository of the data. Use the most automated UI building and visual programming tools available.
> [...] Yet it is a legitimate pattern in some other contexts. In truth, there are advantages to the SMART UI, and there are situations where it works best—which partially accounts for why it is so common. Considering it here helps us understand why we need to separate application from domain and, importantly, when we might not want to.
> Advantages: Productivity is high and immediate for simple applications; Less capable developers can work this way with little training; Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit their requests; Applications are decoupled from each other, so that delivery schedules of small modules can be planned relatively accurately; Expanding the system with additional, simple behavior can be easy; Relational databases work well and provide integration at the data level; 4GL tools work well; When applications are handed off, maintenance programmers will be able to quickly redo portions they can’t figure out, because the effects of the changes should be localized to each particular UI.
> Disadvantages: Integration of applications is difficult except through the database; There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply; Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options; Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.
> [...] Remember, one of the consequences of this pattern is that you can’t migrate to another design approach except by replacing entire applications. [...] Don’t bother hedging your bet. Just using a flexible language doesn’t create a flexible system, but it may well produce an expensive one.
reply