Ask HN: How did Django land on such abomination of MVC naming scheme? I am not satisfied with their official explanation at https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names Was there a legacy reason why they are trapped with MTV naming scheme? https://www.youtube.com/watch?v=OAVnOz7i-JA |
(I’d be afraid a young dev would have no idea this is possible without using React or Vue)
That generation of “MVC” systems stole the name of a very different UI coding paradigm from Smalltalk more than a decade ago. It is common for a web MVC system to be missing one of the letters which is not a problem because they work fine, it’s just they still call it MVC.
And what is a model anyway? The “anemic domain model” is the industry standard, whether it is a POJO in Java or
{ customerId: 5, name: “Alice” }
The “view” is usually well defined but the “controller” is the balance-of-system and doesn’t have to have any particular structure at all.
Are you refering to CGI?
> I’d be afraid a young dev would have no idea
/s But then, I want to reinvent the wheel, it will be square and better.
> treating data as data in the abstract
Now you are really sounding like Sussman from SICP :-)
> “controller” is the balance-of-system
In Django, they call this as a View!
1) naming things
2) cache invalidation
3) off-by-one errors
It was, I'm sure, named hastily while they were in the earliest stages of development, thinking primarily about what the code would do and not much about what to name it. Renaming things later was never the highest priority, and then eventually far too much was built on it to change things.
The problem is, if you actually spend a lot of time at the beginning thinking about the name, you may not do much better, because software architecture often turns out to be somewhat different than the original plan. Naming things at the beginning fails for the same reason detailed product specs at the beginning often fails, but unlike functionality, names are rarely changed later once the situation is better understood.
Incumbents dilemma right?
Shouldnt it be possible to "Rip off the band-aid" when releasing, say Django-6.0 and rename things the way most people not already familiar with Django name things.
> names are rarely changed later
So refactoring APIs is really hard, especially when those are being consumed outside the organization... Shouldnt be an impossible task. After all, API versioning happen all the time internally...
The notion of a "controller" is also quite flexible. It accommodates "whatever logic we need to interpret the user's request and respond with the right thing". Is everything part of the controller? Is there some kind of a domain/business logic layer as well? All up to you really.
Are you refering to the "view" or the "controller"; "django view" or "rails controller" :-)
If we were to coin a new name, say "Zeitgeist" to refer to the notion of a thing that does 'controller things' and more, are we compounding the problem further, or are we simplifying the problem?