In our industry, I think the terminology is a bit vague as to the differences between a Library and a Framework. I'd also throw in a third term that seems to potentially mean the same thing as Library or Framework: SDK.
In my mind, I tend to think of a Library as a static library linked to the application at compile/link time, whereas a Framework as a dynamic shared library referenced by the application at compile/link time but loaded by the executable loader at runtime.
However, that's just how I use the terms in my head. And they are definitely used differently in other contexts, and other programming languages or toolchains may use those terms as better suited for their environments.
Data wrangler, software engineer, systems programmer, cyclist. Unix (mostly Solaris) for aeons. I talk C, Python, SQL, Performance, Java, Kafka and Makefiles.
Location
Brisbane, Australia
Education
BA (Mathematics, Modern History), University of Queensland
I don't agree (and strongly so) with your representation. Linking an application means that you use tools to bolt together all the components which you need in order to make the application work.
Whether you use static or dynamic linking is irrelevant - you're still using libraries.
A framework, otoh, is an API. It's a (more or less) abstract definition of exposed surfaces between components.
Those that I'm most familiar with are for hardware support in Solaris - the Solaris MultiPathed IO (mpxio) stack. The API/framework in that area is a set of interfaces which driver writers are expected to support, so that software further up the stack (closer to userspace) can use the appropriate function calls and callbacks to do the right thing. Having a [documented, supported] framework allows you, the vendor, to get third parties (Emulex, QLogic, Brocade et al) to write their drivers for your OS, rather than requiring the vendor have those staff in-house and extra lawyers to do the IP licensing dance.
The library implements the framework.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In our industry, I think the terminology is a bit vague as to the differences between a Library and a Framework. I'd also throw in a third term that seems to potentially mean the same thing as Library or Framework: SDK.
In my mind, I tend to think of a Library as a static library linked to the application at compile/link time, whereas a Framework as a dynamic shared library referenced by the application at compile/link time but loaded by the executable loader at runtime.
However, that's just how I use the terms in my head. And they are definitely used differently in other contexts, and other programming languages or toolchains may use those terms as better suited for their environments.
I don't agree (and strongly so) with your representation. Linking an application means that you use tools to bolt together all the components which you need in order to make the application work.
Whether you use static or dynamic linking is irrelevant - you're still using libraries.
A framework, otoh, is an API. It's a (more or less) abstract definition of exposed surfaces between components.
Those that I'm most familiar with are for hardware support in Solaris - the Solaris MultiPathed IO (mpxio) stack. The API/framework in that area is a set of interfaces which driver writers are expected to support, so that software further up the stack (closer to userspace) can use the appropriate function calls and callbacks to do the right thing. Having a [documented, supported] framework allows you, the vendor, to get third parties (Emulex, QLogic, Brocade et al) to write their drivers for your OS, rather than requiring the vendor have those staff in-house and extra lawyers to do the IP licensing dance.
The library implements the framework.