So, full spoilers, which is sort of what you need to discuss this film.

The film is set in a world in which the full commodification of women as sexual objects is a fully realized, taken to its logical, technological end. There’s nothing inherently wrong about deciding to use that sort of setting in the service of storytelling: lots of powerfully good feminist works sci-fi explore stories in that sort of dystopia.

But it’s the sort of setting that demands some damn justification, right? And I didn’t, when the credits rolled, truly know whether Blade Runner 2049 succeeded on that…

But no, no not that part, the OTHER part

***Spoilers, duh***

People talk a lot about the final beat & payoff with the police car rolling up, and that was great, sure.

But I’d like to focus in a little more on the “zero fucks” attitude portrayed by the protagonist in the end, and just how earned that felt. And what that means.

Chris spends the entire movie brushing off little micro-aggressions. Being a “good sport” about it all. …

Folks, idk what to tell you

In my last article about pure, cancelable Tasks/Futures and their advantages over Promises, I talked at length at cancelation done right: requesting an operation that will generate a future value, but then also being handed back a functional option to cancel both it and any of its chained side-effects.

What was so powerful about this “thunked” pattern for cancelation is that it returned the cancelation control directly back to the call site at exactly the time the request was actually executed. That is: the precise part of a program that makes a request then has synchronous and direct access to…

Imagine, if you would, telling a person living in 1776 that many computer programmers would one day demand the ability for their online video programming tutorial videos to play at 1.5x or even 2x speed… and that that feature would then become so popular that it would soon be an expected default element in the User Controls of any online video service that ever hoped to target programmers… all just so that the programmers could try to could learn things faster from online tutorials…

Just…. imagine it.

No, no you do it: I don’t have time to bother imagining what they’d say, I’ve got to go learn more programming.

I’m going to try to be real quick here. Your time is valuable, you need the good stuff asap!

So first off, check out this great article about stateful javascript anti-patterns which is based off of this great article about anti-patterns in Elm.

All checked out? Found your way back through a sea of information and fractal distractions back here to this article? Great. Here’s the sweeps-season twist: I lied about trying to be quick: actually what I think those articles lack is both pragmatic context and more comedically elaborate dramatization, and I’m about to launch into it…

So anyhow…

Reflecting on what was so tricky about cancelable Promises, embracing functional purity as a solution

So… “cancelable Promises” have been, well, canceled. And so, the Javascript community is left once again wondering how newer, Promise-based apis like fetch can possibly move forward. Why has this been such a blocker? And what can we do?

Working with the future in the present

Let’s start with a quick recap of the problem space. We could talk about the “event loop” in Javascript here… but for our purposes let’s just reflect on the fact that all the code in our applications executes in a specific order of operation: inside-to-outside, first line to last. …

Future-Facing Functional Tasks: what they get right where ES6 Promises got wrong

I used to love jQuery’s Deferreds. Not just as a nicer callback interface, but as a fundamental structure for building program around. Then I found out that there was something even better out there: the Promises/A+ spec (which jQuery now supports). So when Promises rolled out with ES6, I was overjoyed to have my favorite plaything right smack in the language itself.

But then I stumbled into functional programming and, well, everything fell apart. …

(if you’re on desktop Chrome or Firefox, run the pen, accept the recording permissions, and wait a bit, maybe move around a bit instead of JUST staring…)

(And sure, it currently requires you to be on Chrome/Firefox on a desktop computer to work, and to affirmatively accept the recording permissions: but I swear, and the code will confirm, that the recording is not saved or sent anywhere: it’s all local javascript)

Anyhow, this is just to say that mediaRecorder is a thing, it’s pretty cool, and there are a lot of interesting potential applications for webapps.

And that’s because…

…you might have gotten the idea that they were too unwieldy for solving exactly this sort of problem:

The problem occurs when you feel like you already have the x value lying around but you want to have access to in the 3rd step (the functional argument to the 2nd .then()). How do you actually carry it along to the next operation? The monadic, “return just a single value,” nature of the problem seems to fight against what you need! A lot of people tend to solve the issue like this, using some form of closure:

Still others…

Functional Javascript and the Maybe Type

So, here’s the simplest function imaginable:

In any language where we can assign functions to values, we can think of them AS values.

Drew Tipson

Primarily Javascript, potentially personal, possibly pointless. I welcome and am fascinated by your many marvelous opinions.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store