javbit
I think there's an argument that pixel art was designed for CRT displays and thus optimized for it. I think of it like Pointillism: the work is made of little dots, but the point is for you to see the entire work blend together. And for low resolution works like retro games, they often hold up well on CRT (especially real ones). However, I think modern games with the pixel art aesthetic look best crisp.
To each their own tastes, though.
Pros for guix: - guile scheme - better documentation - free software first - strictness means things blow up early - great emacs mode!
Cons for guix: - goofy stack traces (guile debugger is nice but im not very proficient)
Pros for nix: - more packages & services - flakes, which makes it easy to lock in versions, though guix has channels. Flakes just feels easier to me imo. - laziness - sometimes better error messages
Cons for nix: - laziness (infinite recursion) - no debugger afaik, have to use repl which is useful but also sometimes clunky
Good resource on guix is system crafters (David Wilson)
https://www.gnu.org/philosophy/free-sw.html#four-freedoms
It's interesting because I'm sure no free software author wants to inadvertently support a dubious cause. This clause prevents that (in theory at least, as license enforcement is hard for everyone). However, it also nominally prevents use by good causes as well (you can grant exceptions). Good and bad here are relative to the author.
I guess it's a balancing act between upholding ones own sense of right and wrong, and the freedom for someone else to have a differing opinion than you.
edit: I see other commenters shared this idea too.
E.g.
(+ 1 2) ; Add two numbers.
Would become (comment (+ 1 2) "Add two numbers")
With semantics like const.Another would be
(+ ; Adding
1 ; one
2 ; and two.
)
To ((comment + "add")
(comment 1 "one")
(comment 2 "two"))
You could display comments as popups, marginalia, or even in a traditional fashion (since some intent is captured by the comment scoping. You could also have different types of comments like annotation to have different kinds of display types.If anything, really shows how the “traditional” knowledge that I personally did not consider much before may be worth taking a second look at.
Perhaps there’s a perceived notion that to understand infinitesimals and such you need a logic background, but logic classes are generally an upper-half class that doesn’t have a full track for undergrads. This would be in addition to the fact that most professors are familiar with ε,δ-proofs and AP calculus classes cover the limit approach (though not rigorously).
The entrenched pipeline of mathematics students and professors would have to face a period of getting flushed out and refitted, and this is probably not attractive to administrators.
withFADR' :: (FragileAndDangerousResource #-> IO ()) -> IO ()
be a better type? My reasoning is if I use the linear identity function lid :: forall a. a #-> a
in the following withFADR lid
I should be able to “break out of” the managed context [1] by the types. Using withFADR'' :: (FragileAndDangerousResource #-> ()) -> ()
is obviously not right since nothing could be done with the `FragileAndDangerousResource`, so I think side effects are necessary.---
[1]: I'm assuming that's what you're going for with `withFADR`.
[1] If you already have the symptoms can you get HPPD?