samhh

I wonder about the environmental impact of CPU cores churning away uselessly on so many machines so many times. Probably enough to power a home for a few years?

That would certainly work, I've got a rewrite of a WebExtension in progress that does the same thing.

Depending upon what the likes of `Aff` compile down to, you may not even need a JS wrapper. If the compiled type signature is compatible you can just point the Node.js runtime directly to the PureScript output.

The next step here may be recognising that just as you'd map a list, you can also map lots of other data structures, namely anything that's a functor (see: `fmap`).

Have something nullable? Stick it inside `Maybe` and map it.

Have a side effect in `IO` and want to manipulate the result? Map it.

Following that, look at monadic binding. It's basically flat mapping.

From here you can start to see how programs can be composed in languages like Haskell. You have these foundational typeclasses and you sort of just connect all your functions together with them until you're left with one big expression in `main` which is your application entrypoint.

Not played anything very intensive yet, but Rocket League and Deep Rock Galactic, each via Proton, are performing way better than they were before, in line with what you'd expect moving from a 1070 to a 6800.

When I think of networks of friends and family I don't think that's the case. You'll need something approaching 50%+1.

6800 is already working fine on release mesa for me. Mightn't have been the case if stock wasn't buggered and I'd have gotten my hands on it a couple of months ago at launch, mind.

I never had crashes but, having switched from a 1070 (proprietary) to a 6800 (open) this week, the experience is far better. Things that were previously nigh-on impossible to get right, like fixing screen tearing, or freesync without bizarre performance penalties, just work now.

The vast majority of users don't care about the underlying encryption. That's a problem, in a sense, but the core problem here is the network effect. That it's the natural behaviour of people doesn't make it not a problem.

I can't imagine that having good reliability.

You don't really need to be bought into fp-ts to use io-ts. Just create a helper function that morphs the native decode output, `Either<E, A>`, to something like `E | A` or `A | null`.

I think it makes sense to separate the notion of bangs, what a lot of people use DDG for, from that of a search engine. I think projects like my own (very primitive!) bangin are a step in the right direction here: https://github.com/samhh/bangin

You'll potentially need to use merge if you're collaborating with others on feature branches.

I think the most common usage of that - switching branches - could be replaced with `git switch` now. That leaves `git checkout` in the set of more advanced operations for more niche use cases.

Same goes I think for `git restore` over `git reset`.

Everyone saying which app they prefer, and I'm wondering why you don't just use one of the many lightweight, FOSS CLI diffing tools that already exists.

It is, for example accessing an array or record doesn't unionise the returned value type with undefined, though this particular gaping hole of unsafety is being addressed in 4.1 with a new flag.

Beyond that there's functions that throw/reject doing so outside the type system, something solved by Either/Option/similar types in fp-ts.

The biggest benefit of fp-ts though is that it makes you think functionally. If you're dead set against that, then there are plenty of other libraries that give you types/wrappers like these without having to use pipe/flow (two functions you'll want to use before anything else in fp-ts).

It's a bit high level in that the benefits aren't obvious until you buy into other functional concepts, but basically it's that Options can be layered i.e. Option<Option<string>> is possible. If you just use ordinary union types there's no way to express that.

As an aside, TypeScript is very unsafe by default, and still relatively unsafe with strict mode enabled. Stringent fp-ts usage bypasses these issues.

Author here.

Yeah, I've found myself never really needing that functionality. I use bookmarks principally as time savers and secondarily as ephemeral reminders; I think the habit people have of stacking up bookmarks they'll never come back to, likewise having hundreds of tabs open, is an antipattern.

In rare cases where I've wanted to keep a link for documentative purposes, it's always been more appropriate to keep it alongside that source material, which is typically a markdown file.

All that said, it'd be quite easy to implement tags and descriptions provided you'd be willing to write them yourself (and given how messy some websites' metadata is, I would). You could just grep for what you want.

That's one of my motivations for writing bangin. There are some sites I want to use bangs with which are either too niche or otherwise fall foul of DuckDuckGo's rules.

https://github.com/samhh/bangin

Hello, author here.

The idea came to me yesterday as I wanted to use a bang for ProtonDB. I didn't fancy waiting around for it to be added to DDG following submission, and that led me to ponder the other harms of this really useful feature being locked behind DDG's service.

In theory, with the script being so simple and working on the basis of mere input and output, it should be easy to write other tooling around it, which I've briefly touched upon in the README.

The shell script is extremely simple, but anyone with experience in writing them might be able to spot problems with it, please do let me know if you do.

I'm unsure about how best to package banglists. One option would be to provide a config file with a list of lists, a bit like you do with some adblocking software, but that'd presumably require some sort of intransience.

Anyway, feedback welcome!

I've found 20:4 successful only as a means of preventing me from eating too much; prior to IF I'd habitually graze throughout the day. It's basically a diet where you don't have to think that much about what you eat (you should a bit, still, obviously).

If I'm understanding you correctly, then fp-ts has the `constant` function to enable what you're describing in #1:

    fold(constant('my static fallback'), f)(x)

What sucks about this, as much as it's my preferred pattern, is that without native pattern matching in the language it's unclear which callbacks are for which type constructors. It's not so bad for something like Either, but if you're using something like DatumEither with ~five constructors it's a bit of a mess.

That's not an unreasonable concern but it does mean you're writing code targeting the lowest common denominator. That's not a decision free from negative consequences.

Elm's got questionable support; I wouldn't feel comfortable recommending that at work, it'd be irresponsible.

PureScript I really like but it's a massive jump from JS/TS to PS/HS.

All of these languages are harder to abandon than a library in the same language you'll keep using if you decide against the paradigm down the road. Do I like this compromise? Not really, but it makes sense.

Also, advertising use of a functional language might open you up to candidates who wouldn't otherwise apply.

TypeScript is really about type safety within the confines of your application. You can address the unsafety at the edges with something like io-ts.

I doubt much of this is parallelised. Would love to be wrong though!

I think number one can be handled with type classes. Usually if you want to pass in radically different structures there's some common underlying structure.

Sum types and newtypes behind smart constructors are better ways of accomplishing what you'd usually use union types for, I think?

Ha, similar. Try encouraging your team to adopt the likes of fp-ts and newtype-ts piecemeal, it's certainly not as good as the likes of PureScript but it can at least enable you to utilise composition, Option et al, etc.

Firstly, there's a nuance here that readability is heavily dependent upon the language. A language where recursion is the recommended approach to these sorts of problems will have far better syntax for doing so, such as in Haskell.

Secondly, I think there's something to be said for familiarity. I think looping is second nature to most of us not because it's superior or more intuitive, but because traditionally this is one of the first things we're all taught. If functional programming were the norm and people were taught recursion early on instead I think your notion of simplicity would differ.

I've been teaching a little bit of programming to a beginner lately, and they've often found functional approaches to problems easier to grasp than their imperative equivalents because they're more mathematical. It's like an expression of something they already know versus looping, mutability, et al which are new concepts entirely.

On the other hand, you can pretty much just learn Haskell to learn PureScript. All of the differences fit onto a single small docs page: https://github.com/purescript/documentation/blob/master/lang...