> Our commitment? To tirelessly support our customers—zombie, ghost, or otherwise—while maintaining a level of integrity befitting the smallest scandal possible. After all, the abyss awaits us all… but here at MALIBAL, we’ll send you there with a smile.
it's worth reading some of the early smalltalk/MVC stuff to try to understand how MVC was originally formulated (http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerP...). it can be a little hard to understand, because it's pretty significantly different from how most modern GUI toolkits work, but (as i understand it, not actually having written smalltalk code) at its core it's fairly simple:
Model: business data
View: on-screen representation of Model; reacts to changes in Model to re-draw accordingly
Controller: maps user input to changes in Model; may need to interact with Views, and may pass control through a hierarchy of Controllers, to determine the Model being manipulated
in other words, user-input data flows as: C -> M, and M -> V. i see a Controller modifying a View (rather than just querying it) as impure MVC, and i normally strive to avoid it, even though that's essentially impossible if you're forced to use a platform's GUI toolkit.
i don't think of MVC as having "gone wrong," but rather that the name has been co-opted and the pattern corrupted by so many different people, in many different ways, as to make the original name extremely confusing. iOS' concept of "MVC" drives me crazy. i think it's probably fair to call it MVP (Model-View-Presenter), the difference being that the Presenter can indeed do some of the work of modifying the View. but i still mostly think of this as a hack: the more work that gets shoved into the Presenter, the more complicated it gets.
i would argue that we can't accurately infer any likelihood without knowing what the entire probability space is. in the dressing-room example, we are assuming there are not many, many dressing rooms that look similar, and many, many people that look just like us, and many different sets of the same clothes. but that is just an assumption. we have no idea about the probability space of different material universes and how qualia is embedded in them.
i'll admit that that's a convincing argument, but there are ways in which apparent causality can be shown to be illusory. one thought experiment i remember from school involves someone watching a movie in which one character punches another character, and the punched character falls backward. suppose the watcher knows absolutely nothing about how movies are recorded, or re-played, and sees only the lifelike images; then there would be clear, apparent causality of the second character falling over as an effect of being punched by the first. in reality, the only causality is that set up by the mechanics of the movie projector.
i do not believe in materialsm, but i do believe that intention and goals are emergent phenomena. nevertheless, i think that's mostly a separate issue.
it is a false equivalency to say that materialism is false and that it is impossible to build strong AI. if the material world alone can be described
by laws of causality, then we should expect to be able to simulate some significant part of it. if it cannot, and if extra-material forces impact the material world, then we may have no hope. but existence of extra-material stuff (which i call "qualia") may or may not assert a force that affects the material world.
if i understand you correctly, you seem to believe that qualia definitely affects physical reality. we don't know whether that's true or whether qualia is just a byproduct of physical reality, and given the probabilistic nature of what we can observe physically, we may never know.
fair enough that maybe i'm not in the target audience. and perhaps i'm too stuck in my own head, writing iOS apps, where i can't imagine general constraint solvers being used to solve a software-design problem (as opposed to an algorithmic problem, where it certainly does make sense). i am genuinely curious - are general constraint solvers useful as a software-design pattern?
are one-way dataflow constraints really any different from the observer pattern? i avoid cycles exactly because i implement it myself, and don't even have a solver, per se. even KVO seems not to handle cycles. and when e.g. i am using auto-layout in IB, even then i am careful to avoid over-constrainedness, even though the solver can settle on a "solution."
while i will go off and read a few of the linked papers, this post doesn't do a great job, in my opinion, of showing a meaningful relationship between generalized constraint solvers and one-way dataflow constraints. i use one-way dataflow constraints because they are simple/natural/expressive. generalized constraint solvers are vastly more general, and i can't see how they would apply in a non-geometric setting. isn't cassowary only really interesting when there are inequalities? when there are only equalities, isn't the system either over-constrained (bad) or not (fine)? (to be fair, i haven't read the cassowary paper.) would i ever want code that expresses an object in terms of an inequality with another object? will i ever care about cyclic graphs of constraints between objects that actually require a solver to determine if they are over-constrained, and will any solver be able to do the right thing without knowing some properties of the constraints (e.g. linearity)? (cycles are the one thing i'm careful to avoid when i write one-way dataflow constraints in e.g. MVC code.)
In my opinion, the front page should really, really highlight the call-back-and-show-script feature. Sending this out to family and friends, this is the piece I really want them to see.
I read GauntletWizard's point as that such devices are becoming like "brain prostheses." If the device were embedded in your skull/brain, but could be wiretapped, would it be subject to the fifth amendment? If technology develops to read information from another's brain without their consent, would that be subject to the fifth amendment?