expr @ expr @programming.dev

Posts

0

Comments

458

Joined

2 yr. ago

(It's definitely not.)

What the fuck are you talking about? No one downloads software from GitHub on Linux unless they're doing some really fringe, custom shit. Linux users detest randomly downloaded software from the internet (which is effectively the ONLY way of getting software on Windows, btw). We want all software to be managed by our package managers.

Also, lol on "software purchase". What software are you buying on Linux?

We have a phrase for a bricked windows install: it's called the Blue Screen of Death. It's not like Windows never gets fucked either.

I've personally never had such an issue upgrading Linux.

I mean I've yet to come across a game that is unsupported on my Steam Deck. For all intents and purposes, gaming on Linux is the real deal.

I'm in the US with an Android and have never actually encountered this, only heard about kids bitching about it. Adults definitely don't give a shit. It's very childish behavior.

It's never too late to learn about them. They're super common in practice so it's very helpful to know about them. A lot of things are a DAG, like tree data structures and dependency graphs. Having no cycles in a directed graph has a lot of nice properties too, like allowing one to use efficient graph traversal algorithms, topological sorting, or its transitive closure. It's come up multiple times in my career so it's definitely worth knowing imo.

It's very well-known and common knowledge. It's certainly something that I will talk about without feeling the need to define terms or something. I would assume anyone unfamiliar with it either didn't pay attention in school or never went to school to begin with.

Another super cool thing about it is that it's written entirely in Haskell!

That's what I do.

Sure, I guess the presumption is that you're working someplace where you can have good work-life balance. If you don't, then you're probably gonna be pretty miserable no matter what, WFH or not.

I'm certainly sympathetic as I too have faced terrible abuse when working in customer service. TBH to me that says more about the job (which sounds pretty awful) than working from home. But perhaps that kind of job makes it more difficult since it sounds pretty "solo" to begin with, and I can see how WFH can at least exacerbate that, especially if your workplace isn't set up for it. It's probably a pretty isolating job no matter if you are WFH or not, though.

I tend to prefer similar movies as you and I loved the movie. It is a VERY fantastical, intelligent, existential, and heady movie. It's one of the most expert navigations of complex social dynamics I've ever seen and has an absolute shitload of cinema references and easter eggs to boot.

Don't let the surface fool you. The franchise is just a vehicle for Greta's ideas to reach a mass audience.

My company has been full remote since before the pandemic. It's been fantastic. I hang out and chat with my coworkers all the time in Slack huddles. We have a remote-first culture and it's far better than an office ever was.

If you're getting depressed from working at home, tbh that sounds to me like you live to work rather than work to live. It's important to have a rich life outside of work, especially when working remotely.

It's "open source" as a technical matter, but the fact is that plenty of common extensions are still strictly controlled by Microsoft (like say, Live Share) and can't be used with vscodium due to licensing. It's a pretty useless editor without extensions, and the marketplace isn't exactly "open", either.

I'm in the US. Never used Whatsapp in my life, and don't know anyone that does. I just text people. It would be weird if someone tried to get me to use WhatsApp and tbh I'd probably just say no.

At work we use Slack and Google Meet.

I've always used and will continue to always use curl.

I think that's a reasonable enough generalization, yeah.

I'm sorry though, I seem to have given you incorrect information. Apparently that library does not have monad instances, so it's a bad example (though the Concurrently type does have an applicative instance, which is similar in concept, just less powerful). For some reason I thought they also provided monad instances for their API. My bad.

Perhaps it would be better to use a much simpler example in Option. The semantics of the sequencing of Options is that the final result will be None if any of the sequenced Options had a value of None, otherwise it would be a Some constructor wrapping the final value. So the semantics are "sequence these operations, and if any fail, the entire block fails", essentially. Result is similar, except the result would be the first Err that is encountered, otherwise it would be a final Ok wrapping the result.

So each type can have its own semantics of sequencing operations, and in languages that can express it, we can write useful functions that work for any monad, allowing the caller of said function to decide what sequencing semantics they would like to use.

JavaScript promises are not monads: https://stackoverflow.com/questions/45712106/why-are-promises-monads

They're close, but not quite. then can shift semantics from under you depending on what's supplied.

It should also be added that monoids require the type to have an identity or "empty" value (which is the empty array for arrays).

The explanation is pretty off in general, since it implies that any type that's both a functor and a monoid is a monad, which is simply not true. A good example is a ZipList (like lists, but with an applicative instance based on zipping). It's a functor and a monoid, but definitely not a monad.

It's a pretty natural consequence of other languages simply not having a concept or word for the thing that we're trying to abstract over, so better names simply don't exist. I've yet to see anyone come up with a better name than "monad" for the concept. Same for monoids. We may as well use the names that come from math and are already used extensively rather than trying to invent some new name that would invariably be misleading anyway.

Every single programming language is chock full of jargon that is basically meaningless to anyone unfamiliar with it. It's really no different. The only difference is that monads are fundamentally an unfamiliar concept to many imperative programmers, particularly because programming in that style pretty much upends a basic assumption imperative programmers tend to have (namely, that the semantics of sequencing operations is a global, immutable property of programs).

That's not a monad, that's just typeclasses (also known as traits/interfaces/etc.).

If you're familiar with flat_map or and_then in Rust, you already get the basic idea of monads. Just imagine that instead of the ad-hoc implementations that Rust has to do (since it doesn't support higher-kinded data types), you could express it in a single trait. Then you can write code that generically works with any types that support flat_mapoperations (along with a couple of other requirements, like needing a From<T> impl, as well as abiding by some laws that are really only a concern for library authors).

If that sounds simple, it's because it is. It's mostly just that it just so happens that being able to write code in this fashion has some pretty significant implications. It essentially allows you to very strictly control the semantics of sequencing operations, while still giving you enough flexibility to enable many of the things you typically do in imperative programs. In a language like Haskell which is built on monads, it's a very powerful reasoning tool, much in the same way that purity in functions is a powerful reasoning tool. It allows us to do things like, say, represent async code blocks as first-class concepts requiring no special syntax (no async/await, etc.), because the monad interface allows us to dictate what it means to sequence async actions together (if you're curious to see what this looks like, here's a link to Haskell's Async type from the async library: https://hackage.haskell.org/package/async-2.2.4/docs/Control-Concurrent-Async.html#t:Async).