5 ms·

It's all about managing state and dependencies. Doesn't matter much for small apps but does when you have tons of people trying to work on the same thing. Also

It's all about managing state and dependencies. Doesn't matter much for small apps but does when you have tons of people trying to work on the same thing. Also helps in large organizations that develop lots of apps because it reduces the learning curve for new team members. Besides, it's not like MVVM is a huge thing. It can be explained in a paragraph.

overgard 11y ago
> It's all about managing state and dependencies. Doesn't matter much for small apps but does when you have tons of people trying to work on the same thing. That literally applies to any program though. A compiler has to manage a lot of state too, but I've yet to hear compiler makers trying to figure out why they have so much logic in their controllers, and why their views are too big (because nobody would write an MVC compiler). > Besides, it's not like MVVM is a huge thing. It can be explained in a paragraph And yet there's like 500 blog posts about why you're doing it wrong, and how to do it better, etc. Of course, in truth it's not complicated, what makes it complicated is when it's applied in contexts that make little sense.
- Arnavion 11y ago
  >because nobody would write an MVC compiler Model - Input -> output format transformation View - input/output Controller - Drives the model And not much coupling between them except to pass data back and forth. Sounds like a regular compiler to me.
  - overgard 11y ago
    You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. Just looking at what you said though: why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Also, claiming the view as input/output is pretty reductive. How do I represent a lexer as a view? More importantly, why would I want to? Fun experiment, find the views and controllers in here: https://github.com/llvm-mirror/clang https://github.com/llvm-mirror/clang
    - Arnavion 11y ago
      >You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. shrug MVC / MVVM is that simple. >why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Models are not limited to being data stores. Models are responsible for doing work, so-called business logic. Controllers / ViewModels work with Views to take in user input and apply it to the models, then take the updated model and give it back to the user. >How do I represent a lexer as a view? The lexer is part of the model. The view would be what the compiler uses for input/output: for a CLI compiler it would be the function that reads stdin or the filesystem + the function that writes to stdout and the filesystem, for a compiler hosted in an IDE or webpage would be the compiler library interface (ie: a programmatic way to give it files or strings and receive output + errors), and so on. Separate views that only know how to take in user input and display user output, interfacing with a common controller/viewmodel + model. Edit: Minor clarifications.
      - Arnavion 11y ago
        To clarify, an example of a non-MVC compiler would be something that expects to read a list of files from argv and expects to write to stdout. An example of a MVC compiler would be something that abstracts the act of compiling bytes into bytes from how it obtains those bytes or puts them out. I think gcc works like the former and clang like the latter? I'm not familiar with either. An example I am familiar with is the TypeScript transpiler - a "Compiler" class with a pluggable "Host" interface. There is one implementation of that host for each environment it can run in (in-memory, node.js, cscript.exe) that knows how to read files and write output. The compiler class would call host.writeFile(filename, contents) and it's up to the host whether to write that to a file, or a textarea in a web page, or pipe the string to another transpiler, or whatever. It's up to the view to decide whether to colorize output or not, whether to show an underline that the user can click to jump to the error or not, etc. Basically the view is independent of the model, and provides functionality local only to its interaction context that the model shouldn't need to care about. As a bonus it's pluggable and thus easy to write new views.
- TheCoelacanth 11y ago
  > A compiler has to manage a lot of state too, but I've yet to hear compiler makers trying to figure out why they have so much logic in their controllers, and why their views are too big (because nobody would write an MVC compiler). No, but they do write entire books about how their parser uses recursive descent or LL(1) or about how they do code generation.

overgard 11y ago

> It's all about managing state and dependencies. Doesn't matter much for small apps but does when you have tons of people trying to work on the same thing. That literally applies to any program though. A compiler has to manage a lot of state too, but I've yet to hear compiler makers trying to figure out why they have so much logic in their controllers, and why their views are too big (because nobody would write an MVC compiler). > Besides, it's not like MVVM is a huge thing. It can be explained in a paragraph And yet there's like 500 blog posts about why you're doing it wrong, and how to do it better, etc. Of course, in truth it's not complicated, what makes it complicated is when it's applied in contexts that make little sense.

Arnavion 11y ago
>because nobody would write an MVC compiler Model - Input -> output format transformation View - input/output Controller - Drives the model And not much coupling between them except to pass data back and forth. Sounds like a regular compiler to me.
- overgard 11y ago
  You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. Just looking at what you said though: why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Also, claiming the view as input/output is pretty reductive. How do I represent a lexer as a view? More importantly, why would I want to? Fun experiment, find the views and controllers in here: https://github.com/llvm-mirror/clang https://github.com/llvm-mirror/clang
  - Arnavion 11y ago
    >You can make pretty much anything seem equivalent if you abstract it enough. You've basically just equated MVC with any program that does IO. I can't see how that's a useful thing to do. shrug MVC / MVVM is that simple. >why would you represent a transformation (something inherently a verb/action) as a model? "Model - Input -> output format transformation". It operates on models, it's not A model. Models are not limited to being data stores. Models are responsible for doing work, so-called business logic. Controllers / ViewModels work with Views to take in user input and apply it to the models, then take the updated model and give it back to the user. >How do I represent a lexer as a view? The lexer is part of the model. The view would be what the compiler uses for input/output: for a CLI compiler it would be the function that reads stdin or the filesystem + the function that writes to stdout and the filesystem, for a compiler hosted in an IDE or webpage would be the compiler library interface (ie: a programmatic way to give it files or strings and receive output + errors), and so on. Separate views that only know how to take in user input and display user output, interfacing with a common controller/viewmodel + model. Edit: Minor clarifications.
    - Arnavion 11y ago
      To clarify, an example of a non-MVC compiler would be something that expects to read a list of files from argv and expects to write to stdout. An example of a MVC compiler would be something that abstracts the act of compiling bytes into bytes from how it obtains those bytes or puts them out. I think gcc works like the former and clang like the latter? I'm not familiar with either. An example I am familiar with is the TypeScript transpiler - a "Compiler" class with a pluggable "Host" interface. There is one implementation of that host for each environment it can run in (in-memory, node.js, cscript.exe) that knows how to read files and write output. The compiler class would call host.writeFile(filename, contents) and it's up to the host whether to write that to a file, or a textarea in a web page, or pipe the string to another transpiler, or whatever. It's up to the view to decide whether to colorize output or not, whether to show an underline that the user can click to jump to the error or not, etc. Basically the view is independent of the model, and provides functionality local only to its interaction context that the model shouldn't need to care about. As a bonus it's pluggable and thus easy to write new views.
TheCoelacanth 11y ago
> A compiler has to manage a lot of state too, but I've yet to hear compiler makers trying to figure out why they have so much logic in their controllers, and why their views are too big (because nobody would write an MVC compiler). No, but they do write entire books about how their parser uses recursive descent or LL(1) or about how they do code generation.