6 ms·

Why learn frameworks when you can build everything from scratch and become a true carpenter ("building software using general purpose frameworks doesn’t make yo

by V-2 10y ago

Why learn frameworks when you can build everything from scratch and become a true carpenter ("building software using general purpose frameworks doesn’t make you a coder or a programmer any more than putting together a pre-built house makes you a carpenter"). "These people [framework creators] seems to be infatuated by the though of having other people follow their “way of doing things”, becoming some kind of PHP community leaders, and having other people use their latest “hip” Open Source tools..." How lame of these people. The problem is, if I inherit an application created with a well-known framework, I'll have a much easier time figuring out what is what, and looking for answers when something goes awry. On the other hand, if the codebase has been written from scratch by Greg, a real carpenter of a programmer, who is no longer with the company, then good luck. I'm at his mercy entirely. I'll be having his "way of doing things" for dinner whether I want it or not, the only difference is that I won't have a community of other people in the same situation. This aspect isn't addressed by the author at all, although he found just enough time to provide us with a psychological analysis of framework authors and their narcissist motivations :)

MustardTiger 10y ago
I wonder why this mentality only exists with web devs. Everywhere else, someone writing software is considered normal, not some scary problem. Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided.". It is just normal. Perhaps the low barrier to entry and corresponding low average experience of web developers plays a part in this mentality.
- V-2 10y ago
  "I wonder why this mentality only exists with web devs [...] Nobody sees any other kind of application [...]" Your premise - on which you based a slightly convoluted ad hominem, implying lack of professional experience on my part - is false to start with. While I did have some PHP experience, I'm not really a web dev. I'm a mobile (Android) and desktop (Windows) developer. Having said that, with web applications you typically have more moving parts and layers to integrate than in case of a client app.
- nix0n 10y ago
  I think some of it has to do with the languages involved. I find the type systems of C/C++/Java to be helpful in figuring out what a piece of code does, as compared to the type systems of Python/PHP/Ruby where it's more difficult to tell what a variable contains. Frameworks help solve this problem because you can infer what type of data you've got by looking at what method it's coming from and where it's being used.
- squeaky-clean 10y ago
  Because 99% of web dev code is the same stuff and 99% of the time it doesn't need to be rewritten. You don't need your own implementation of URL rules, user authentication and roles, testing suites, database driver or ORM, request parsing, csrf protection, session handling.... I can buy a book on Django/Flask/Symfony/Spring/Express. I can't buy a book about your homebrew 30k LOC "non-framework" which does all the same things plus an additional customized CRUD layer. > Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided." If a large majority of the code you've been given to maintain could instead be handled by well known, well documented project with thousands of eyes fixing bugs and adding features, you would probably say the same thing. Imagine inheriting a java codebase of a simple POS system with a UI. Except instead of using Swing or AWT or I don't know what else, the entire UI is custom written in OpenGL. And instead of using any of the standard sorting or ArrayList implementation, they write their own, which are similar, but not identical (and often have 0 tests).
  - MustardTiger 10y ago
    This whole argument is based on two false assumptions. One, that shitty broken web frameworks like cakephp and zend are "well known, well documented project with thousands of eyes fixing bugs and adding features" rather than the horrible messes they actually are. And two, that web apps are the only software to share any common aspects. Every lame VB+Access app I ever saw had more in common than two randomly chosen web apps. Yet nobody needed a "framework" to enforce worst practices and ensure that everything was done inefficiently and unmaintainably.
- Glyptodon 10y ago
  I think you're right that the propensity of non-technical organizations to try and hire unqualified people at below market rates leads to a particular problem in web development. But I think people programming other types of software have structure that comes from elsewhere. For example, if you write plain Android or iOS apps, in may ways there's a kind of standard app architecture that's just used and taken for granted. Sure, it can be muddled, but only so much for the most part. And the same is largely true for desktop applications, too, when they're built with IDEs that impose structure or even things like Unity. The thing that's extra weird about this is that most web apps have to reinvent the wheel in ways that desktop software doesn't.
- arcatek 10y ago
  Not sure why you think it doesn't happen in other fields. Every time I spoke with a software developer, they were constantly cursing the architecture of the code they had to dealt with.
- kbenson 10y ago
  Because the myriad ways public people interact with your code through HTTP and routes starts to rival the complexity of getting crypto code right, with a lot of the same sorts of downsides (which is to say problems often lead to security issues, and very few people are capable of reasoning about all the implications of the decisions made). I would suggest someone not roll their own framework (which is essentially creating a framework of their own at some level) for the same reasons I would suggest someone not roll their own crypto. The upside is relatively minuscule compared to the downsides, IMO. > Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided.". Yes, they do. If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. If not lamenting that you're at their mercy, at least cursing them for imposing a requirement of some level of strength that you use what is very likely to be a substandard implementation of what you can find freely available. So, you either replace it with something less likely to cause the odd problem later (and deal with all the testing to make sure you didn't introduce a bug, and you probably did) or deal with those odd problems ("what do you mean we aren't conforming to TLS correctly? Why haven't we seen this until now?").
  - deleted 10y ago
    [deleted]
  - MustardTiger 10y ago
    > If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. No, why would it? What HTTP client framework am I supposed to be wishing they used?
    - kbenson 10y ago
      Maybe cURL? Some other one I don't know of (I know the ones in my preferred languages). Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain? Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usually not the intricacies of HTTP negotiation, or some other well understood and supplied need).
romaniv 10y ago
> The problem is, if I inherit an application created with a well-known framework, I'll have a much easier time figuring out what is what, and looking for answers when something goes awry. Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often. Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things. Whether or not it's easy depends on the quality of code and documentation. Given equal size of the code that does the job, reasonably written framework-free code is probably going to be easier to understand, because it doesn't have external dependencies. I never understood why after years of dealing with dozens of competing and rather poorly constructed web frameworks in Java, PHP and now JavaScript people still believe that those things have some kind of inherent value. Remember Struts, anyone? PHP Nuke? WebForms? Would you rather maintain something that used either of those over something that was written in vanilla Java/PHP/C#?
- pavel_lishin 10y ago
  > Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things. I don't think this is true. If you're learning a framework, you have the entire community - which has probably written blog posts, asked and answered StackOverflow questions, and likely has some members who can answer your question at odd hours. If you're learning one person's approach, you have exactly one person you can ask about it: Greg. Who might quit, or go on paternity leave, or get hit by a bus. If you're lucky, you might also have some coworkers who understand parts of that system.
  - romaniv 10y ago
    >If you're learning a framework, you have the entire community - which has probably written blog posts, asked and answered StackOverflow questions, and likely has some members who can answer your question at odd hours. You're assuming that learning the framework will make understanding actual workload code completely effortless. In non-trivial applications this is never the case. You still have to understand... stuff like this, for example: http://mikehadlow.blogspot.com/2010/04/custom-aspnet-mvc-model-binder-for.html http://mikehadlow.blogspot.com/2010/04/custom-aspnet-mvc-mod... When someone writes code from scratch the quality of the code depends on their ability. When someone uses a framework the quality of the code depends on their ability, the quality of the framework and fitness of the framework for a particular problem. If the developer is not very experienced but sufficiently disciplined, and the framework is well-designed and fits the chosen task well, than yes, you end up with better code. If any of those conditions fail, the code is usually just as bad or worse than vanilla.
brightball 10y ago
The underlying issue is that PHP is bad at frameworks and because of that there are dozens of them. If there was one, clear, dominant framework it would be one thing...but there's not so investing in using any particular PHP framework is just about as risky of a proposition as rolling your own.
- paulryanrogers 10y ago
  This is likely more an artifact of the PHP community and philosophy being focused on ease of use and deployment, circa early 2000's. Consider that Ruby has a few dominant frameworks--like Rails--built on a language with read-hostile features like monkey patching. Unlike Python Ruby often has many ways of doing things, and that's reflected in community gems. (EDIT: swipe-typing fail.) Regardless, there has been some coalescing around more modern PHP frameworks like Laravel recently.
  - brightball 10y ago
    That's true. One of the things that I find particularly interesting is the response to this with PHP vs that of Go. As I've picked up Go, the distinct impression that I've gotten is one of total anti-framework with the idea of just pulling in the parts you needs for what you're doing. Even a general disdain for using anything that isn't in the stdlib. That seems exactly what what is being advocated for here but with PHP and Composer instead yet the response is reversed.
    - joesmo 10y ago
      A stupid idea is stupid regardless of language. Whether the community sees that or not also reflects on the community.
throwanem 10y ago
> On the other hand, if the codebase has been written from scratch by Greg, a real carpenter of a programmer, who is no longer with the company, then good luck. I'm at his mercy entirely. You're at his mercy if he used a framework, too. There's nothing to require that he used it in a sensible way. The only difference is that now you get to discover the innermost details of the framework, too, at the same time you're trying to figure out what Greg was doing, and you also get to figure out which is which.

by V-2 10y ago

MustardTiger 10y ago

I wonder why this mentality only exists with web devs. Everywhere else, someone writing software is considered normal, not some scary problem. Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided.". It is just normal. Perhaps the low barrier to entry and corresponding low average experience of web developers plays a part in this mentality.

V-2 10y ago
"I wonder why this mentality only exists with web devs [...] Nobody sees any other kind of application [...]" Your premise - on which you based a slightly convoluted ad hominem, implying lack of professional experience on my part - is false to start with. While I did have some PHP experience, I'm not really a web dev. I'm a mobile (Android) and desktop (Windows) developer. Having said that, with web applications you typically have more moving parts and layers to integrate than in case of a client app.
nix0n 10y ago
I think some of it has to do with the languages involved. I find the type systems of C/C++/Java to be helpful in figuring out what a piece of code does, as compared to the type systems of Python/PHP/Ruby where it's more difficult to tell what a variable contains. Frameworks help solve this problem because you can infer what type of data you've got by looking at what method it's coming from and where it's being used.
squeaky-clean 10y ago
Because 99% of web dev code is the same stuff and 99% of the time it doesn't need to be rewritten. You don't need your own implementation of URL rules, user authentication and roles, testing suites, database driver or ORM, request parsing, csrf protection, session handling.... I can buy a book on Django/Flask/Symfony/Spring/Express. I can't buy a book about your homebrew 30k LOC "non-framework" which does all the same things plus an additional customized CRUD layer. > Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided." If a large majority of the code you've been given to maintain could instead be handled by well known, well documented project with thousands of eyes fixing bugs and adding features, you would probably say the same thing. Imagine inheriting a java codebase of a simple POS system with a UI. Except instead of using Swing or AWT or I don't know what else, the entire UI is custom written in OpenGL. And instead of using any of the standard sorting or ArrayList implementation, they write their own, which are similar, but not identical (and often have 0 tests).
- MustardTiger 10y ago
  This whole argument is based on two false assumptions. One, that shitty broken web frameworks like cakephp and zend are "well known, well documented project with thousands of eyes fixing bugs and adding features" rather than the horrible messes they actually are. And two, that web apps are the only software to share any common aspects. Every lame VB+Access app I ever saw had more in common than two randomly chosen web apps. Yet nobody needed a "framework" to enforce worst practices and ensure that everything was done inefficiently and unmaintainably.
Glyptodon 10y ago
I think you're right that the propensity of non-technical organizations to try and hire unqualified people at below market rates leads to a particular problem in web development. But I think people programming other types of software have structure that comes from elsewhere. For example, if you write plain Android or iOS apps, in may ways there's a kind of standard app architecture that's just used and taken for granted. Sure, it can be muddled, but only so much for the most part. And the same is largely true for desktop applications, too, when they're built with IDEs that impose structure or even things like Unity. The thing that's extra weird about this is that most web apps have to reinvent the wheel in ways that desktop software doesn't.
arcatek 10y ago
Not sure why you think it doesn't happen in other fields. Every time I spoke with a software developer, they were constantly cursing the architecture of the code they had to dealt with.
kbenson 10y ago
Because the myriad ways public people interact with your code through HTTP and routes starts to rival the complexity of getting crypto code right, with a lot of the same sorts of downsides (which is to say problems often lead to security issues, and very few people are capable of reasoning about all the implications of the decisions made). I would suggest someone not roll their own framework (which is essentially creating a framework of their own at some level) for the same reasons I would suggest someone not roll their own crypto. The upside is relatively minuscule compared to the downsides, IMO. > Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided.". Yes, they do. If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. If not lamenting that you're at their mercy, at least cursing them for imposing a requirement of some level of strength that you use what is very likely to be a substandard implementation of what you can find freely available. So, you either replace it with something less likely to cause the odd problem later (and deal with all the testing to make sure you didn't introduce a bug, and you probably did) or deal with those odd problems ("what do you mean we aren't conforming to TLS correctly? Why haven't we seen this until now?").
- deleted 10y ago
  [deleted]
- MustardTiger 10y ago
  > If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. No, why would it? What HTTP client framework am I supposed to be wishing they used?
  - kbenson 10y ago
    Maybe cURL? Some other one I don't know of (I know the ones in my preferred languages). Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain? Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usually not the intricacies of HTTP negotiation, or some other well understood and supplied need).

romaniv 10y ago

> The problem is, if I inherit an application created with a well-known framework, I'll have a much easier time figuring out what is what, and looking for answers when something goes awry. Unless they spend most of their code fighting the framework to accomplish their actual task. Which happens rather often. Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things. Whether or not it's easy depends on the quality of code and documentation. Given equal size of the code that does the job, reasonably written framework-free code is probably going to be easier to understand, because it doesn't have external dependencies. I never understood why after years of dealing with dozens of competing and rather poorly constructed web frameworks in Java, PHP and now JavaScript people still believe that those things have some kind of inherent value. Remember Struts, anyone? PHP Nuke? WebForms? Would you rather maintain something that used either of those over something that was written in vanilla Java/PHP/C#?

pavel_lishin 10y ago
> Not to mention that learning a new framework is not fundamentally different from learning some person's approach to doing things. I don't think this is true. If you're learning a framework, you have the entire community - which has probably written blog posts, asked and answered StackOverflow questions, and likely has some members who can answer your question at odd hours. If you're learning one person's approach, you have exactly one person you can ask about it: Greg. Who might quit, or go on paternity leave, or get hit by a bus. If you're lucky, you might also have some coworkers who understand parts of that system.
- romaniv 10y ago
  >If you're learning a framework, you have the entire community - which has probably written blog posts, asked and answered StackOverflow questions, and likely has some members who can answer your question at odd hours. You're assuming that learning the framework will make understanding actual workload code completely effortless. In non-trivial applications this is never the case. You still have to understand... stuff like this, for example: http://mikehadlow.blogspot.com/2010/04/custom-aspnet-mvc-model-binder-for.html http://mikehadlow.blogspot.com/2010/04/custom-aspnet-mvc-mod... When someone writes code from scratch the quality of the code depends on their ability. When someone uses a framework the quality of the code depends on their ability, the quality of the framework and fitness of the framework for a particular problem. If the developer is not very experienced but sufficiently disciplined, and the framework is well-designed and fits the chosen task well, than yes, you end up with better code. If any of those conditions fail, the code is usually just as bad or worse than vanilla.

brightball 10y ago

The underlying issue is that PHP is bad at frameworks and because of that there are dozens of them. If there was one, clear, dominant framework it would be one thing...but there's not so investing in using any particular PHP framework is just about as risky of a proposition as rolling your own.

paulryanrogers 10y ago
This is likely more an artifact of the PHP community and philosophy being focused on ease of use and deployment, circa early 2000's. Consider that Ruby has a few dominant frameworks--like Rails--built on a language with read-hostile features like monkey patching. Unlike Python Ruby often has many ways of doing things, and that's reflected in community gems. (EDIT: swipe-typing fail.) Regardless, there has been some coalescing around more modern PHP frameworks like Laravel recently.
- brightball 10y ago
  That's true. One of the things that I find particularly interesting is the response to this with PHP vs that of Go. As I've picked up Go, the distinct impression that I've gotten is one of total anti-framework with the idea of just pulling in the parts you needs for what you're doing. Even a general disdain for using anything that isn't in the stdlib. That seems exactly what what is being advocated for here but with PHP and Composer instead yet the response is reversed.
  - joesmo 10y ago
    A stupid idea is stupid regardless of language. Whether the community sees that or not also reflects on the community.

throwanem 10y ago

> On the other hand, if the codebase has been written from scratch by Greg, a real carpenter of a programmer, who is no longer with the company, then good luck. I'm at his mercy entirely. You're at his mercy if he used a framework, too. There's nothing to require that he used it in a sensible way. The only difference is that now you get to discover the innermost details of the framework, too, at the same time you're trying to figure out what Greg was doing, and you also get to figure out which is which.