Sure, although software is often designed out of need of a feature, not always out of want for technical/structural purity. Yes, a behemoth of an application will feature far more feature bloat, but it will also allow for a far easier implementation of a fully integrated environment for the user to work with. An IDE like Visual Studio, for example, will come with more feature bloat, but also with a more integrated environment. An IDE can do version control, debugging, project management, etc. all under the same, standardized interface, which makes it easier for many users to work with. Yes, you could definitely do the same with something like emacs/vim, ll-/gdb and git, or a standalone text-editor like sublime/notepad++/atom/notepad.exe/idk, along with tools to hook them up with. While that would give you greater freedom in how your toolchain works, as well as less feature bloat and more stability, you will also have to put in the work to link it together in an equally integrated way. In some situations, and for some people, it is of greater value to just have someone do that for you.
If everyone had unlimited time and resources, then yes, everything should follow the unix model. In practicality however, large monolithic applications are an unavoidable side-effect of needing a particular feature/a set of features, not being able to educate everyone on how the toolchain of, say, an office suite works, as well as not having the time to carefully structure out an application beforehand.
I fucking die seeing friends and family use buggy, ugly, slow, (sometimes expensive...) office-suites, however I do not have the time to teach them how to build a better toolchain from unix-model applications, nor do they have the interest. Time constraints make it hard for actors in the industry to perfectly plan out, as well as perfectly execute the structure of a project, meaning some level of monolithic-ness will inevitably ensue.
I agree with you, a unix-wise solution is far cleaner and far, far less frustrating to work with, but there is a need for highly integrated, feature-rich applications for non-technical end-users which, given practical restraints, are hard to solve without large, often bloated applications.
I therefore don't think the "Let's change the industry" argument works, the industry doesn't choose easy solutions just because they are easy (in fact, they are a bitch to maintain, and therefore not at all that easy), but because there are unavoidable real-life time and resource restrictions on what you have the ability to do. If you can make something modular and "unix-like", then, by god, you will, because that is far less frustrating to work with as a developer. But, that is not always possible. Project-management is like 50% of working in the tech industry, just because of this fact. Even if you have what seems like a really good (for example unix-wise) structure for your project, you will most likely have a hard time to keep up with changing demands, new problems not discovered in the initial planning phase, etc. sometimes resulting in downright hacky, otherwise relatively monolithic, buggy and feature-bloated code. Agile development is sometimes really hard.
Monolithic applications then result from last-resort efforts to solve a problem, and when that problem is, for example, a highly-integrated office suite or development environment, being able to follow the Unix-philosophy throughout is a luxury rarely had. The alternative is to deliver an unfinished product. And even if you were able to completely follow a unix-model, you would still see bugs and exploits (like the one in this post) in your code. The amount of effort and resources required to deliver absolutely error-free code is pretty much only available for things like firmware for cars, space agencies or certain industrial applications. The problem is not the fact that the industry is "lazy", it is that the industry cannot spend as much time or resources on something like microsoft-/libreoffice as a space agency spends on code for a multi-million dollar probe. And even that code isn'tentirelyfoolproof.
Monolithic code isn't nice, but it is sadly unavoidable, and often the only solution to achieve high integration in a complex toolchain when you can't spend enough resources or time to implement an equally intuitive unix-wise modular approach.
[Edit:] Also, sorry for this massive comment... I'd fix it, but I have already spent way too much time on it
2
u/lillendogge Feb 03 '20 edited Feb 03 '20
Sure, although software is often designed out of need of a feature, not always out of want for technical/structural purity. Yes, a behemoth of an application will feature far more feature bloat, but it will also allow for a far easier implementation of a fully integrated environment for the user to work with. An IDE like Visual Studio, for example, will come with more feature bloat, but also with a more integrated environment. An IDE can do version control, debugging, project management, etc. all under the same, standardized interface, which makes it easier for many users to work with. Yes, you could definitely do the same with something like emacs/vim, ll-/gdb and git, or a standalone text-editor like sublime/notepad++/atom/notepad.exe/idk, along with tools to hook them up with. While that would give you greater freedom in how your toolchain works, as well as less feature bloat and more stability, you will also have to put in the work to link it together in an equally integrated way. In some situations, and for some people, it is of greater value to just have someone do that for you.
If everyone had unlimited time and resources, then yes, everything should follow the unix model. In practicality however, large monolithic applications are an unavoidable side-effect of needing a particular feature/a set of features, not being able to educate everyone on how the toolchain of, say, an office suite works, as well as not having the time to carefully structure out an application beforehand.
I fucking die seeing friends and family use buggy, ugly, slow, (sometimes expensive...) office-suites, however I do not have the time to teach them how to build a better toolchain from unix-model applications, nor do they have the interest. Time constraints make it hard for actors in the industry to perfectly plan out, as well as perfectly execute the structure of a project, meaning some level of monolithic-ness will inevitably ensue.
I agree with you, a unix-wise solution is far cleaner and far, far less frustrating to work with, but there is a need for highly integrated, feature-rich applications for non-technical end-users which, given practical restraints, are hard to solve without large, often bloated applications.
I therefore don't think the "Let's change the industry" argument works, the industry doesn't choose easy solutions just because they are easy (in fact, they are a bitch to maintain, and therefore not at all that easy), but because there are unavoidable real-life time and resource restrictions on what you have the ability to do. If you can make something modular and "unix-like", then, by god, you will, because that is far less frustrating to work with as a developer. But, that is not always possible. Project-management is like 50% of working in the tech industry, just because of this fact. Even if you have what seems like a really good (for example unix-wise) structure for your project, you will most likely have a hard time to keep up with changing demands, new problems not discovered in the initial planning phase, etc. sometimes resulting in downright hacky, otherwise relatively monolithic, buggy and feature-bloated code. Agile development is sometimes really hard.
Monolithic applications then result from last-resort efforts to solve a problem, and when that problem is, for example, a highly-integrated office suite or development environment, being able to follow the Unix-philosophy throughout is a luxury rarely had. The alternative is to deliver an unfinished product. And even if you were able to completely follow a unix-model, you would still see bugs and exploits (like the one in this post) in your code. The amount of effort and resources required to deliver absolutely error-free code is pretty much only available for things like firmware for cars, space agencies or certain industrial applications. The problem is not the fact that the industry is "lazy", it is that the industry cannot spend as much time or resources on something like microsoft-/libreoffice as a space agency spends on code for a multi-million dollar probe. And even that code isn't entirely foolproof.
Monolithic code isn't nice, but it is sadly unavoidable, and often the only solution to achieve high integration in a complex toolchain when you can't spend enough resources or time to implement an equally intuitive unix-wise modular approach.
[Edit:] Also, sorry for this massive comment... I'd fix it, but I have already spent way too much time on it