omphalos

Consider the problem of predicting an agent's binary choice. If an agent follows a strategy of always choosing the opposite of what the algorithm predicts, then the algorithm's prediction will always be incorrect. A "true future predicting algorithm" cannot correctly predict the actions of certain kinds of agents, as long as those agents can observe the prediction.

People are not their governments. Viewing competing governments as competition between their countries - I think that is propaganda. The US government violates the privacy of US people through mass surveillance. Now it is competing for control over social media. Yet the goal of mass surveillance of US people, which harms US people, is justified in terms of US interests.

During the cold war all sorts of things were justified because they made sense from the perspective of US (governmental) interests. The Vietnam war, the Mujahideen, the toppling of free and democratic governments. In a "realist" framework, the ends justify the means. The "ends" and "means" here are considered from the point of view of the statesman.

When the world is viewed as a chessboard between competing nations, human beings outside the decision making centers suffer - we are reduced to being expendable resources, collateral damage, in the pursuit of "national" interests.

The money is there, it just mostly resides in the hands of the few. The mean net worth of an American household is almost $700,000 - that's total net worth of all households, divided by number of households.

FYI I see [dead] by your comments. Maybe you have been hell-banned?

Yes, and a lot of it isn't, which is what I'm saying :)

Money isn't the only motivation someone can have. People write lots of open source code for free, for example.

I think it's because of the common assumption that the system that controls your data must also house the application that interacts with this data. When decentralized applications finally arrive (the inklings are already here) users won't be forced into this false choice. In that sense, companies like Google and Facebook are behind the curve, and don't really represent technological "advancement", but rather a social shift that has legitimized itself by falsely presenting itself as inevitable.

I kind of think of imminent battle between decentralized/centralized as analogous to the Linux/Windows wars of yesterday. Over the short term you're probably right that centralized services will win. But because decentralized services yield control of your data, they have the potential to be so much better for the consumer than centralized services.

Privacy-wise Palantir is even scarier than Facebook.

Seems like an argument against the idea that patents encourage innovation.

It's remarkable how a company with so many resources can make something so poorly designed.

Can people join this network without downloading an application - will it be available in the browser? The reason I ask is most decentralized applications up to this point require a download to start your own node (zeronet for example). Availability from the browser I believe is important for decentralized applications because it lowers the barrier to entry for consumers.

PS., not sure if you noticed, but some of your comments on this page are marked dead. I have no idea why this has been done to you.

The "grid" is a graphic design principle [1] that existed long before CSS. You can implement this in CSS with flexbox or something else. If you don't care about vertical alignment of elements at different heights on your page then you probably don't need a grid framework.

[1] https://en.wikipedia.org/wiki/Grid_(graphic_design)

Well it's not exactly common. It's used to describe the very best moves at the highest level of play.

> the stark degree to which "AlphaGo output that move because the board will later be in a winning state" sometimes doesn't correlate with conventional Go goals like taking territory or being up on points

Minor quibbles: 1) taking territory or being up on points are the same thing, and 2) in go there are many other things to optimize for besides territory/points - influence, shape, efficiency, and sente being examples of this.

I wish the author included something about the Intel Management Engine. It runs closed source software with privileged access to your entire machine including support for remote execution, has a history of critical vulnerabilities, and is present on every current Intel chip.

Yeah, MCTS is traditionally terrible with ko. It would be interesting to learn how AlphaGo addresses or doesn't address this.

I recently encountered the Duhem-Quine thesis on wikipedia which I think presents a really interesting perspective on testability, something I never really questioned before in the philosophy of science.

[1]: https://en.wikipedia.org/wiki/Duhem%E2%80%93Quine_thesis

Reminds me of nobackend.org

Now if only they would stop requiring JavaScript to see images :)

It would be nice if the ability to reason about execution timings were one of the design goals of WebAssembly, because this could make it safer to port to crypto to the web.

What should happen is that we do incremental computation, sort of like what's described here [1]. You ought to be able to declaratively specify that such-and-such collection maps to such-and-such elements. If you change just one element in the collection, change tracking built into an incremental computation framework should cause that one element to update. Logically, there's really no need to review the entire collection if just one element changes.

Certainly the Virtual DOM is one way to let you declaratively write to the DOM and not worry about change tracking yourself. But it's not the most efficient way.

Unfortunately this sort of thing has never been implemented in JavaScript (that I can find) so currently the Virtual DOM is probably our least worst choice, at the moment.

[1] https://blogs.janestreet.com/introducing-incremental/

You can read section 3.7 of their paper for an overview: http://static.benet.ai/t/ipfs.pdf

I imagine you could go through their codebase to try to see how far this has come along: https://github.com/ipfs/go-ipfs

According to this, it looks like the implementation is currently in progress: https://github.com/ipfs/go-ipfs/blob/master/dev.md

Hope something in there helps you.

Yes and additionally (with Chrome's DevTools) you get out-of-the-box functionality like the ability to set a break point, live edit your code right at the breakpoint, and save your change right back to the filesystem. With transpiled languages this kind of workflow is generally less streamlined -- I don't know why more people don't complain about it. The best alternatives I've seen are when people completely reengineer the workflow - I'm thinking about the Elm debugger as an example.

I believe they have an "IPNS" protocol which is intended to handle mutations.

IIRC I believe tailspin was based partly off the Narcissus codebase. I think MetaES is better because it gives you a debugger whereas Narcissus isn't pausable (last I checked). Additionally MetaES is written in plain ES5, which I think is another plus over Narcissus in terms of general usability. Narcissus' focus was mainly on prototyping language features and I get the impression that compatibility was never a concern.

Ah, sorry I missed that! Very nice!

I think there's definitely value in this kind of JavaScript-in-JavaScript type of dev utility. The main advantage is cross-browser dev utilities - which brings us closer to a cross-browser dev environment.

Browsers have historically opted for hiding runtime management (debugging, etc) behind myriad APIs, most of which can't be accessed from the running program itself. I would love to see a cross-browser way to hook into these sorts of things without extensions or at least with standard APIs.

Overall this would be much better for us as coders. And this would open the way for all sorts of cool tools. Consider V8's live code reloading functionality. But imagine if it worked cross-browser and could be called from the program itself. Your webserver could send a signal over websocket, and you could perform hot-swapped deployments of your webpage, and all connected browsers would be updated. The browsers could be customers', or they could be inside that mobile device that's a pain to debug.

It would also be much easier to prototype new dev tools and ways of coding. For example, programming against Chrome's extensions APIs (as great as they are) is somewhat limiting - last I checked you lack direct access to the embedded CodeMirror editor for example. There are a lot of security-focused restrictions. So people workaround this. They rewrite editors and file managers from scratch so they can get the desired flexibility (lighttable, brackets, atom, etc).

Personally I love to see projects like MetaES because I feel like they are inching us closer to something that could be the next step.

Yeah, it seemed designed for educational examples, and worked within in a VM. But I couldn't find a way to easily interop with the external JavaScript environment. It was well-tested though and passed the vast majority of test262.

MetaJS has some open issues - some related to the fact that it's intended to let you step through code, which I think makes certain interop scenarios difficult (let's say for example native code calls MetaJS code and expects a return value - it's not possible to set a MetaJS breakpoint there because the native runtime isn't paused).

I would be curious to know how MetaES fares under something like test262. I think a metacircular interpreter that does well in an extensive suite like that could indeed be a proper, "safe alternative to eval" (as suggested by another commenter).

Reminds me of https://github.com/int3/metajs

I like this kind of stuff.

A particularly interesting take on this is tailspin, although the repo appears have been taken down: https://github.com/wthimbleby/tailspin That one offered a reversible JavaScript debugger written in JavaScript, which I thought that was very impressive from a technical standpoint.