4 ms·

This discussion reminds me of one of my favorite quotes: "form is liberating". I always associated this with the sculptor Henry Moore, but the beauty of the ide

This discussion reminds me of one of my favorite quotes: "form is liberating". I always associated this with the sculptor Henry Moore, but the beauty of the idea is that it can be applied to all sorts of domains, whence it's also associated with Brook's Mythical Man Month about software development. The association here is that frameworks are "form". One might intuitively think that form/frameworks is/are constraining rather than liberating, but per the sculptural analogy the roughed-out shape provided by the framework liberates you to concentrate on the details rather than suffer from analysis-paralysis when there is too much freedom of approach (just a large block of marble from which you might sculpt literally anything). But it depends on the scope and nature of what you are trying to do ... If your problem fits withing the scope/form of the framework, and your value-add is in the details, then using a framework, all else considered, make sense. Alternatively, when you are trying to do something outside of the norms of gentrified frameworks, then the flexibility of libraries (or ultimately a blank sheet of paper) is what is called for. Of course, the devil is in the details... a poorly designed framework may be TOO constraining and not provide enough flexibility to be widely applicable, while poorly designed libraries may be overly restrictive due to poorly designed APIs that don't place nice with other libraries or the data structures you'd like to use.

chrisan 7y ago
1 more plus for the form of frameworks. People on your team must be on the same page and work within that form. If everyone is left to their own devices you will get a lot of friction when going into parts of the code you did not create yourself. I like to think of frameworks like a kitchen. The chef sets the menu and everyone works to produce how the chef thought it should be. Sure sometimes you will run into things that you fight the framework, but a good framework normally allows a "raw" way of doing it "by hand" instead of the sugary framework way that "just works (most of the time)". But most of the time it does work out fine and you can hop between other's proejcts/parts of the code and have instant familiarity and intent
- deleted 7y ago
  [deleted]
dkarl 7y ago
The devil is sometimes in the large as well. Form changes — code that used to run while generating a web page now runs in a REST service. Code that used to run in a REST service now runs as a FAAS. Code that used to run in a FAAS now runs in a stream processor. Your framework could tie you to a specific form, forcing you to implement your FAAS by posting each request to a REST service, or forcing you to implement your stream processor by posting each event to a FAAS. Or you can liberate your code from form by making sure that nothing important about it depends on a form-specific framework.
- Townley 7y ago
  True, but all code ages out, and I wouldn’t expect the average LAMP stack site to have adjusted to the REST-powered react world any better than a rails app would. When use cases change, huge parts of a code base should be rewritten (otherwise it was duplicated work to begin with) That said: good, modular, well-developed frameworks evolve alongside their use cases. Django with DjangoRestFramework is an excellent choice for many API use cases, and the migration path is about as painless a major architectural overhaul can be.
  - dkarl 7y ago
    It shouldn't need to be rewritten. The same Python code can be utilized in all of those different forms, unless you've tied yourself to a framework for functionality that needs to be used in the new context, i.e., for functionality that is not form-specific. If you've fallen into the trap of thinking a specific form is eternal -- for example, if you've subconsciously identified "our back end == our REST services" and therefore "data serialization/deserialization, metrics, and data storage access should and will be done only in the REST services" then you might have relied on a REST service framework for that functionality. Then when you want to move functionality to an AWS Lambda or a Spark streaming job, you find yourself forced to choose between running a REST framework inside the Lambda or Spark streaming job (which will be hacky, if it works at all, since frameworks want to own the application lifecycle and be configured via specific mechanisms) or writing and maintaining a duplicate implementation of all your data serialization/deserialization code, metrics configs, S3 configs, etc. I don't mean to say it's a disaster if you end up doing that, but it's a cost that will tend to hold you back from doing the right thing and make you persist with hacks and band-aids longer than you would have if you were free to change. > good, modular, well-developed frameworks evolve alongside their use cases. Django with DjangoRestFramework is an excellent choice for many API use cases That's a very modest change. It's still a long-lived service doing request/response over HTTP.

chrisan 7y ago

1 more plus for the form of frameworks. People on your team must be on the same page and work within that form. If everyone is left to their own devices you will get a lot of friction when going into parts of the code you did not create yourself. I like to think of frameworks like a kitchen. The chef sets the menu and everyone works to produce how the chef thought it should be. Sure sometimes you will run into things that you fight the framework, but a good framework normally allows a "raw" way of doing it "by hand" instead of the sugary framework way that "just works (most of the time)". But most of the time it does work out fine and you can hop between other's proejcts/parts of the code and have instant familiarity and intent

deleted 7y ago
[deleted]

dkarl 7y ago

The devil is sometimes in the large as well. Form changes — code that used to run while generating a web page now runs in a REST service. Code that used to run in a REST service now runs as a FAAS. Code that used to run in a FAAS now runs in a stream processor. Your framework could tie you to a specific form, forcing you to implement your FAAS by posting each request to a REST service, or forcing you to implement your stream processor by posting each event to a FAAS. Or you can liberate your code from form by making sure that nothing important about it depends on a form-specific framework.

Townley 7y ago
True, but all code ages out, and I wouldn’t expect the average LAMP stack site to have adjusted to the REST-powered react world any better than a rails app would. When use cases change, huge parts of a code base should be rewritten (otherwise it was duplicated work to begin with) That said: good, modular, well-developed frameworks evolve alongside their use cases. Django with DjangoRestFramework is an excellent choice for many API use cases, and the migration path is about as painless a major architectural overhaul can be.
- dkarl 7y ago
  It shouldn't need to be rewritten. The same Python code can be utilized in all of those different forms, unless you've tied yourself to a framework for functionality that needs to be used in the new context, i.e., for functionality that is not form-specific. If you've fallen into the trap of thinking a specific form is eternal -- for example, if you've subconsciously identified "our back end == our REST services" and therefore "data serialization/deserialization, metrics, and data storage access should and will be done only in the REST services" then you might have relied on a REST service framework for that functionality. Then when you want to move functionality to an AWS Lambda or a Spark streaming job, you find yourself forced to choose between running a REST framework inside the Lambda or Spark streaming job (which will be hacky, if it works at all, since frameworks want to own the application lifecycle and be configured via specific mechanisms) or writing and maintaining a duplicate implementation of all your data serialization/deserialization code, metrics configs, S3 configs, etc. I don't mean to say it's a disaster if you end up doing that, but it's a cost that will tend to hold you back from doing the right thing and make you persist with hacks and band-aids longer than you would have if you were free to change. > good, modular, well-developed frameworks evolve alongside their use cases. Django with DjangoRestFramework is an excellent choice for many API use cases That's a very modest change. It's still a long-lived service doing request/response over HTTP.