7 ms·

> perhaps all of them (every single one) have not actually experienced writing an application without a framework I actually have written software without a fr

> perhaps all of them (every single one) have not actually experienced writing an application without a framework I actually have written software without a framework, so by this standard I feel qualified to comment. Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the label “framework”. Nevertheless even they exist within an overall architecture that starts to look like one, if you squint, and realise the enormous power of piping stdout around. However, many line-of-business applications do develop sufficient complexity, as the owner/operator adds new features to support their expanding operations, that the subsequent edifice either accretes random code into a horrifying fatberg of unmaintainability, or some wiser developer refactors substantial parts of the interface, business logic, persistence, and runtime configuration, effectively creating a framework within that application on which the logic and interface and so forth subsequently hang, and with a pinch of skill and luck, in a fashion that is more readily reasoned about and amended. Whether that informally-specified framework might be considered worthy of extraction into a unit of software for itself is another matter, and largely a case of programmer hubris.

Supermancho 4y ago
> Not all software has an implied framework within it. The definitions of "framework" are always a sticky issue. If you take "framework" at face value, it's minimally a set of idioms. "an essential supporting structure which other things are built on top of" - which necessarily includes a mental model of execution. This relates closely to why naming, in software development, is considered so difficult. All software has an inherent framework. First is the mental model and then the implementation. Implementation middleware to simplify utilizing these idioms or enforce them, are incidental. If you're lucky, you can derive some of the underlying design from documentation. Ironically, those who claim that they never use a framework are largely making implicit claims about what they consider a framework to be or have.
- inopinatus 4y ago
  Well, I don't disagree, and we could almost label that "framework zero", and also hence the reference to Unix utilities and their assumptions regarding stdin/out, but I am also taking a contextual cue from the article linked at the top which is clearly taking aim at large pre-chewed boluses of code such as Rails, Django, Drupal and so forth. I am just about old enough to have even toggled in a program on the front panel of a PDP-8 that my local university had kept around to occupy valuable floor space in their computing center. I wouldn't say I used a framework, but I was just a kid at the time, so it's possible that I did use a stepladder.
  - hmlongco 4y ago
    Really? Did my toggling on an 8e that ran as a controller for a COM (Computer Output Microfilm) "printer". Not saying that I could write code directly in octal... but I was pretty darn close. Of course, it helps when your assembly language consists of just eight instructions.
- vidarh 4y ago
  > The definitions of "framework" are always a sticky issue. Hence why the article defines what it means by framework, and by the definition in the article, software rarely has any implied frameworks within as one of the definition points is that there is code in the framework the user is not free to change. There certainly can be frameworks emerging within large projects, but by the definition in the article they're not problematic because they don't lock you in: You can change those pieces. You in particular ultimately remain in charge of the flow of control in the code. Those "frameworks" don't take away control and put you in a straightjacket. The article could perhaps have been framed better as "how to write a framework or framework-like thing which doesn't become a problem". Some thoughts might be: * Structure it as decoupled components where you can opt in and opt of different elements, including of control flow. E.g. Padrino - a Ruby web framework fits well here. You can pick and choose which ORM to use; you can opt in to a router, controller, admin interface, mailers, logging, caching, and view libraries, or not use them at all. You can start with plain Sinatra and add in bits of Padrino as and when you choose, or supply your own. * In particular, if possible, externalise the control of flow into replaceable components. Doing this alone can often be enough to get you out of the straight-jacket of "frameworks as defined by the article" * Allow users to override/replace all components rather by defining clear interfaces and not assuming you can call hard-code calls between the different components. Padrino again fits well there. So did e.g. Qmail treated as a "framework for building a mail server" ("nobody" used pure Qmail, but Qmail defined the interfaces between each individual program which made up the full system, so you could replace every single bit step by step). In particular there should be no "magic" glue which there isn't a well defined way of tearing out.
- Ma8ee 4y ago
  An important part of being a framework is that it is made for reusability, similar to a library. Just because your code has some thought out structure/architecture doesn't mean that it has an inherent framework.
  - Supermancho 4y ago
    > An important part of being a framework is that it is made for reusability I might have agreed with this at one time. A dedicated "framework" has documentation and additional software to shortcut assumptions, but a coherent design isn't different enough from the rules that guide any given framework to be a distinction. The biggest differences are how mature the frameworks are in breadth of documentation, guidance in how to achieve constrained goals (there is no "everything" framework), and supporting software to shortcut boilerplate.
valenterry 4y ago
> or some wiser developer refactors substantial parts of the interface, business logic, persistence, and runtime configuration, effectively creating a framework within that application That's not what people commonly understand as a "framework". Nor is it a helpful definition because then where does "abstracting things" and "framework" start and end? No, the main difference between frameworks and what you describe is the IOC. In the framework world, the framework calls you and then something happens behind the scenes until the framework decides to call some code that you provided via the frameworks API. With libraries it's the other way around: you call the library and then you do something with the result and then use it to call the library again and so on until you have the desired outcome. The difference is, for example, that you can call the library and when it returns something to you, you can inspect it and choose to ignore it. You can do so in an arbitrary way. In the framework case, if the framework does not provide any way for you to interact with it in the way you want, then you are screwed.
- inopinatus 4y ago
  Sorry, I don't accept this very mechanical definition; not only is it a needlessly narrow one, it's downright meaningless in some paradigms, such as when implementing coroutines via continuations, but that doesn't mean you can't have frameworks in Scheme. Conversely, we could describe tuplespaces (a la Linda), or many event- or interrupt- driven systems (like an Ethernet port), as an inversion of control, but whether they're frameworks or not would be an open question, and indeed in the end almost everything happening inside a modern computer consists of one element calling back to another, up and down a stack. Heck, it's not even true of some of those specifically called out in the article above. For example, I've written programs that use Rails as a library - or rather, suite of libraries - of functions and classes to be called, but anyone suggesting that Rails is somehow "not a framework", on the flimsy grounds that it did not dictate the flow of control, is gonna get some funny looks at morning standup. But the greater problem is that narrow, mechanical definitions omit purpose, and talking about software without purpose being front-and-center becomes rapidly theological. If you're wondering what I mean by that, look up the wikipedia article for "Software framework", scroll through its desultory talk page, and recognize the inevitability of the boilerplate it got stuck with: "This section is written like a personal reflection, personal essay, or argumentative essay that states a Wikipedia editor's personal feelings".
flohofwoe 4y ago
> Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the label “framework”. The C standard library is exactly that though, a framework for writing UNIX command line tools :) (for anything else it's much less useful)
- vidarh 4y ago
  > The C standard library is exactly that though, a framework for writing UNIX command line tools :) It doesn't fit the term as used in the article at all, though, in that it doesn't dictate the overall program's flow of control.
  - flohofwoe 4y ago
    The overall program flow in this case is: shell => CRT => main(argc, argv) => exit code => shell (to me, the CRT and C standard lib are not strictly separate, although that's debatable of course)
    - vidarh 4y ago
      Except none of these steps are dictated by the C standard library (some may be dictated by some libc's) EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of course usually enter via main() you don't have to. You decide the control flow.
      - pjmlp 4y ago
        CRT also does stuff like floating point emulation, loading dynamic libraries on demand instead of at load time (e.g on AIX and Windows), handling threads post C11, or runtime checks in hardened code.
marcus_holmes 4y ago
But this is fine. The framework that the organisation develops for itself is designed to solve the problems that the organisation has. As TFA says, one of the main problems with frameworks is that the maintainers of the framework don't share your organisation's goals, and therefore will have different problems to solve.
- strogonoff 4y ago
  While one can think of every problem as a snowflake situation never encountered by anyone before, outside of its core business domain an organization (particularly a non-technical one) rarely faces truly unique challenges. Most of the time one can also decompose the solution into a number of well-known problems that had been solved before. For example, in an overall solution for some snowflake business challenge you may see components such as an order taking system, a customer support center, a CRM, an ERP—and on another level patterns like a statically rendered site, an SPA, a “classic” content-driven site, and so on. In my opinion, being blind to these opportunities and intent on putting the entire solution together without any delegation of control flow smells of lazy architectural thinking and/or job security. The exact decomposition would depend on business specifics, foreseeable future evolution of the business, team capabilities and other factors, but as a result you’d be able to radically lighten the implementation and indeed maintenance burden with a strategic use of frameworks or even lightly customized CMS.
  - marcus_holmes 4y ago
    This simply isn't true for, well, every project I've been on. There is always some unique wrinkle in the requirements that means this project needs a different approach. SAP is the classic example of this: SAP implements vanilla business processes (with lots of flexibility built in). Yet every single business implementing SAP needs extensive customisation and modification to make it fit their business processes. Some have spent millions or tens of millions trying to make SAP fit their business and failed. In your terms; every business is a snowflake. You cannot create (for example) an order taking system that will fit all businesses. Or even "all businesses for whom order taking is not part of their core business domain". Only "those businesses who are willing and able to make their order-taking process fit your system".
NoGravitas 4y ago
> Whether that informally-specified framework might be considered worthy of extraction into a unit of software for itself is another matter, and largely a case of programmer hubris. The interesting thing to me is that this is how Django, one of the canonical big backend frameworks, came into being. It was based on what a newspaper's website's staff were actually using in practice.

Supermancho 4y ago

> Not all software has an implied framework within it. The definitions of "framework" are always a sticky issue. If you take "framework" at face value, it's minimally a set of idioms. "an essential supporting structure which other things are built on top of" - which necessarily includes a mental model of execution. This relates closely to why naming, in software development, is considered so difficult. All software has an inherent framework. First is the mental model and then the implementation. Implementation middleware to simplify utilizing these idioms or enforce them, are incidental. If you're lucky, you can derive some of the underlying design from documentation. Ironically, those who claim that they never use a framework are largely making implicit claims about what they consider a framework to be or have.

inopinatus 4y ago
Well, I don't disagree, and we could almost label that "framework zero", and also hence the reference to Unix utilities and their assumptions regarding stdin/out, but I am also taking a contextual cue from the article linked at the top which is clearly taking aim at large pre-chewed boluses of code such as Rails, Django, Drupal and so forth. I am just about old enough to have even toggled in a program on the front panel of a PDP-8 that my local university had kept around to occupy valuable floor space in their computing center. I wouldn't say I used a framework, but I was just a kid at the time, so it's possible that I did use a stepladder.
- hmlongco 4y ago
  Really? Did my toggling on an 8e that ran as a controller for a COM (Computer Output Microfilm) "printer". Not saying that I could write code directly in octal... but I was pretty darn close. Of course, it helps when your assembly language consists of just eight instructions.
vidarh 4y ago
> The definitions of "framework" are always a sticky issue. Hence why the article defines what it means by framework, and by the definition in the article, software rarely has any implied frameworks within as one of the definition points is that there is code in the framework the user is not free to change. There certainly can be frameworks emerging within large projects, but by the definition in the article they're not problematic because they don't lock you in: You can change those pieces. You in particular ultimately remain in charge of the flow of control in the code. Those "frameworks" don't take away control and put you in a straightjacket. The article could perhaps have been framed better as "how to write a framework or framework-like thing which doesn't become a problem". Some thoughts might be: * Structure it as decoupled components where you can opt in and opt of different elements, including of control flow. E.g. Padrino - a Ruby web framework fits well here. You can pick and choose which ORM to use; you can opt in to a router, controller, admin interface, mailers, logging, caching, and view libraries, or not use them at all. You can start with plain Sinatra and add in bits of Padrino as and when you choose, or supply your own. * In particular, if possible, externalise the control of flow into replaceable components. Doing this alone can often be enough to get you out of the straight-jacket of "frameworks as defined by the article" * Allow users to override/replace all components rather by defining clear interfaces and not assuming you can call hard-code calls between the different components. Padrino again fits well there. So did e.g. Qmail treated as a "framework for building a mail server" ("nobody" used pure Qmail, but Qmail defined the interfaces between each individual program which made up the full system, so you could replace every single bit step by step). In particular there should be no "magic" glue which there isn't a well defined way of tearing out.
Ma8ee 4y ago
An important part of being a framework is that it is made for reusability, similar to a library. Just because your code has some thought out structure/architecture doesn't mean that it has an inherent framework.
- Supermancho 4y ago
  > An important part of being a framework is that it is made for reusability I might have agreed with this at one time. A dedicated "framework" has documentation and additional software to shortcut assumptions, but a coherent design isn't different enough from the rules that guide any given framework to be a distinction. The biggest differences are how mature the frameworks are in breadth of documentation, guidance in how to achieve constrained goals (there is no "everything" framework), and supporting software to shortcut boilerplate.

valenterry 4y ago

> or some wiser developer refactors substantial parts of the interface, business logic, persistence, and runtime configuration, effectively creating a framework within that application That's not what people commonly understand as a "framework". Nor is it a helpful definition because then where does "abstracting things" and "framework" start and end? No, the main difference between frameworks and what you describe is the IOC. In the framework world, the framework calls you and then something happens behind the scenes until the framework decides to call some code that you provided via the frameworks API. With libraries it's the other way around: you call the library and then you do something with the result and then use it to call the library again and so on until you have the desired outcome. The difference is, for example, that you can call the library and when it returns something to you, you can inspect it and choose to ignore it. You can do so in an arbitrary way. In the framework case, if the framework does not provide any way for you to interact with it in the way you want, then you are screwed.

inopinatus 4y ago
Sorry, I don't accept this very mechanical definition; not only is it a needlessly narrow one, it's downright meaningless in some paradigms, such as when implementing coroutines via continuations, but that doesn't mean you can't have frameworks in Scheme. Conversely, we could describe tuplespaces (a la Linda), or many event- or interrupt- driven systems (like an Ethernet port), as an inversion of control, but whether they're frameworks or not would be an open question, and indeed in the end almost everything happening inside a modern computer consists of one element calling back to another, up and down a stack. Heck, it's not even true of some of those specifically called out in the article above. For example, I've written programs that use Rails as a library - or rather, suite of libraries - of functions and classes to be called, but anyone suggesting that Rails is somehow "not a framework", on the flimsy grounds that it did not dictate the flow of control, is gonna get some funny looks at morning standup. But the greater problem is that narrow, mechanical definitions omit purpose, and talking about software without purpose being front-and-center becomes rapidly theological. If you're wondering what I mean by that, look up the wikipedia article for "Software framework", scroll through its desultory talk page, and recognize the inevitability of the boilerplate it got stuck with: "This section is written like a personal reflection, personal essay, or argumentative essay that states a Wikipedia editor's personal feelings".

flohofwoe 4y ago

> Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the label “framework”. The C standard library is exactly that though, a framework for writing UNIX command line tools :) (for anything else it's much less useful)

vidarh 4y ago
> The C standard library is exactly that though, a framework for writing UNIX command line tools :) It doesn't fit the term as used in the article at all, though, in that it doesn't dictate the overall program's flow of control.
- flohofwoe 4y ago
  The overall program flow in this case is: shell => CRT => main(argc, argv) => exit code => shell (to me, the CRT and C standard lib are not strictly separate, although that's debatable of course)
  - vidarh 4y ago
    Except none of these steps are dictated by the C standard library (some may be dictated by some libc's) EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of course usually enter via main() you don't have to. You decide the control flow.
    - pjmlp 4y ago
      CRT also does stuff like floating point emulation, loading dynamic libraries on demand instead of at load time (e.g on AIX and Windows), handling threads post C11, or runtime checks in hardened code.

marcus_holmes 4y ago

But this is fine. The framework that the organisation develops for itself is designed to solve the problems that the organisation has. As TFA says, one of the main problems with frameworks is that the maintainers of the framework don't share your organisation's goals, and therefore will have different problems to solve.

strogonoff 4y ago
While one can think of every problem as a snowflake situation never encountered by anyone before, outside of its core business domain an organization (particularly a non-technical one) rarely faces truly unique challenges. Most of the time one can also decompose the solution into a number of well-known problems that had been solved before. For example, in an overall solution for some snowflake business challenge you may see components such as an order taking system, a customer support center, a CRM, an ERP—and on another level patterns like a statically rendered site, an SPA, a “classic” content-driven site, and so on. In my opinion, being blind to these opportunities and intent on putting the entire solution together without any delegation of control flow smells of lazy architectural thinking and/or job security. The exact decomposition would depend on business specifics, foreseeable future evolution of the business, team capabilities and other factors, but as a result you’d be able to radically lighten the implementation and indeed maintenance burden with a strategic use of frameworks or even lightly customized CMS.
- marcus_holmes 4y ago
  This simply isn't true for, well, every project I've been on. There is always some unique wrinkle in the requirements that means this project needs a different approach. SAP is the classic example of this: SAP implements vanilla business processes (with lots of flexibility built in). Yet every single business implementing SAP needs extensive customisation and modification to make it fit their business processes. Some have spent millions or tens of millions trying to make SAP fit their business and failed. In your terms; every business is a snowflake. You cannot create (for example) an order taking system that will fit all businesses. Or even "all businesses for whom order taking is not part of their core business domain". Only "those businesses who are willing and able to make their order-taking process fit your system".

NoGravitas 4y ago

> Whether that informally-specified framework might be considered worthy of extraction into a unit of software for itself is another matter, and largely a case of programmer hubris. The interesting thing to me is that this is how Django, one of the canonical big backend frameworks, came into being. It was based on what a newspaper's website's staff were actually using in practice.