I'm playing around with it, and it's very cool! One issue is that fingerprint expansion doesn't always work, e.g. I have a memory "Going to Albania in January for a month-long stay in Tirana" and asking "Do I need a visa for my trip?" didn't turn up anything, using expansion "visa requirements trip destination travel documents..."
What would you think about adding another column that is used for matching that is a superset of the actual memory, basically reusing the fingerprint expansion prompt?
Depends on what your prose is for. If it's for documentation, then prose which matches the expected tone and form of other similar docs would be clichéd in this perspective. I think this is a really good use of LLMs - making docs consistent across a large library / codebase.
A problem I’ve found with LLMs for docs is that they are like ten times too wordy. They want to document every path and edge case rather focusing on what really matters.
It can be addressed with prompting, but you have to fight this constantly.
> A problem I’ve found with LLMs for docs is that they are like ten times too wordy
This is one of the problems I feel with LLM-generated code, as well. It's almost always between 5x and long and 20x (!) as long as it needs to be. Though in the case of code verbosity, it's usually not because of thoroughness so much as extremely bad style.
I have been testing agentic coding with Claude 4.5 Opus and the problem is that it's too good at documentation and test cases. It's thorough in a way that it goes out of scope, so I have to edit it down to increase the signal-to-noise.
The “change capture”/straight jacket style tests LLMs like to output drive me nuts. But humans write those all the time too so I shouldn’t be that surprised either!
1. Take every single function, even private ones.
2. Mock every argument and collaborator.
3. Call the function.
4. Assert the mocks were called in the expected way.
These tests help you find inadvertent changes, yes, but they also create constant noise about changes you intend.
Juniors on one of the teams I work with only write this kind of tests. It’s tiring, and I have to tell them to test the behaviour, not the implementation. And yet every time they do the same thing. Or rather their AI IDE spits these out.
If the goal is to document the code and it gets sidetracked and focuses on only certain parts it failed the test. It just further proves llm's are incapable of grasping meaning and context.
I asked about the Peninsula campaign during the Civil War and it gave me an overview, a map, profiles (with photos) of the main military commanders, a relevant Youtube video ... rough edges but overall love the format.
Rough edges:
- aspect ratios on photos (maybe because I was on mobile, cropping was weird)
- map was very hard to read (again, mobile)
- some formatting problems with tables
- it tried to show an embedded Gmap for one location but must have gotten the location wrong, was just ocean
"Critically, the language one speaks or signs can have downstream effects on ostensibly nonlinguistic cognitive domains, ranging from memory, to social cognition, perception, decision-making, and more."
Can they really distinguish between the impact of language on these domains rather than culture? It could be the language you speak, or it could be that you're surrounded exclusively by other people that operate this way.
I mean I'm not really qualified or rigourous enough to prove this but if you have learned chinese and english it should be pretty damn obvious that it is linguistic. But in any case, human language and culture are intractable if you start trying to speak idiomatically.
Sure maybe you could isolate a bunch of scholars and give them a specification of Chinese and ask them to go at it, which is maybe what we do with Latin and Greek.
I would struggle to see how someone could earnestly argue the opposite, that language doesn't shape thought, when Chinese doesn't use conjugation, has looser notions of tense, has no direct/indirect article, uses glyphs instead of an alphabet, can be read top to bottom, right to left, left to right and doesn't use spaces to delimit words. That's even before we talk about tones or the highly monosyllabic nature of the language alters things like memorisation. (ever notice how Chinese people are often good at memorising numbers?)
Recently I've found myself getting the evaluation simultaneously from to OpenAI gpt-5, Gemini 2.5 Pro, and Qwen3 VL to give it a kind of "voting system". Purely anecdotal but I do find that Gemini is the most consistent of the three.
I am running similar experiment but so far, changing the seed of openai seems to give similar results. Which if that confirms, is concerning to me on how sensitive it could be
I found the opposite. GPT-5 is better at judging along a true gradient of scores, while Gemini loves to pick 100%, 20%, 10%, 5%, or 0%. Like you never get a 87% score.
Yeah, it's really hard to tease them apart in a GUI sort of environment, since the input is so tightly tied to the graphical view. Model and View have always seemed pretty obvious to me but I've never gotten a compelling answer as to what a controller is.
My best guess from this article, given then "associated by observer" link from View to Controller, is that the View is supposed to pass events to the Controller, which will interpret them into changes to the Model. But what's the format of these events that's both meaningfully separate from the View, e.g. could be emitted from different views to maybe different controllers, but doesn't just force the View to do most of the work we want the Controller to do?
Controller is where your logic is. Your model is your state, and the view is presentation. Both are static. The controller is the dynamic aspect that update the view to match the state and update the state according to interaction or some other system events.
Splitting the logic from the state and presentation make the code very testable. You can either have the state as input and you test your presentation, or have the presentation as input (interaction and lifecycle events) and test your state (or its reflection in the presentation).
Also this decoupling makes everything more flexible. You can switch your presentation layer or alter the mechanism for state storage and retrieval (cache, sync) without touching your logic.
The model is the source of truth. For almost all apps, it should always be valid. (For those apps that isn’t true such as massively distributed systems, it should present a projection of what can be considered valid to your locality and handle delta internally.)
There has to be a boundary that controls changes to the model. The confusion with MVC is where is the best place for this boundary. Well more than one place as it turns out because there are at least two models of reality trying to converge. The model itself and the view of the model (and the user’s mind).
The view’s job is to present a projection of the model and then collect change events to the model. Thus could be a UX or an API. Other events can also change the model like say sensor data.
The controller decides what view to show and retrieves model data to project and translates change events coming from the external world (views or events) into changes the model should interpret. This includes gatekeeping such as auth, and error handling.
That’s a lot for one class so it can get confusing very quickly. Why localize it in one place?
So viewtrollers come around where the controller is in the view class but in the onhandle methods. This also makes sense since each view has a mini controller to handle all the jiggling bits.
This works well when there are no orthogonal injections like auth or eventing. When those are added it makes sense ins viewtroller to extend the model with controller functionality to for eg control authorization or have a thin event receiver to fsm in the model.
This all works but three years later it’s hard to figure out when I read the code again. So I have learnt to treat the model as pure data as much as possible and the view as much about rendering as possible. Views can have little controllers for handling the jiggling. What the controller cares about is when a change to the system needs to happen.
Then I can put the system control fsm in one place. I can put all event handling in the same fsm to avoid race conditions.
The goal is to make it easier to reason about.
What I don’t want are multiple threads of fsms in conflict with each other.
> The model itself and the view of the model (and the user’s mind).
Trygve was very explicit about the model being a model of how the user thinks about the problem:
There should be a one-to-one correspondence between the model and its parts on the one hand, and the represented world as perceived by the owner of the model on the other hand.
> There has to be a boundary that controls changes to the model.
Yes. It's called the API of the model. The model makes available API for all semantically valid operations. As I wrote elsewhere, I usually have a facade that acts as the top-level API for the model.
The views can call this API. So can other entities.
> The controller ... decides what view to show
possibly. But views can handle their own subview.
> The controller ... and retrieves model data to project
Nope. Not the job of the controller.
> The controller ... and translates change events coming from the external world (views or events) into changes the model should interpret.
Nope, it doesn't. The views typically do that as well. Controllers may be get involved if there is a complex sequence of steps that doesn't really naturally fit into a view.
> That’s a lot for one class so it can get confusing very quickly.
Yeah, if you put all sorts of stuff in the controller that doesn't belong there.
> Why localize it in one place?
Indeed. Don't incorrectly localize all these things in one place. MVC, for example, tells you not to do this.
> This all works but three years later it’s hard to figure out when I read the code again.
Yes. MVC is much better than that thing you came up with.
That’s a fair critique. Though the snark was unnecessary.
I took the time to reread the literature and review my actual code. My updated understanding.
Model controls and holds the state of the system. It ensures the data is always valid.
Controller controls the boundary between the system and the user.
View represent the model and capture user intent to change the model. They ask the model for data they need; however I disagree with the practice that views change data directly but instead prefer they send an intention to change to the app which does the work.
Auth was not considered in 1979 as far as I can tell. Authentication is part of the “controller” but in middleware usually because it’s part of the user input boundary, and generally better if done in one place early in the event lifecycle. Authorization is part of the model.
App logic is decomposed into workflows or use cases in the app layer. Events coming in through the controller are translated into what the system understands and then passes it onto the workflow to execute.
Thus these should take change intent from the view and then actually tell/ask the model what needs to change. This allows the app to catch errors from the model, recover if they can, or handle multi step flows. Results and errors are then sent back to the view (eg GUI dialog) or controller (eg api call) that initiated the workflow.
This makes it easier to put different views over the same app logic (mobile, web, api, agent) and also test workflows in isolation.
Modern views have their own controllers for mouse and keyboard. That’s fine. Don’t care. That’s effectively outside the system in the client experience (eg browser) anyway.
Where I have trouble is when I
- put a ton of app logic in the controller
- put a ton of model updates in the view
- have a single controller for the entire system instead of one per system boundary/interface of user events.
The (DDD?) style of app logic being encapsulated outside of the controller makes a lot more sense to me now that I see it.
Hmmm...the problems you recount are exactly the problems of putting (way too much) logic into the controller...and not enough logic into the model...which is exactly what MVC recommends you not do, and which is exactly what I criticized about your approach...and which is exactly the critique you seem unwilling to accept.
¯\_(ツ)_/¯
What gives?
Put all the logic in the model. If you want authentication, put that in an "authenticated model" that wraps your model. Don't put it in the controller.
> Controller controls the boundary between the system and the user.
Nope. That is Apple-MVC. Aka Massive-View-Controller. It is not MVC.
The model API is the boundary between the model and the rest of the system.
The controller is meant to be handling things like keyboard events or http events. That’s the boundary to the user. The thinner the better.
I don’t know why you think this is a combative conversation where I need will to accept or reject anything. I lack understanding of how you would solve the same problem. Throwing chaffe is not communication. It creates a second problem beyond the one we are discussing.
How does the model handle authentication without having to become aware of boundary protocols? How the user authenticates is part of the input to the system. Eg http basic or oauth
I don’t know how you handle routing. Do you put that in the model as well?
You might have mentioned before that you are talking explicitly about web programming, where the concept drift from actual MVC to what is called MVC nowadays is even greater than in GUI programming.
MVC as described by Trygve is for GUI programming.
lol, contradictions about MVC are par for the course. It's not personal. It's just confusing. Talking about the concepts isn't the same as talking about each other as professionals. Some of the articles you linked to express this tumult over decades.
Looking at 1979, when I read this.
> A controller is the link between a user and the system.
I think of it as the boundary
> It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen.
It's the router, or view loader.
> It provides means for user output by presenting the user with menus or other means of giving
commands and data. The controller receives such user output, translates it into the appropriate
messages and pass these messages on .to one or more of the views.
The controller receives user input, translates it, and dispatches the input to the views. I think this has changed in the modern era.
> A controller should never supplement the views, it should for example never connect the views of nodes by drawing arrows between them.
I don't really understand this exactly, but I think it means views compose themselves.
> Conversely, a view should never know about user input, such as mouse operations and keystrokes. It should always be possible to write a method in a controller that sends messages to views which exactly reproduce any sequence of user commands.
The controller handles the raw input and translates it into actions/commands meaningful to the system.
>> How does the model handle authentication without having to become aware of boundary protocols?
> It gets passed required information. Just like it gets passed other information.
Is what you consider the model all logic in the system? I would not. I would consider the model to be the data in the system world, using terms in systemese. It shouldn't know or care about OAuth or SAML or HTTP Authorization or whatever. It would care about Users and Sessions.
However, is this semantics? The use case and work flow approach is just a layer on top of the data model. The auth is another layer.
Why it matters to me is I prefer to think of systems as data flows, and the code follows the data flow. Control layers are different than the actual data.
I always thought that business logic, expressed in the language of your domain, should be part of the model. The controller is just a translator from the language of keystrokes and mouseclicks into the domain language, and the view is just a translator from the domain language into pieces of text and widgets to display to the user.
In the server-side web world the controller should ideally only receive http actions and call services or fat models. It should have no business logic, only validation and parsing. In the frontend UI world the controller is bound to UI events and communicates those from the view to the model objects. (1).
Though it's probably easiest understood in a non-web world.
The web makes it quite a bit more involved with a separation of client- and server-side state - plus you have a given frontend "framework" in the shape of DOM, which people often leave out of the picture.
This latter necessities the 'escape hatches' in React and alia.
At least in my head, the 'controller' is what can either take 0 or more parameters or input models as 'input' and the controller can either provide direction to the browser as to what to do next.
e.x. in a 'proper' ASP.NET MVC 4 project I 'inherited', the View took input data in and with a tiny bit of JS magic/razor fuckery around the query page etc, but overall the controllers would return the right hints for the Razor/JS 'view' to move the application flow along or otherwise do a proper reload.
In ASP.NET MVC is a modified version of classical MVC adapted for the web.
The Controller in ASP.NET MVC takes on the role of both the classic Controller and part of the classic Model's role (orchestrating the retrieval/updating of data). The connection between the View and the Model is completely severed and mediated by the Controller.
Agreed, but maybe my mental model is splitting the 'Controller' aspect into the client / server model. Everything must get validated server side, there's no other rational choice. Otherwise you cannot enforce any consistency or business logic.
That just leaves formatting the requested changes into a language the server model accepts.
Maybe model is more 'database', controller is API interface (server side + client request requirements), and view is end user render?
Early Microsoft frameworks (the old Windows 3.x and 9x era MFC) suggested using a "document-view" model wherein the model was a "document" class serviced by a "view" class which handled presentation and UI, serving as both view and controller. There were wizards that would spit out skeletons for these classes and everything.
What would you think about adding another column that is used for matching that is a superset of the actual memory, basically reusing the fingerprint expansion prompt?
reply