Prohibited non-residential purposes include ... Running any type of server on the system that is not consistent with personal, residential use. This includes but is not limited to FTP, IRC, SMTP, POP, HTTP, SOCS, SQUID, NTP, DNS or any multi-user forums. spectrum.com/policies/inter… The internet is fucked because centralization is baked into the rules, not because decentralization wouldn't be possible, but because the infrastructure is rigged by the owners.

When people are not killing themselves for their jobs, services are less reliable. In the net I think this is a positive, but it's a tradeoff that needs to be acknowledged to be accepted. I'm not talking about computers, computer systems can generally be built to run unattended if you know what you're doing, I'm talking about real work

LambdaCase is strictly more useful than traditional 'case' keyword and I don't see why it shouldn't simply *replace* it instead of adding \case as an additional keyword

case x of { ... } can always be rewritten as x & \case { ... } The traditional case expression does two things at once: it defines a function, and also applies it.

Voting isn't so bad if you get an absentee ballot and just research one question a day Would be a lot more fun with a ranking system though

If you've got a #haskell identifier x and you need to figure out how to convert it to some type T, just write

_ x :: T

And hover over the underscore, and you see what type of function you need to get there. If an appropriate function doesn't exist yet, replace the underscore with some name

f x :: T

and use the "Define ..." code action to automatically stub out a definition for f

what the city government does is continually obliterate vegetation to create hot barren shadeless hellholes they call "parks" where there could be a nice little forest, there is just shit, because we live in a society

There's a piece of programming advice I've been turning over in my head for some years: that a function or program or whatever unit of code ought to "do a single thing." It's always seemed like that contained a kernel of truth but was ill-phrased. I haven't managed to fix it, but I now have in mind what I think is a fairly general special case of the sentiment - for the context of functional programming, at least. My reformulation is: Prefer to define a function as a composition of other functions where possible.

Haskell programs side effect all the time, there's no prohibition or even cultural aversion to effects. The only "effect"-related thing we really avoid is the way in many languages one uses the stack, the heap, and static memory as a myriad of little ad hoc in-process databases. A lot of languages I look at as essentially DSLs for creating multitudes of ad hoc databases. The simplest form of a database is an IORef, which haskell has and haskellers use, but a lot of languages have dedicated syntax for IORefs (e.g. when every variable implicitly is one).

For a library that wraps an HTTP API which is already decently designed and documented, *encapsulation* should *not* be the goal. Provide functions that interpret the headers and response bodies, but keep the HTTP API details in the forefront of the user's mental model. There's a much bigger rant coming on a more general topic here, about how to write libraries that are designed to be eliminable, not libraries that "capture" a problem by forcing a lot of opinions on the user and obscuring in places that ought to be enlightening.