The halting problem also makes an assumption on the program's size. In practice we probably only care about programs under, say, a billion petabytes (or any other finite limit you can think of). In theory you can have a Turing machine that solves this regardless of the program's structure.
If you mean "programs that can only use a billion petabytes of storage", then that's true, but if you mean "programs whose code is less than a billion petabytes long", it's not true. (Someone recently calculated a result that I think can be interpreted directly as an actual decidability bound, and it's dramatically shorter than that.)
I meant that there exists a TM which solves HP for programs smaller than a given size. This makes it computable. Now, just because we can prove the existence of a TM, doesn't mean we can find it. It's true that for programs which use a finite amount of storage we can actually describe the algorithm for the TM, but that's not what I meant.
Because of the list of correct answers for a finite subset of the Halting Problem is finite, the Turing machine you mention does exist, but we not only can't find it, we can't know when we've found it!
Where the Math Overflow post mentions that "experts could compute the particular value of n", there has recently been such a bound published in a thesis, such that we can be confident that we can never construct or recognize the solutions beyond that point (using a particular axiomatization of mathematics).
You referred to the idea that "you can have a Turing machine that solves this", and we can agree on that with the caveat that, above certain problem instance sizes, you can't know or verify in any way that you have such a Turing machine!
It certainly takes its time :) Well, Bublé sound cool for projects where feature stability over time is critical (like huge codebases), but I will still prefer to go with babel to select which stage I want.
EDIT : just to be clear, I won't advice any sized team to go with staged features. It works for me because I do a lot a small sized project working alone on them and I'm ok refactoring their codebase if a feature implementation change.
I didn't know it was still in progress... really hope async/await makes it in. I'm betting on that pattern to make JavaScript much more pleasant to write!
It'll probably make it into ES2017, given that Edge, Chrome and maybe FF will have it in their browsers by the end of next year, official spec or not. It's a popular feature, and with Promises and generators in place, easy enough to support.
It really does cleanup a lot of code, but getting people to understand that an Async function returns a promise isn't always the easiest thing to convey until after it's been used. I resisted Promises for a while, once it became a part of ES6, and with async/await in Babel, I started using it... the cleaner code is worth the minor bit of overhead.
Threadbase is a really cool project. I'd definitely use something like this if it were available in my country. Good luck, I hope you succeed and go global.
I always thought it would be nice to have a GitHub-like thing for formal proofs. Where anyone can define a theory using a set of axioms, and everyone else can build theorems on top of it (and on top of existing theorems), with a series of formal steps that are verified by the system.
Cameron Freer started something like this, but I think it stagnated: http://vdash.org . Tom Hales put a lot of his formal proof work on Google Code: https://code.google.com/p/flyspeck . I don't know if he has any plans to migrate to GitHub, though.
Really glad to see React Native mentioned here, albeit briefly.
Hybrid mobile apps like the ones currently supported by Meteor always feel kind of clunky, and the 3rd party implementations of DDP for iOS/Android feel like a workaround and not the Meteor-way of doing things.
Would be interesting to see how React Native is integrated into Meteor.
Though what I really want to see is Blaze Native.
It's a pretty big hole, and it's practically impossible to seal. Which is why I don't think we'll ever see "game over" for piracy, no matter how advanced DRM technology becomes.
At this point, I think censoring the internet is the only way for the movies/music industry to win. Sadly this isn't so far fetched.
> it's practically impossible to seal [the analog hole]
It's easier than you think. Look at Macrovision. Look at the EURion constellation. All you have to do is make your secure video path emit some kind of signal not immediately apparent to human eyes. In a post-general-purpose-computing world, you can just make consumer-grade devices respect these signals and refuse to record and make professional-grade equipment both insanely expensive and specifically traceable.
I agree, but my point is this - If you can see it or hear it, then you can record it. Sure, the recording device you'll need in the future might be insanely expensive/rare/illegal, but there's also a lot of money in piracy.
