4 ms·

> Frameworks are there so you don't have to repeat the work of others You know what else is there so we don't have to repeat the work? Libraries. And they don'

> Frameworks are there so you don't have to repeat the work of others You know what else is there so we don't have to repeat the work? Libraries. And they don't take the control of how my code is called from me. Frameworks are there because except for Lisps language provide little mechanisms to reduce boiler plate so people want to avoid writing boiler-plate to pipe libraries together. However that doesn't have to be the case, take a look at Hunchentoot.

com2kid 8y ago
> You know what else is there so we don't have to repeat the work? Libraries. And they don't take the control of how my code is called from me. Of course they do. Libraries want you to give data in one way, and they return data in another strictly formatted way. Put a bunch of libraries together, that all know how to talk to each other via convention, and you have a framework.
- setr 8y ago
  >Put a bunch of libraries together, that all know how to talk to each other via convention, and you have a framework. And if that language of communication is the programming language... you have a programming language! (Eg using stdlib types/objects/whatever)
  - com2kid 8y ago
    Sure, but if I pass you a struct, having standard naming conventions for those struct elements is really nice. Having a standard way to do callbacks on observables is really nice. If a bunch of components are configured at run time using JSON or XML, having those components all use a similarly formatted markup language is nice. Looking at web server frameworks, a lot of them boil down to "put things in these directories, use these naming conventions, and if you do the convenience functions we've thrown in will work nicely". End result, instead of writing my own auth code for every endpoint, I throw some middleware in there and the auth happens for me. It all works because everyone agreed on how a bunch of library components are going to communicate with each other. Are there some frameworks that are way too opinionated and heavy weight? Sure. When someone tries to make a meta-framework that can be configured to solve all problems (see: The Java ecosystem), horrible nightmares end up being written. But the rise of small lightweight frameworks that are just an agreed upon glue for how components should work together? Eh, no big complaint.
ppeetteerr 8y ago
> Frameworks are there because [...] people want to avoid writing boiler-plate This really depends on how the framework was designed. Some frameworks are really good at getting out of the way, and focus primarily on providing a library-like syntax (e.g. Flask for Python) with very little bundling of libraries. You can use a Flask instance inside of a desktop app as a library rather than piping to it Apache requests if you so need. Larger, more structured frameworks exist for the developer to focus on the business logic and not worry about the context (networking, auth, sec, data store, etc.). They bring together multiple standard libraries that everyone agrees on and bundle them in a context instance the developer can confidently rely on. This, too, is a great tool.
icebraining 8y ago
I've taken a look and found https://edicl.github.io/hunchentoot/#easy-handlers https://edicl.github.io/hunchentoot/#easy-handlers
- jlg23 8y ago
  Yes, to be fair: hunchentoot is a webserver in CL, the "easy handler framework" is one option how to use it and I have never seen it in production - it is a convenient way to get started.
jlg23 8y ago
And in LISPs you'd call a framework maybe protocol or driver. Same difference. A high-level "web request dispatching and handling" library will take just as much control over your code no matter how you call it... (See weblocks, clack etc in CL - they all very much limit your code)

com2kid 8y ago

> You know what else is there so we don't have to repeat the work? Libraries. And they don't take the control of how my code is called from me. Of course they do. Libraries want you to give data in one way, and they return data in another strictly formatted way. Put a bunch of libraries together, that all know how to talk to each other via convention, and you have a framework.

setr 8y ago
>Put a bunch of libraries together, that all know how to talk to each other via convention, and you have a framework. And if that language of communication is the programming language... you have a programming language! (Eg using stdlib types/objects/whatever)
- com2kid 8y ago
  Sure, but if I pass you a struct, having standard naming conventions for those struct elements is really nice. Having a standard way to do callbacks on observables is really nice. If a bunch of components are configured at run time using JSON or XML, having those components all use a similarly formatted markup language is nice. Looking at web server frameworks, a lot of them boil down to "put things in these directories, use these naming conventions, and if you do the convenience functions we've thrown in will work nicely". End result, instead of writing my own auth code for every endpoint, I throw some middleware in there and the auth happens for me. It all works because everyone agreed on how a bunch of library components are going to communicate with each other. Are there some frameworks that are way too opinionated and heavy weight? Sure. When someone tries to make a meta-framework that can be configured to solve all problems (see: The Java ecosystem), horrible nightmares end up being written. But the rise of small lightweight frameworks that are just an agreed upon glue for how components should work together? Eh, no big complaint.

ppeetteerr 8y ago

> Frameworks are there because [...] people want to avoid writing boiler-plate This really depends on how the framework was designed. Some frameworks are really good at getting out of the way, and focus primarily on providing a library-like syntax (e.g. Flask for Python) with very little bundling of libraries. You can use a Flask instance inside of a desktop app as a library rather than piping to it Apache requests if you so need. Larger, more structured frameworks exist for the developer to focus on the business logic and not worry about the context (networking, auth, sec, data store, etc.). They bring together multiple standard libraries that everyone agrees on and bundle them in a context instance the developer can confidently rely on. This, too, is a great tool.

icebraining 8y ago

I've taken a look and found https://edicl.github.io/hunchentoot/#easy-handlers https://edicl.github.io/hunchentoot/#easy-handlers

jlg23 8y ago
Yes, to be fair: hunchentoot is a webserver in CL, the "easy handler framework" is one option how to use it and I have never seen it in production - it is a convenient way to get started.

jlg23 8y ago

And in LISPs you'd call a framework maybe protocol or driver. Same difference. A high-level "web request dispatching and handling" library will take just as much control over your code no matter how you call it... (See weblocks, clack etc in CL - they all very much limit your code)