Programming

It's not hard and fast but:

• API is the actual interface for the functions, not the implementation. It's possible for one API to be implemented by more than one library.
• Library is a bunch of code provided together. It might have more specific meaning depending on the language.
• A package is something you can install. It's pretty much synonymous to library since most packages contain one library.
• A framework is just a library that dictates a lot about how your app works.

Apart from API they don't really have strict definitions so they'll be used interchangeably and differently depending on the language.

API is just the term for "the surface of something that's been exposed to you to interact with"

Libraries, websites, tools, etc all have APIs, it's just the general term for "this thing has something we can interface with"

A library is a bunch of code someone else wrote.

A package is when you use a tool to bundle up a library to make it easier to distribute to other people, usually adding a version # to it, and adding it to so.e popular package manager network so millions of people can find your package easier.

A framework is a term for a very big cohesive library, with an advanced api, that does a whole bunch of different things that all have stuff in common. Basically a firework is a huge library that provides many many different things to do that all have stuff in common.

Game Engines for example are frameworks.

A library of tools to make a bunch of different website components that all work well together and have stuff in common is a framework.

Etc etc. It's a bunch of code that doesn't do anything in it's own, but provides a bunch of modular pieces you can assemble into something.

Think of a framework like buying a big box of lego. It's not anything specific yet, but you can assemble all those pieces together to make infinite different things.

An API is just a standard for using a thing. Normally, it's part of a library. So you install an email library and there is an API for sending emails. But an API can be a standalone thing. There can be a standard for something, such as ORM (or apparently video drivers—not my area) but then there are libraries that implement the API differently. For example, Hibernate implements the JPA API. Now the individual libraries probably do have their own custom API, but if you want to be implementation-agnostic in your code you just code to the API and you can theoretically swap out implementations.

Package as in package manager is about having a library that you need to use, which is built on other libraries, without you having to manage all of those dependencies yourself. You tell the package manager what you want and it handles the rest.

Frameworks are built on top of the core language and perhaps a bunch of different components that all work together to create a purpose-build set of features that all work together. It transforms the language, at least within that specific domain. So for example, Spring by itself basically manages dependency injection and beans. But there are a bunch of things that can plug into that to add things like security or database access or web-session management so that you can do those things in a way that is compatible with what you've already learned.

I can't really speak to the specific domain you are looking at because I do web services, but conceptually that should all translate fairly well.

I asked ChatGPT to see if it could improve my answer. It basically patted me on the head and ignored everything I said in favor of the following. To be fair, it at least addresses the specific domain you are looking at.

An API (Application Programming Interface) is a specification that defines how software components interact. It is often part of a library, but it can also stand alone as a standard that multiple libraries implement. For example, OpenGL is an API that defines a standard interface for rendering graphics, but different implementations (e.g., Mesa, Nvidia's drivers) follow that API. Libraries like GLAD, GLFW, and freeGLUT exist to help developers interface with OpenGL more easily.

A library is a collection of prewritten code that provides specific functionality, which you integrate into your program. In C++, you link against .lib or .dll files, as you do with Raylib for game development.

A package refers to a unit of distribution for code, usually managed by a package manager (e.g., pip for Python, cargo for Rust, vcpkg for C++). Packages often include libraries and their dependencies, making installation and dependency management easier.

A framework is a more comprehensive structure that dictates how a program should be organized. It typically provides inversion of control, meaning your code fits into the framework’s lifecycle rather than calling functions from a library freely. For instance, Cocos2d-x (a game framework) provides not just rendering but also an entire architecture for handling game logic, assets, and input—unlike Raylib, which is just a graphics library.

They’re overlapping concepts, and can be used interchangeably. Sometimes a library can be all of them at the same time. In simple terms:

• API is the interface to the library.
• Library is code that is shared.
• Package is how it’s distributed.
• Framework is the methodology the library is used.

Not all APIs are libraries. For example, all websites have some interface to interact with them. A website is not a library.

Not all libraries are packages. A library don’t need to be distributed through a package manager.

Framework is a bit blurry where the line is drawn. I think if the library is used in such way that your entire program revolves around it, then it’s a framework. If you’re just using it a handful of times, then it’s not a framework.

React and Angular are frameworks in this regard. If you use them, then your entire programming is revolving around them. Any decision made is in regard to these frameworks.

I would say OpenGL is API, library and framework. Maybe also package depending on how it’s distributed.

• API = Direct interface to other people's code.
• Library = A file containing other peolple's code.
• Package = A contained archive file contining other people's code.
• Framework = When the entire foundation of your program is other people's code.

Btw, use pipx to install software, pip is for libraries only.

Why is OpenGL considered an API?

An API is a promise - make these calls, get these kinds of results. An API often has more than one library that implements it. At minimum, there may be completely different code for different operating systems. At best, there may be completely separate vendors that implement identical APIs (Kubertnetes, and the Open Container Initiative, for examples).

Why is it necessary to use other libraries like GLAD, freeGLUT or GLFW to interface with OpenGL?

I don't know.

where you install these packages that get used like libraries? What's the difference?

Almost all packages are composed of libraries. Plenty of libraries lack packages. Packaging and delivering software is an entire field of study. As an expert at packaging and delivering software, I sometimes forget that a library I love still lacks a decent package. So I do my best to contribute a package, when I see a need.

RE: The biggest problem about this is the API definition. Libraries have APIs. But in a completely different way, webservers have APIs. If I say “we are going to a conference on API’s” what do you hear? That we are going to talk about REST, GraphQL, or gRPC, or web server APIs of some type. This is common phraseology. However, one time I was invited to such a conference, and it ended up being about C# design philosophy.

In that way API is an adjective (REST API, C# API, …) AND a noun (webserver API). That’s a problem.

And as an adverb, there is some justification to replace it with Library and others (REST Endpoint, C# Library)

Because otherwise all public functions are API’s, which doesn’t seem necessary to me. Saying a Library has an API is somewhat redundant. Saying a server hosts an API is not, many servers run jobs or databases. Many websites don’t host APIs. Etc.

An API is a interface / contract to do something. In the case of hardware APIs, at a certain point your code actually has to tell physical chips and wires what to do. How you do that, is often a convoluted process of putting bits of memory into specific buffers, executing instructions, and moving the results around, all in assembly language.

Those instructions will also be different, for every piece of hardware that has different buffers and instructions and features.

From the perspective of an application developer though, you typically don't actually care about any of that. Your application just requires something like drawing pixels on a screen. So instead of you having to detect what graphics card is there, and have to switch how your application code draws stuff depending on what card is installed, OS makers like Microsoft looked at the various hardware APIs, created a software abstraction that could work for any of them, and then published that as a unified API at the OS level that you could use to draw stuff on screen (DirectX). Application developers could just target DirectX, and then hardware developers just had to write little bits of code to run DirectX on their cards (this is what drivers are).

OpenGL is just taking that concept one step further and agreeing on an international / open source standard for that interface, rather than one that Microsoft controls and only works on Windows.

A library is one collection of code, it could just be a a function that returns something, or it could interact with the OS / hardware in some way.

A package can be a collection of libraries, or it can just be one, but packages are designed to support dependencies. i.e. a package will typically be a new library that builds functionality on top of an existing one, and this has a dependency on it (and on a specific version).

A package might also include compiled code, so it could be say, a JavaScript library that creates a JavaScript interface that is calling a compiled C++ binary, allowing you to now call C++ or assembly code from a higher level language.

Package managers handle managing packages for you, and managing their dependencies. If you install one package via a package manager, the package manager will also install all its dependent packages for you, and will clean up dependencies when you remove it, and upgrade them when you upgrade it.

Note that all of the above is extremely unopinionated and generic. It's basically all just code that could do anything you want.

The distinction with framework, is that a framework should be a full skeleton for producing something. It will typically provide libraries or packages, along with dev utilities, build utilities, testing utilities, and provide a full end to end example of how to build a type of application.

So for instance React itself, is just a library / package. It only handles updating the React tree. It doesn't even handle rendering anything to the screen (that's React-DOM for web project but something else for React Native projects), it doesn't come with a way of writing test code, it doesn't even come with real build utilities.

But you can build a framework around React, that's what Vercel has done with Next.js, where they include the React library / package in their Next.js framework, and provide a whole slew of additional functionality to build a full end to end web application.

Angular is similar in that it's published as a full framework, as opposed to just a part of it. Spring, Django, etc. are similarly full frameworks for building backend server applications.

Frameworks as a concept is looser too. Some of these frameworks are like game engines where you download an exe file and everything happens within that application. Sometimes frameworks are literally just a written list of instructions on how to build something. And frameworks are often built around other frameworks. For instance, Spring provides a generic framework for building a backend API, and a company's dev ops team might build their own framework around Spring that customizes it further for their company and infrastructure.

Package managers may distribute and manage libraries as dependencies, but may also manage tangential files like documentation, debug symbols, or source code for those libraries. They may also package build files to integrate into the build system, executable programs, or executable instructions. So it is a superset. Distributing libraries is the main, but only one aspect of them.

A packaged library is distributable through the package manager.

APIs, application programmable interfaces, are a standardization of callability - of names, parameters, returns, and behavior. Libraries may practically offer a non-standardized interface, or they may explicitly define an interface that they promise to follow (a more stable interface that you can depend on), or a library may implement an interface that is defined independently of a library.

With a standardized interface, multiple libraries can implement the interface, and they become inter-operable and inter-changeable.

OpenGL is an API that is defined as standards. The various graphics driver developers implement the interface. (Their driver makes the implementation available as libraries.) And there's even software-implementations that implement a translation layer rather than "directly" talking to hardware. This for example allows you to play Windows games on Linux where the Windows APIs get translated to Linux equivalent API calls or implementations.

Frameworks typically offer a broad[er] architecture and functionality of things. You do not interface with them, you integrate with them. For example, in C++ you may use the Qt framework for UI. Rather than using a UI library that you interface with and call, you implement UI the Qt way, and call Qt to render that. This does not only work for UI of course.

Small word about OpenGL, as it seems confusing for many peoples:

OpenGL is a spec written by Kronos group. There is no such thing as OpenGL library, or OpenGL source code. You cannot "download" OpenGL. OpenGL is really just a buch of .txt files explaining how functions should be named and what they should do. This spec define an API.

Then, this API can be implemented by anyone, by writing code and putting it in a library.

GPU drivers implement this API. That means that Nvidia, AMD and Intel have their own implementation.

To have access to this API from your program, you have to "getProcAdress" all function you want to use from GPU driver's DLL. As this is quite painfull, libs exist, like glew, that do it for you. These libs are really just a long list of getProcAdress for all entry points.

That's also why you cannot "static link" with OpenGL. As function can only be retrieved at runtime.

Another interesting things is MESA. It's a CPU implementation of OpenGL spec. So MESA is a lib, with source code and so on. You can download it, link against it, etc... This is very useful when you want to do 3D without GPU (yes, this happen, especially in medical domain).

My understanding:

• API = a communication interface between different pieces of software, can be running on the same machine (e.g. a library API) or on another (e.g. a HTTP API)
• library = code that provides some reusable functionality that someone else wrote and that you, as the application developer, are calling and using the return values of
• package = can mean different things depending on context and programming language, the metaphor is that it is code that somehow belongs together, but there's no general way to define this
• framework = code that provides the general structure of code and that is extended by the application developer to implement actual functionality

The way it's been explained to me is that the difference between a library and a framework is that a library is something that you call from your code, a framework is something that calls your code.

Opengl is a weird edge case because the way it links into c programs is cursed. GLAD GLUT and GLFW just make using opengl itself easier by doing all of the library loading automatically. Because there are so many versions of opengl you have to load the specific one you want at runtime, alongside all the separate extension libraries that may or may not be in different binaries, directories, etc.

OpenGL is the exception and not the rule in the normal library - api - program paradigm.