Ask HN: How did Django land on such abomination of MVC naming scheme?

[textread]

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

[PaulHoule]

MVC is itself a bad naming scheme. At least in the mid-2000s the thing web-based MVC had in common was that all your endpoints went through some function which could render a different template based on the circumstances: for instance re-draw the form with error messages or display a message saying the submit was successful.

(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” }

in JavaScript there is some piece of data describing a situation. It does not have to be an ‘object’ or adhere to any particular discipline because it can. In fact, there are disciplines around treating data as data in the abstract as opposed to a set of objects that provide affordances. SQL, Immutability, a defined set of operators such as “add a member to this list” which can be bound to events or sent over the wire or be done or not done on the digression of the system, etc.

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.

[textread]

> all your endpoints went through some function

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!

[rossdavidh]

There are, as the saying goes, only two truly hard problems in programming:

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.

[textread]

> eventually far too much was built on it

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...

[rossdavidh]

Impossible, no. Worth it? The names are annoying, but not as annoying as the transition would.

[isodev]

I think MVC is a general concept / pattern and doesn't need to be reflected exactly in order to be useful. In case of Django (and other frameworks like Phoenix), the "view" is not necessarily a template .. can be a JSON response, CBOR or something else entirely.

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.

[textread]

> The notion of a "controller" is also quite flexible.

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?

https://xkcd.com/927/