Quadratic Voting and Quadratic Funding have some ideas in common, but they refer to separate concepts. To learn more about these topics, I would probably check out the website for RadicalxChange. IIUC RxC is the main public body attempting to realize the theoretical benefits of QF and related ideas.
Here's an explanation of Quadratic Funding from their website[1], which I guess they now refer to as "Plural Funding":
Plural Funding (also known as Quadratic Funding or QF) is a more democratic and scalable form of matching funding for public goods, i.e. any projects valuable to large groups of people and accessible to the general public.
“Matching funding” is a model of funding public goods where a fund from governments or philanthropic institutions matches individual contributions to a project. Plural Funding optimizes matching funds by prioritizing projects based on the number of people who contributed. This way, funds meant to benefit the public go towards projects that really benefit a broad public, instead of things that only have a few wealthy backers. In Plural Funding, [total funding] for a proposal is [the square root of each contribution to it → summed up, then squared.] Plural Funding strongly encourages people to make contributions, no matter how small, and ensures a democratic allocation of funds meant to benefit the public.
Indeed they call for new names, as they encompass far more than iterators.
If you read a bit more about them, I think you will be surprised to see the breadth of what these abstractions can be used for. To start, they've been used to build a new compositional foundation for game theory[1], and they can be used to model gradient-based learning in machine learning[2].
As for their simpler applications as getters and setters, they are programmable in the sense that you can think of lens/prism types as interfaces that can be implemented arbitrarily. So you can create your own lenses and combine them like legos to construct new, "bigger" getters and setters from the smaller components.
Hi! A few years ago I found myself wanting an equivalent of `column` that didn’t strip color codes. After I implemented it in Haskell, I found it was useful to use Nix to force statically linking against libraries like gmp to reduce startup time. Perhaps what I ended up doing might be helpful for you too: https://github.com/bts/columnate/blob/master/default.nix
You should look into the "comonad" abstraction from the functional programming world. Dual to monads, they're a natural fit for situations where you might have a value with some sort of (possibly infinite) context (think: neighborhood, or history, etc.) that can be either pre-computed or computed on-demand.
This StackOverflow post[1] is a good starting point for understanding comonads. It points out that they can be used to model cellular automata (like Conway's Game of Life), sequences, streams, etc.
In the Haskell world, folks have solutions to both of these problems:
The "large-object problem" can be tackled in a principled fashion using strict state threads (aka the ST monad: https://wiki.haskell.org/Monad/ST) or using vanilla mutable (IORef) references.
The "parent-child problem" is well-addressed by lenses, also known as functional references. They are basically composable getters and setters that allow you to read or update deep into nested structures.
They are, and they absolutely should be. They're completely separate projects/repositories from those from which they came. The owner of a forked repository is completely free to make whatever changes they please -- from a few bug fixes to taking projects in completely new directions (as I've done with a forked repository of my own). As far as GitHub is concerned, in the context of a forked repository being a first-class citizen, it's a minor detail that the code was originally "copied" (to use the term loosely) from somewhere else.
But that link only says that via-C is being dropped which, as I understand it, is not currently the default backend -- NGC is[1]. This means that (1) via-C is being dropped; (2) NCG (native code generator) has been, and is still the default; and (3) this LLVM backend support is currently being considered to be merged in.
Although this is really cool stuff and it looks like it's going to get merged in, the title is a little misleading here. GHC hasn't switched to an LLVM backend -- they're currently reviewing this patch and possibly merging in this support for LLVM output (not necessarily switching over to it entirely).
This looks pretty interesting (and I particularly like the ability to have a package pointed at the bleeding edge), but I'm not sure how I feel about /usr/local being owned by an arbitrary user. What happens if there's more than one user on the machine?
I think the biggest disadvantage of putting something like this in middleware, is that it's completely incompatible with stuff like memcache. The injection of this meta-tag is done after a memcache SET would have been done in the web app, and so if you have a reverse proxy in front of your webserver, for any cached page that's served, it won't include the injection. Also, the user-agent check that's being done in this plugin yields incorrect results in the presence of caching for similar reasons.
Here's an explanation of Quadratic Funding from their website[1], which I guess they now refer to as "Plural Funding":
[1] https://www.radicalxchange.org/wiki/plural-funding/
EDIT: formatting