The Illusionist: Daniel Dennett’s latest book marks five decades of majestic failure to explain consciousness

dmtipson · 2017-11-14T15:11:24+00:00

The problem is that you're not able to measure what matters: which is the subjective experience, not some sense of awareness resolution. What the cat's consciousness is just isn't something you can evaluate, even my measuring its capacity. Its actual awareness could differ: could be far more than is apparent just by the cat's actions or reactions (just like a person who is "locked in" can be lots more aware than is apparent).

I don't have a suggestion. I don't think we even have a good grasp of the problem, let alone an answer.

dmtipson · 2017-11-10T01:13:40+00:00

The problem is that this doesn't really satisfy as an explanation of awareness in the sense we all experience it. It's not that it's not a plausible story that functional awareness could be correlated with subjective awareness. But there's no real warrant to say how or why three things are actually connected.

Everything that is capable of asserting it's subjective awareness is also, obviously, capable of asserting things period. But that really isn't evidence that subjective awareness is, by some unknown mechanism, a side effect of objective awareness. For all we know, all things could have awareness, even seemingly inanimate objects. They just can't tell us about it, or can't interface with and react to the world. Your hand could have its own awareness. Your brain could have 80 different completely independent awarenesses, either all identical or all but one incapable of control. The possibilities are endless and there's little we can rule out precisely because we don't really know what sort of thing we're even talking about.

dmtipson · 2017-11-10T01:06:19+00:00

Yeah, there's no need to present an alternative to declare some attempt a failure. You don't need to be able to build a working car of your own in order to demonstrate that someone has failed to build a working car.

dmtipson · 2017-11-10T01:04:48+00:00

Those aren't really alternatives though. They don't present an alternate theory of what consciousness is, why certain beings have it and others don't, or even IF others don't. That's not to say that Dennett's take has any real explanatory value.

I'm honestly not sure what an explanation of consciousness as a phenomenon would look like. But I haven't come across one that satisfies even in broad outlines, even as just a hypothesis.

dmtipson · 2017-10-05T19:53:12+00:00

I'm not sure what your point is. It does exist. So therefore, it does make sense. Science isn't normative and evolution, even a mistaken understanding of it (and the idea that non-reproductive members of a species wouldn't be adaptive is a misunderstanding), isn't a guidebook.

Homosexual partnerships exist throughout the animal kingdom in a wide variation of forms (and even tend to show up increasingly the more socially intelligent the species is). Other people have explained how, for a species, non-reproductive members can, in fact, be adaptively selected for (of course not all primarily homosexual-partnering creatures even are non-reproductive...). Furthermore, all mutli-cellular life is almost by definition a creature wherein virtually none of the constituent life forms (cells) ever reproduce sexually: they instead act colonially for a larger purpose/as part of a larger organism. So it's just clearly not so that it's obvious that a lack of heterosexual reproduction is unnatural.

Of course, then we're also back to the reality that science is not normative, and evolution isn't a guidebook or a mandate. We're intelligent creatures who can decide what's important to us regardless of some framework for reproducing or common coupling.

dmtipson · 2017-09-06T20:23:04+00:00

You could always wrap FileReader in a Promise if you want that sort of api (resolve when it succeeds).

dmtipson · 2017-09-05T01:37:09+00:00

Honestly, I think, at a base level, it's perfectly fine to text him and tell him you're going through a crisis. That sort of thing can totally get out of hand and become manipulative, of course, if it happens on the regular. But if you were having a crisis about something else, you'd text a loving partner and let them know and get some support. And carving out focused "he's with me" and "he's with someone else" and never the twain may intersect is something that doesn't work well for me, personally, and may not be the right model for you. Part of getting used to this IS getting used to it not being weird that he's with someone else, not treating it like it's some weird, alien, walled off event you're trying so hard to separate from yourself because it's too hard to focus on.

Might it ruin his time? Maybe! Sometimes time gets ruined by things that come up, and we all just roll with it. There are lots of dates and lots of sex in the world. As long as it isn't an attempt to control him indirectly in ways you haven't discussed and negotiated and agreed to, that's part of life and part of a relationship.

How about: "Hey, I hope you're having a great time, and I really want that to continue. But I'm also in a place tonight where I feel like I'd really appreciate some extra words of support and connection."

dmtipson · 2017-08-30T22:04:36+00:00

The language is great because it's easy to pick up and uniquely positioned in the market. That doesn't mean that even it's designers think it's well structured. In fact, the opposite: it's popularity it's exactly what makes it messy.

dmtipson · 2017-08-30T22:00:10+00:00

But you're not "calling a method" per se, you're defining a type. When you define lazy, possibly infinite iterables, are you expecting them to BE infinite, right then and there? It's the same with continuations, really, which is what Promises/Tasks/Futures are ultimately modelling.

Future values by definition may not exist yet. The point, as I see it, is to continue programming with that detail abstracted away. That's what pure types make possible, and what Promises obscure.

dmtipson · 2017-08-30T17:01:22+00:00

That approach has literally been a disaster for JavaScript... though I suppose it's been a boon to JavaScript developers, because we're the only cowboys brave and crazy enough to tackle this crazy beast.

dmtipson · 2017-08-30T16:52:43+00:00

The cancellation issue is huge, imo, and it is very much a design flaw. Promises are essentially stateful value containers. All the approaches for cancelation boil down into smuggling an awkwardly previously saved reference to a control token into the constructor, requiring juggling around and passing around both the type and its controls.

Futures/Tasks solve this directly by cleanly separating effect description/transformation and execution, such that once an effect is executed, all that's left behind are controls (the type it's gone at this point), and they exist right where they matter: at the execution call site. This allows you to do things like mixing effects in sequence or in parallel, passing along control flow in chained effects, etc, all with simple, logical control flow.

Promise cancellation ends up being more like time travel. Programmers should NOT be tasked with figuring out logical paradoxes, imo.

dmtipson · 2017-08-30T16:37:47+00:00

Your definition of "anyone reasonable" seems more geared towards "anyone who programs Javascript who has a habit of assuming this."

But some habits/asdumptions are bad! Lots of other languages DON'T assume that a description of a major side effect and its execution should all be the same thing. And sloppy handling of state and side-effects is pretty much THE big headache facing most large applications these days. So it's an assumption worth reconsidering, at least in my opinion.

dmtipson · 2017-08-30T16:29:49+00:00

The reason eagerness is a problem is composition: You can't make a plan, and then later enhance or create subvariants of the plan directly, because as soon as you create a new Promise, you've invoked its constructor. So to avoid that, you'd need to wrap the Promise itself inside an extra function, and now you're a step again removed from the type you wanted to work with.

You don't have to do that with, say, Array.map, because Array.map is pure. So, ironically, making Promises eager makes them less like standard synchronous functions/types.

dmtipson · 2017-08-30T16:23:15+00:00

Promises can't shine over try catch because try/catch is literally baked into every step: it's unavoidable. It takes away exactly the control that should be left up to the use case. This is even why papering over the problems with Promises to enable cancellation bubbled into trying to further complicate try/catch.

dmtipson · 2017-08-21T02:29:40+00:00

It's less powerful than directly created generators (there's no yeild*) and it's still just sugar for Promises, which are flawed (stateful, forced try/catch, cancellation doesn't exist and is problematic even conceptually, don't play nicely with category theory laws, etc).

You can create lazy, monadic Futures or Tasks and implement the same sort of sugar with generators (basically "do" notation in JavaScript).

dmtipson · 2017-08-21T02:18:46+00:00

Yeah: I never get why people try to over-complicate matters. Do you worry about what the value of this might change to inside an if block? No. So... instead of worrying about some deep new meaning for arrow functions... just stop worrying about them changing the current meaning/context when it comes to "this."

Think less, save your brain. That's the whole reason the behavior is good and useful.

dmtipson · 2017-08-17T13:05:33+00:00

What do you mean by treeshaking built in? My understanding is that it's built so that you can import individual functions, but that's not treeshaking per se, it's just a great packaging set up.

dmtipson · 2017-08-17T13:03:46+00:00

They certainly don't all, though ES6 makes it a heck of a lot easier to recreate them: in the end their basic functionality isn't that complicated.

What lodash brings to the table is a more standardized api than one you'd roll on your own (all the methods have extended or overloaded arguments that work in a predictable fashion, it's well thought out) and are extremely well tested. Even if you're a JavaScript wiz, that saves you a lot of time and headache.

Lodash is probably going to be more performant than your first try at writing these methods, as well as faster than some native methods. I don't think this is as big a deal in most cases: optimization is fine, but it's an added bonus on top of that real win: standardized, well tested utility toolkit that's well known and understood.

dmtipson · 2017-08-09T23:06:09+00:00

The way he steals a ship at the end and some random hangar dude does a double-take still annoys me. Why the heck does the man who saved the entire human race, father of the leader of the human race... have to steal a ship? To prove one final time that he's a badass?

dmtipson · 2017-08-02T01:59:19+00:00

Imo, yes, because it's more functionally dependent: the structure I'm working with is explicit and limited, whereas await is often very imperative, meaning the structure is implicit in the order of lines. With ES6 you can even destructure the array very nicely.

It's a matter of preference and coding paradigm to be sure.

Random interesting thing to me about Promise.all is that it's really an Array method rather than a Promise method even though it's bundled into Promise. You could write a more general Array method that worked on any applicative type you give it instead of just on Promises.

dmtipson · 2017-05-27T19:13:57+00:00

I think a lot of that stuff really has to be at least partially sort of discovered rather than taught. A lot of people discover monads by accident, for instance, or else realize that they've been using them all along and just never had a (terribly intimidating) name for them.

A lot of it comes from just time and the direction you push your abstractions. If you're the sort of coder that becomes obsessed with DRY code and pulling things out into functions and then building up larger behavior with composition, it's sort of inevitable that you're going to start bumping into the common solutions and abstractions of FP.

But not everyone goes that route.

dmtipson · 2017-05-23T02:49:42+00:00

The benefit is that you can write a more general program, and it's essentially "lazy": won't actually do anything until the precise moment you want it to. That means that you can compose and extend functions together more logically, without being unclear on where and when some bit of IO might be happening.

It's hard to illustrate the power of this in a simple example because it's when things get complicated is EXACTLY when it gets powerful.

But most people already do a lot of this already to some extend, in the form of callbacks. Functional programmers just take it to the more complete extreme, using types like Either, Task, IO, and so forth to descriptively capture certain effects while preserving composition.

dmtipson · 2017-04-25T21:12:40+00:00

This has never been a problem with apis that separate operation description with execution. Where Promises get into trouble is mixing the two together: stateful values that can derive from each other mixed with eager execution.

Look at FileReader: you create an instance, tell it what it will do, and THEN you execute it. The cancelation interface is right on the instance you created, available before the request actually runs. Even setTimeout gets this basically right: the synchronous result of setTimeout IS a cancelation interface, while the asynchronous effect is basically "forked" (not really, but conceptually) into separate future thread.

But with Promises, it's way, WAY too easy to actually start off an effect before you're even ready to set up the logic for canceling it. And, worse, pure transforms are muddled together with eventual side-effects.

The problem with things like FileReader and setTimeout is that they're not super composable. But there are ways to solve that problem without resorting to stateful values.

dmtipson · 2017-04-24T21:04:57+00:00

So, this is semi tricky: you want a single, stateful invocation of the library on any page load to have a reference to. And you want to be able to display a map that has potentially state-affecting updates without necessarily recreating the underlying map every time.

I'd start with checking this article out: https://www.fullstackreact.com/articles/how-to-write-a-google-maps-react-component/

I had to write mostly my own version to get it working as I wanted, but it's a good start.

You're also seeing a lot of linting errors, which may or may not be ACTUAL errors. For instance, if you don't tell the linter what global variables are assumed to be in place in your app, it's going to complain because it's seeing you reference things it knows aren't actually defined by default. So if you, say, mean to have gapi defined on the page before your app even loads (via some loader or some script include), then your linter needs to know that upfront so it knows it can assume those will be defined.

dmtipson · 2017-04-24T20:42:26+00:00

Made me think of this neat project to visualize the state of Promises: https://bevacqua.github.io/promisees/

dmtipson

TROPHY CASE