The AGPL precisely covers that part. https://www.gnu.org/licenses/license-list.en.html#AGPLv3.0
You can also email licensing@fsf.org with your use case and I am sure they will be able to help.
848 karma · joined July 21, 2022
You can also email licensing@fsf.org with your use case and I am sure they will be able to help.
Results would probably come out empty anyway.
It's unclear what "linear algebra" means to GP, though. I agree writing linear algebra libraries is next level, since that involves numerical code and knowing FP math well.
And this whole blog series: https://preshing.com/20120612/an-introduction-to-lock-free-p...
He would've been caught on the spot.
Let me prepare the school curricula for next calendar year.
> So far, we’ve only used perf to record stack traces at a regular time interval. This is useful, but only scratching the surface.
For cache hits and other counters, you're gonna have to go deeper than just sampling.
The big difference here is that the OCaml compiler has a lot less work to do. It's not that the Haskell error messages are inadequate (they are actually pretty good), but that the amount of compiler features and type gymnastics make the errors deeper and more complex. For example, if you get the parens wrong in a >> or >>=, you'll get some rather cryptic error that only hits home once you've seen it a few times, as opposed to "did you mean to put parens over there?"
> If I come to an existing OCaml project, the worst thing previous developers could do to it is have poor variable names, minimal documentation, and 200+ LOC functions. That’s fine, nothing extraordinary, I can handle that. > > If I come to an existing Haskell project, the worst thing previous developer>s could do… Well, my previous 8 years of Haskell experience can’t prepare me for that
This is kind of like Go vs C++, or <anything> vs Common Lisp. The former is a rather unsophisticated and limited language, not particularly educational or enlightening but good when you need N developers churning code and onboard M new ones while you're at it. The latter is like tripping on LSD; it's one hell of a trip and education, but unless you adopt specific guidelines, it's going to be harder to get your friends on board. See, for example: https://www.parsonsmatt.org/2019/12/26/write_junior_code.htm...
> Ideally, you should be able compose them several of them into a single app and not have a custom implementation of a giant state
If you are suggesting that components store their state, I'm not sure about "ideal" there. That works well for small GUI applications. In GUI applications of modest size, you do want a separate, well-organized and non-redundant data layer you can make sense of, at least from my experience. Qt, specifically, allows you to do both things.
Your latter example needs context. In what situation have you had an enum with 2^16 states? In any case, if you generally have a reasonable number of booleans, with some states being logically invalid, then you'll need error checking on those anyway.
Leaving them as booleans gives you the ability to monkey-patch things later in an ad-hoc manner, which is useful when you're still in a prototyping phase and the requirements aren't clear (and you could argue that this is almost always the case in many problem domains; I think that would be valid criticism.) But if you've already modeled the domain and you want any assurance of correctness, then I don't see why you wouldn't enforce the constraints at the type level. Your criticism seems to me the usual trade-off between strong static typing and dynamic and/or weak monkey-typing.