drostie

For what it's worth, it prevents you from negotiating an agreement that you were not going to win anyways. ISPs are an oligopoly in their present state. If they weren't, then it might make sense to deregulate, but since they are, it doesn't.

(1) No, this is fundamentally misunderstanding what happens when monopolistic assholes get to interact with people who are making life-or-death decisions. In those cases the monopolistic assholes always overcharge the crap out of the person who wants, more than to have more money, to be alive. You know how we keep getting news reports about why healthcare costs are higher in the US than anywhere else and it's a problem? It's invariably because there's monopolistic assholes involved -- and congrats, they just got higher due to abandoning net neutrality rules which prevent this from even being a thing.

(2) That cell phone provider was probably lying their pants off to you about the marginal cost of going from "you can use a couple apps" to "you can request the whole internet, but your bandwidth will be limited." It's very likely to be negative; you'd seem to have to build out more infrastructure to limit peoples' traffic destinations than you'd do to limit their bandwidth. (Think of the fact that Facebook is all-HTTPS these days, for example, so it's not like you're sniffing those packets without MITMing the whole connection.)

To address your earlier point, it's not really double-think. The point is, in the presence of the oligopoly the ISPs are basically Internet countries, with a strange but unelected oligarchic government at the top. We have somewhat more freedom than most to emigrate, but that's about the biggest difference. Net neutrality is an externally imposed free-trade deal among all of them. They are expressing that no, they would instead really like to charge taxes and inspect imports like makeshift customs officers, at their own anti-transparent discretion. They don't want the free-trade deal. It is indeed a valid response to say "well, tough, you're going to have this free-trade deal because the benefits of free trade for everyone in terms of innovation and public good outweigh the benefits those taxes on imports and exports will bring to your shareholders."

The L1 point is a saddle point in the local effective potential: it is therefore not stable enough for an object to stay there without station-keeping.

So yes, the goal here would indeed be to detect life capable of creating large structures and keeping them actively in orbit. There is some tongue-in-cheekness to this sort of research, but as the abstract notes, also some seriousness. The tongue-in-cheekness is that we're nowhere near being able to build something this large between Earth and the Sun; as the abstract notes, it has to be around as large as the Earth in order to usefully eclipse the Sun; that's a very very large structure, and we're certainly able to get into space right now: and yet we have no prospects even in the next many thousand years for engineering anything at that scale, unless folks are right about an impending technological singularity.

The seriousness, on the other hand, comes from one consideration: blotting out the Sun is probably easier than fleeing to nearby star-systems. It's very hard to say exactly how much energy it takes to flee to a nearby star-system, but a lower limit for the technology that I can presently envision is maybe 10^20 J of kinetic energy; my imagination might not be very good though, but I think that's reasonably conservative. Now the solar power irradiating a disk-that-blots-out-the-Sun is known to be 10^17 W or so. So the claim is, to even harvest the level of energy that is required to try and scout out neighboring star systems, one needs Sun-blotting scales of energy-harvesting technology; the length scale could maybe be smaller by a couple orders of magnitude to scout, but one can imagine that the energy needs of billions of entities fleeing their home planet would be several orders of magnitude larger, too.

There are indeed a lot of competing ones. Highly recommended:

• CIS 194 @ UPenn, https://www.seas.upenn.edu/~cis194/fall16/

• Haskell Programming from first principles, http://haskellbook.com/

• Real World Haskell, http://book.realworldhaskell.org/

A block chain is a similarly verifiable append-only log and map. However, block chains loosen the restriction of "trust this other singular party but verify what they have done" and broaden that to, "trust the majority of nodes in this network, but verify." It's likely that there is some improvement in the periodic "publish an authoritative tree hash" step which digital currencies do not use yet, see the table at the back and think about how many cases one needs to download the entire ledger for with digital currencies... But of course the proof-of-work schemes are important to get that "majority of the nodes" trust.

I think that will be the tasting necessary to prove this pudding.

I would also point out that you do have parse errors in your scheme (incorrect indentation errors) and that parse errors are not actually a bad thing (if you think about static analysis tools, they can only work under the assumption that not every bytestring is a valid, useful program, and they get better the sparser that valid, useful programs become).

ES6 is JavaScript.

It's the latter. The JSON encoding example is actually a really bad example for this language because there is a huge class of JSON which it cannot easily be seen to encode, though you can probably make some exceptions. An example of the many undefined things would be:

    {"abc def": ["123 456", 789, 101112, null, false]}

A better DSL for JSON would have to include actual data types or so,

    obj
     abc def
      arr
       str 123 456
       num 789
       num 101112
       null
       bool f

...or so.

I... think some humility would serve you well.

You are making some very audacious claims about the data structures,

    -- rose tree storing data on internal nodes rather than leaves
    data AugmentedRoseTree x = ART {node :: x, children :: [AugmentedRoseTree x]} 
        deriving (Show, Eq, Ord, Functor)
    
    type TNT token = [AugmentedRoseTree token]
    type TN = TNT String

You seem to be making these claims on the basis that there is the following serialization of such trees:

    serialize tn unlines $ concatMap linesOf tn where 
        linesOf (ART x subtrees) = x : [' ' : line | tree <- subtrees
                                                   , line <- linesOf tree]

Arguably there's something missing from these in the form of treating blank lines, but let's take a semantics where the deserializer deletes blank lines...

Of course as you're undoubtedly aware, the deserializer for this only gives you a `TN` and to do useful things with this requires a `TNT token` for some more interesting (semantically) token type, your approach is apparently to use the simplest tokenizer,

    tokenize :: TN -> TNT [String]
    tokenize = map (fmap words)

I guess I just want to point out that while syntax is certainly super important, these data-semantics are not all that novel. In fact they are a subset of s-expressions, assuming parentheses are not used in the lines themselves (and why would they be if `words` is used to parse them?):

    sexpr :: [AugmentedRoseTree [String]] -> String
    sexpr (ART xs subtrees) = "(" ++ unwords (xs ++ map sexpr subtrees) ++ ")"

Note that the subset you're carving out requires the S-expression to only contain bare symbols as its first several elements, with not-bare symbols being the "indented" parts.

On the flip-side, S-expressions have certainly changed the world computing-wise... I am just dubious that in reinventing a subset of them with slightly better syntax that you have fundamentally changed computing beyond what they already innovated for you.

But, if you want to start a new smallish programming language and see where it goes, this means that a lot of that way is already cleared out for you; feel free to translate Scheme[1] into your new syntax and you will be able to do some things that you are not even dreaming about yet, like macro expansion.

[1]: http://www.scheme.com/tspl4/

I think that the original article made it clear that it was a correlation, not a causation.

There is probably some underlying cause to both trends, something like "there are people who tend to be really ticked off about 'this operates slightly different in two different environments', such people are more likely to (a) use spaces and (b) have an engineering-type job that pays a little more." Another possible correlation would be "people who are more worried that they will someday have to SSH into a machine where they have not yet configured an editor in order to insert debugging statements into the live production code, tend to come from DevOps backgrounds that earn slightly more, and also tend to favor spaces instead of tabs because that damn default tabstop is 8 and I can handle 2, 4, and maybe even 3, but 8 is too damn high..." or so.

I personally really preferred tabs in my youth as a sort of nod to democracy and "everyone can set their tabstops however they like!" -- and it was Python that finally got me to use spaces instead, with the "hey when you want to do multi-line stuff" arguments[1] and PEP-8 and community agreement and such. But I do miss my little tab characters a lot.

[1] You know, stuff like "If you want to do multi-line stuff, then you need to keep a conceptual split between using tabs for indentation but spaces for alignment; and if you're using spaces for everything then you don't: you can even use your tab key to insert many spaces at once. So it's tab-tab-tab-hit-space-twenty-one-times versus tab-8-times-then-space-once. Worse, if you screw up the mixed tabs-and-spaces format then you won't know about it unless tabs are clearly visible by default, which adds visual noise to your file..." etc. etc.

Yes. Oh my god yes.

So there is this HUGE part of biophysics that we completely isolate all of the undergraduate students from, with these pretty videos where one machine magically swims out to exactly where it's supposed to go and then the next machine magically swims in to do the next thing and then the next machine, and so on, until you've got this perfect assembly line chugging away at this stuff. That is NOT what happens.

The reason that we make those "schematic" videos is that if we drew the real video, you could get overwhelmed by detail and miss the actual mechanism that we're talking about. What's actually happening is that this whole activity is happening in one big churning sea of all of these things knocking into each other bouncing around chaotically. That one machine that went to the right place is symbolic of hundreds of machines that happened to bounce off into the wrong one; that straight line is symbolic of an average of a million possible bouncy trajectories which went in all sorts of different directions before getting there. Everything is at a high enough concentration and pulsating and buzzing so much that in short order the "right stuff" happens to bounce together to do whatever is happening. Sometimes, even, the cell makes the "local concentration" of some machine or part even higher, via either containing some structure within a bag or else by producing proteins which attract "the right sort of thing" to them, so that more nucleotides or whatever happen to be nearby.

Just to give a more concrete example, in the fertilization of an ovum, we showed you a nice picture of one single solitary spermatozoon which shakes hands nicely with one ovum, and they became best friends. We also tried to scare you with "just one sperm is all it takes!" reasoning, which is technically true but misleading. If we were showing you the absolute truth, you'd see that the ovum is getting beaten down by a bunch of spermatozoa pelting it like a pack of wolves, trying to break down a chink in its shell, called the "corona radiata", until one of them burrows into a thin tear. Then the eggs of most mammals have to chemically shift composition of their borders to actively prevent "polyspermy", getting penetrated by multiple spermatozoa, through that tear. What's really fascinating here is that we're not completely sure how this happens because usually this process is happening during meiosis, another of those things where we separate the story for the textbooks ("meiosis happens, then you store the resulting cells, finally some of them bubble up for fertilization" -- no, meiosis actually has these two long pauses in it; long-term storage happens during the first one (the "dictyate") and fertilization happens during the second one before meiosis is complete). So it's hard to say "this prevention of polyspermy is due to meiosis" vs. "it's due to fertilization."

Suddenly it's not so much of a surprise that some of your friends were trying for years to conceive while some teenagers you know of got pregnant too soon -- that "it only takes one" rhetoric makes people very worried very rapidly, "what if I waited too long, what if I'm infertile" and the "there is literally a wall there and it's a matter of luck whether something breaks through it or not" story reveals the real emotional truth: "oh, we have like no real control over this; whatever will be, will be."

It's just that at the lowest levels there's a ton of bouncing chaotic pulsating activity, things smashing into each other routinely, and heck, the only reason that your proteins even keep their characteristic lumpy shapes is that they're designed by evolution to take on this shape when water molecules are bouncing against them chaotically enough that they happen to curl up into it. The machines to replicate DNA similarly are sitting in a sea of nucleotides smacking against them, which is why the helicase can't unzip too far ahead of the polymerase; that polymerase might be able to handle the stray nucleotide that binds prematurely to the DNA, but it might have real trouble if an extended sequence gets accidentally bound that way.

I did something similar with a project for Node.js called nermal[1], which comes with an example called `tagaloop` that I still use to store my passwords. Even though it had a bit larger of a scope (it is a library for encrypting/decrypting arbitrary JSON with AES-GCM + scrypt + random-length-padding), one of the examples is a password manager called `tagaloop`. It did not really get the sort of traction that I hope you're going to see -- good luck! Fortunately I can still call it a success because it has made my life much easier in many cases.

We both can make different choices and that's OK, but I'm happy to see as a design point that both of our password managers are interactive loops to avoid the history management of the shell. I will say, though, that my files routinely hold way more than 4 passwords and listing them all for the user to choose by number is not really appealing: so one of the biggest things that `tagaloop` does is that it just lets you grep through them at the interactive console. You might want to consider that as a very important feature.

[1] https://github.com/drostie/nermal

This is a solid question and it's worth an answer. There's kind of four things I want to get to: 1. the hardware is highly varied; 2. there are some fundamental operations which any hardware is going to have to be a quantum computer; 3. the actual "programs" consist of some precisely timed electrical signals turning on or off some of those fundamental operations in order, followed by (and occasionally interleaved with) these destructive "blasts" which actually tell you what's going on inside; 4. it helps to maybe revisit 2 and 1 once you know that with some specific examples.

1. You know how there's a lot of different hardware implementations for computers? There's Babbage engines, there's the silicon that we use every day, once upon a time there were vacuum tubes and such... we get a lot of freedom because the definition of computation, e.g. the definition of a Turing machine, just involves a sort of abstract manipulation of symbols but does not say anything about how those symbols are embodied in reality. The same bits that are high/low voltages in your CPU or copper cable can be flashes of light in a fiber-optic cable or aligned spin-domains in your spinning hard-drive or whether current can flow through a channel in your flash SSD. The oldest trick in the book is to represent one set of "logical" bits as a different pattern of "physical bits" (which then get represented their own way downstream) in order to correct errors or transmit heavily biased signals without net voltage bias or whatever.

Same with quantum computers. We don't know which hardware is going to scale so we've got spin qubits and superconducting flux qubits and cavities with super-high-quality mirrors pointing inward which trap photons, and all sorts of other qubits. But you can think of these as small little isolation chambers which must be shielded from each other and the rest of the world, maybe microscopic, perhaps all in a row. We have many candidates for what goes in the box and how the following operations are done.

There are some possibilities for alternative designs for "quantum computers" that are not the conventional quantum computer design, for example D-Wave is trying to do the quantum annealing thing, have lots of these things all connected. But researchers like the following approach because it is very concrete and has separable concerns which can be separately addressed.

2. There are some fundamental operations which these little rooms need to be able to do.

First off, we have the entanglement operations. These need to be able to shove these rooms together so that they affect each other. When shoved together, what matters is a set of 4 energy levels, E00, E01, E10, E11, of how much interaction energy there would be if both bits were forced to 0, if one bit was forced to 0 and the other was forced to 1, etc -- and the absolute value of these energies (not just their differences) also matters relative to the baseline energy B that all the other qubits experience while this happens.

The shoving operation is actually allowed to be pretty much anything that generates a "nontrivial" set of E00, E01, E10, E11, because it's the hardest thing to get right and yet only one little property of it ("quantum entanglement") is really needed.

The next operations are the room-phasing operations. These apply to any room by itself, and come in two forms: you can either raise the energy of the room relative to all of the other rooms (which only affects things if this room is entangled with the other rooms), or you might create an energy difference between the 0 state and the 1 state, or so. It turns out that you can think of all of these as a rotation of a sphere[1], so a very common model is to have "pulses" of light or magnetism or whatever in two different physical directions, with very precise control over how long that pulse lasts, to give full ability to twist these spheres that way.

The final operation is the readout operation, which requires "blasting" the qubit somehow into some really big system which can report and process the measurement. The nice thing about blasts that there is a nice chunk of theory which says that readouts don't actually have to happen before any particular time, though you might need them to happen after some entanglement step or so. There are quantum versions of all of the logical gates which can be implemented on this thing if it is too hard to blast away the room to get a bit of classical information, and then connect that to all of these lasers or whatever that are manipulating this system from these different directions.

The "blasts" are certainly different from the "pulses", the "pulses" need to basically have no real input or output, they just need to change the local environment a little bit. The "blasts" need to hit the specific device slightly harder in some way. The technical difference is that examining the outcome of a pulse you should not have any idea whether the qubit is more 0 or more 1 or anything else about it; after the blast, you should have total knowledge about whether the qubit is 0 or 1. So usually these two need to exploit some sort of very different physics.

3. So, how the computers are actually used is, we get four or more of these boxes together and try to figure out a routine to start out the first four rooms in the |0000> state, move it to the |1111> state representing the number 15, and then we try to figure out whether we can run the quantum factoring algorithm to find out that fifteen is three times five. So there is some fussing around with the thing as it's brought to ultra-cold temperatures, then there are some time-controlled pulses from which do these bit rotations, some lower-finesse entanglement steps where the particles are somehow connected for some set times, then there is maybe some other schedule of more pulses... and then finally your readout lasers blast the thing, and get 4 bits out of it, and we write down what binary number we saw. We repeat a lot and we find out, woah, 40% of the time this was 3, and 40% of the time this was 5, and 20% of the time it was something else. We then daydream of the day when this 20% becomes low enough that we can run a quantum error-correcting-code on top of this thing so that we can use three times as many qubits but the error will drop rather than increase.

4. Just to get some ideas of what the hardware might look like inside this room, let me give two examples.

In flux qubits, which are maybe coming up on 20 years old or so, there is a little superconducting loop which holds the qubit as a superposition of currents going clockwise and counterclockwise around it, the single-qubit pulses are accomplished by firing microwaves at the thing, while the actual readout is done by another superconducting loop that is in close proximity called a SQUID, this thing is sensitive to electromagnetic induction, which. You measure your ability to fire a bunch of electrons through the SQUID in order to figure out whether the current in the flux qubit is going clockwise or counterclockwise. By contrast this "bringing the rooms together" operation really needs to bring these two micrometer-sized devices into inductive contact so that they start influencing each other. And of course nothing is superconducting at room temperature so this all is happening in some big refrigerator.

Another promising thing in recent years has been the "NV qubits," which consist of a nitrogen atom sitting in one of the carbon locations of a diamond's crystal lattice, a "defect" in the otherwise perfect lattice. These can be made to 'fluoresce' or flash, so you can just see where they are and then deposit some structures on top of wherever they turned out, and the key is that you get a nice spin state in the qubit which has a nicely long lifetime even at room temperature, so you don't need the elaborate cooling setup that you need for superconductors -- and it interacts nicely with microwave pulses to do the single-qubit manipulation. There are some tricky problems with readout just because diamond has a very high index of refraction, which means light moves very slowly in it and gets bent a lot, but the bigger problems occur with trying to get these things to interact with each other since you basically just have this diamond lattice and it has some nitrogens in it and you can't really move them relative to each other or insert some sort of spin-wires into the lattice that will connect the two spins or anything like that. So it's missing this most-important property of the entangling operation. My guess is that if one of these looked like a computer it would have to have these little diamond qubits doing this process via some elaborate setup existing above the chip, some constant source of short-lived microwave photons which could be entangled with these qubits and then with each other, then immediately measured and the measurement used to tweak the NV qubits, leaving only the residual entanglement between the NV qubits. But you would see the same pattern of a computer program as some timing of pulses that are fired at these systems, combined with some timing of these entanglements-by-photons or so.

[1] https://physics.stackexchange.com/questions/204090/understan...

"String theory."

TeX is a joke.

I mean, it's not a joke for its intended purpose; that's fine. It typesets the #$@! out of documents. But TeX is a joke for mathematical notation in particular. Put another way: the best way to understand what an arbitrary mathematical expression in LaTeX really means, is to render it as an image and read that image. TeX can be understood best as a concise way of writing a certain class of vector images, and when you are reading TeX you are reading a computer program which generates an image.

I'm not saying it can't be used for this context, of course it can, I have used it a ton and found it quite enjoyable. The fact that it's an image-based representation makes it very easy to switch from `\int_A dx~\int_B dy~f(x,y)` to `\iint_{A\times B} dx~dy~f(x,y).` However let's not mistake the fact that TeX does not know and does not want to know how you are using the `\int` and `\iint` symbols, is 100% OK with omitting those `~` characters, and has no semantic conception of what `dx` and `dy` are. If TeX were the CAS that it doesn't claim to be, as far as it's concerned that expression could be canonically refactored to `\iint d^2fxy(x,y),` since no one wrapped the `dx` and `dy` in curly braces. TeX claims to be a typesetting and layout system, and it does that well; it's not trying to be a universal mathematical notation.

The contention of the original link posted is, all of these image-based formats like PDF and lecture videos are going away. This may or may not be true, but if it is true then TeX is not going to survive the death of images, precisely because it is a programming language for a class of images.

Maybe something else will survive. The biggest player right now is the Wolfram language, of course, but that can look terribly unwieldy too.

So the transform is what we'd write as a matrix as:

    [-4  -6]
    [ 3   5]

This matrix corresponds to the following linear transform: if you hand in the pair (x, y) it gives you the pair T(x, y) = (-4x - 6y, 3x + 5y). The word "linear" means that T(x1 + x2, y1 + y2) = T(x1, y1) + T(x2, y2) for all x1, x2, y1, y2 and that T(k x, k y) = k T(x, y) for all k. This has a nice interpretation in terms of the "vector space" underneath; a linear transform "distributes over vector addition" and "commutes with scalar multiplication."

In fact vector spaces are super-general. The set of infinite sequences of real numbers `[a0, a1, a2, ...]` is a very nice vector space, and the Fibonacci recurrence F[n] = F[n - 1] + F[n - 2] is linear in such infinite sequences. It can be solved by F[n] = p^n for two bases p=b1, p=b2, and then you can see that any other sequence obeying that recurrence relation must have the form F[n] = A b1^n + B b2^n for some constants A, B. It's the same principles of linear algebra which get you there. (Exercise: solve the Fibonacci recurrence for b1, b2 and find A and B such that F[0] = 0, F[1] = 1, the normal Fibonacci numbers.)

Anyway, back to the matrix. As you can see the trace of this matrix (sum of diagonal entries) is 1, and the determinant (for a 2x2 matrix, the product of the diagonal entries minus the product of the other two entries) is -20 + 18 = -2. It turns out that the trace is always the sum of the eigenvalues and the determinant is always the product of them, giving a nice way to understand this as the eigenvalues +2 and -1, the only two numbers that you can multiply together to get -2 and sum together to get +1.

If we know that these are the eigenvalues then we would calculate the eigenvectors by looking for a non-trivial nullspace, T(x) = k x implying that T2(x) = T(x) - k x maps this nontrivial vector x to 0. Since the - k x is the diagonal matrix diag(-k, -k), we are looking at for k = +2 the matrix

    [-4  -6]  +  [-2   0] = [-6  -6]
    [ 3   5]     [ 0  -2]   [ 3   3]

Now that looks like a very degenerate transform! T(x, y) = (-6 x - 6 y, 3 x + 3 y), what's going to map this to (0, 0)? Just x = -y will do perfectly nicely. So (1, -1) is one representative eigenvector for an entire eigendirection (t, -t) for all t. Plugging that into the original we also see T(1, -1) = (-4 + 6, 3 - 5) = (2, -2), proving that this is all 100% self-consistent.

The other eigenvector comes from,

    [-4  -6]  +  [+1   0] = [-3  -6]
    [ 3   5]     [ 0  +1]   [ 3   6]

This takes a little more thinking, the eigenvector is (2, -1) representing the eigendirection (2t, -t) for all t.

Now what's the basic reason that you're doing all of this? Here's what: the eigenbasis. These vectors are not orthogonal, but they do span the space with a skewed coordinate system. Any vector

    (x, y) = a (2, -1) + b (1, -1)

Call these new components {a, b} with curly braces.

To solve for it explicitly, notice that {1, -1} = (1, 0) and {1, -2} = (0, 1). So x (1, 0) + y (0, 1) = x {1, -1} + y {1, -2} = {x + y, -x - 2y}, and we can find that a = x + y, b = -x -2y.

Now if you pay the pain of using these skewed coordinates to begin with, then the matrix has a very nice representation in these coordinates: T{a, b} = {-a, 2b}. It just treats both of these coordinates independently, scaling them without mixing them. If you want to repeat it n times, it will just be T^n {a, b} = {(-1)^n a, 2^n b}. (Exercise: one of those roots b1, b2 for the Fibonaccis, let's say b2, has absolute magnitude less than 1, hence its exponentiations drift towards 0. Program an algorithm to calculate the Nth Fibonacci as `round(A*pow(b1, n))` and see how it does.)

What complicates things a little is that usually your vector space is also an inner product space, and often that inner product has a nice structure (a, b) . (x, y) = a x + b y, in the orthogonal coordinates. It loses this structure in the skewed coordinates. Fortunately the physicists have a very nice notation for these cases coming from their work in relativity: it is to write vectors with both "upper indices" and "lower indices". The idea is that if we're using the basis (2, -1), (1, -1) then for each vector of the basis, we find a vector which has two properties: first, it's orthogonal to all of the other vectors of the basis; second, its dot product with the vector that it corresponds to is 1. These vectors form the "dual basis".

So the vectors perpendicular to (1, -1) have the shape (t, t) for all t, we dot (2, -1) . (t, t) = 2t - t = t, so we choose t=1 and find that the dual vector to (2, -1) is (1, 1). Similarly the vectors perpendicular to (2, -1) have shape (t, 2t), dotting this with (1, -1) gives t - 2 t = -t, setting that to 1 says that t = -1, so the dual vector to (1, -1) is (-1, -2). [These mirror the expression {a, b} = {x + y, x - 2 y} above, and for good reason.]

So the idea is that we represent every vector in two ways, with its "contravariant components" v^1, v^2 such that v^1 (2, -1) + v^2 (1, -1) is our vector, and its "covariant components" v_1, v_2 such that v_1 (1, 1) + v_2 (-1, -2) is also our vector. When we do this we discover that actually we get dot products back to a nice diagonal form even in a skewed coordinate system, that form is u_1 v^1 + u_2 v^2 + ... = u^1 v_1 + u^2 v_2 + ... . If you've got a nice crystal structure in physics, you might have, say, that the electrical conductivity really "wants" to be expressed in these skewed coordinates, where if you go down any of the natural directions of the crystal the material responds via Ohm's law. If it has slightly different resistances in slightly different crystal directions, say, then because the crystal is a skewed coordinate system, if you apply an electric field in an arbitrary physical direction you will in general create a current in a slightly different physical direction. But in the skewed coordinates it just looks like `J = {s1 E1, s2 E2, s3 E3}` corresponding to a diagonal conductivity tensor `diag(s1, s2, s3)` ... it's just that when you're not in the crystal structure you can't quite see that this material wants to flow in a couple of skewed directions preferentially.

As mentioned beneath, the comment was secretly fixated on the 'stored procedures' side and not the 'prepared statements' side. Stored procedures have many costs associated to them; for example, they don't get version-controlled by default and they don't lend themselves easily to a development/production schism; both of these need to be solved by writing out some sort of database-synchronizer-script which will handle fallover. In addition usually you cannot issue breaking changes to an SPROC without scheduled downtime, so you have to intentionally have a flow of "create new SPROC, make code use the new SPROC, deploy across the codebase and audit for the old SPROC's use, finally remember to drop the old SPROC so that old code doesn't get recycled by someone who is looking for the first thing that does what they want." Compare that to just "commit a new patch, then upgrade servers as soon as possible".

I asked the ##math chat room on Freenode about cohomology recently, more precisely I expressed that it was for me the scariest math-word-that-I-don't-know-yet, and I received the explanation "it isn't that scary once you get used to it; it's just a way to repair exactness of sequences." Maybe that helps?

For topology, I feel like there's a sort of meeting-of-two-different-things; one starts with being very frustrated with the delta-epsilon-definition of "limit" and its one-dimensional nature, and the limit-definition of "continuous" and its clumsiness. The other starts from wanting to play with spheres and Möbius strips and knots and the like. When you're playing with these shapes a bijective mapping between two surfaces is not a fine-grained-enough idea because it is not continuous; adding continuity gives "homeomorphisms" which also aren't a fine-grained-enough idea because they do not make reference to the space an object is embedded in; wrap a torus about itself in a pretzel knot and you have something which is homeomorphic to a torus but in 3D you can't get there without tearing part of the surface through the other one, but in 4D you can. So finally we come to the idea of an isotopy, which bumps "continuous" to the next level by saying "Just like you can have a continuous path of points in space, you can have a continuous path of homeomorphisms from one to another," and that's where the pretzel knot becomes finally distinct from the torus in 3D, there is no continuous path from the homeomorphism of the pretzel knot to the torus, to the identity homeomorphism of the torus to itself. Or something like that. So this path is then an "isotopy" and then certain things are nicely isotopy-invariant and so forth.

I think you're maybe expecting much more than you should, which is why you think that "the language of bugs also serves to mask what the issue is" (it doesn't; both are deep-dives into the causation of unexpected behavior). I think if you get more clear about what you're expecting from Penrose you'll have a better foothold for why you're not getting what you're expecting.

It does make sense that our ability to understand the incompleteness theorem is very close to self-contradictory -- I don't know that I'd say it is, without a doubt, self-contradictory; I have not dove deep into how provability logics might force □(a → (p ∧ ¬□p)) into a contradiction, and what you need for that (possibly with reasonable axioms it merely derives ¬□a which just means that if there is an algorithm for understanding then we'll never uncover it?).

QM does not by itself plug the hole in our understanding; Penrose has never said that to my knowledge. However a tiny part of quantum physics is the only known part of physics that's capable of producing nonalgorithmic results (the vast majority of QM is linear algebra in funny hats), hence if we've got a nonalgorithmic result it makes sense to follow our "best theories so far" towards that tiny part of quantum physics.

The word "this" is key, and the reasoning why it's this unknown, and not, say, our unknowns about the arrow of time or whatever -- see also my comments below. If you're going to stay in the realm of normal conventional physics and try to explain the phenomena that he's trying to explain, those conventional physics steer you towards this particular part of physics as a crucial step in understanding how we're able to accomplish certain forms of reasoning in general.

Your frustration in your first sentence I would equate to a general human frustration that we all feel when we see our own sins reflected in others -- you don't back up your claim so you get mad at me for not backing up my claim. I could in turn make a really good case that the burden of proof is not on the person who says "he doesn't make that argument" to prove that he doesn't, but on the person who says "he makes that argument" to prove that he does. And then we can go back and forth in negativity, I suppose.

In an attempt to avert that spiral of world-suck, let me attempt to instead meet your request head-on. Penrose is not saying what you say he's saying, and would not be able to fill up two books with your argument.

Let's talk hacker for a second. What you're saying is that Penrose is basically saying "well I don't understand this bug in my computer program, and I don't understand the kernel in my computer, so therefore a kernel bug is causing this bug in my computer program." You are going to be predisposed to see any reduction of a bug towards the kernel as being evidence that yes, your characterization of the argument is correct and the argument is indeed laughable. This is understandable if someone just told you that hypothesis off-the-cuff, which I surmise is how you've probably encountered Penrose. (That is, I take the fact that you're laughing as evidence that you've not read both The Emperor's New Mind and Shadows of the Mind.) The alternative however, is that someone has (a) a high-level statement of "this shouldn't be happening", and (b) knows that the only way that such things can happen, barring things like the MMU misbehaving, is a kernel bug, and (c) has been attempting to trace down the code to the fundamental syscalls, and found that the thing-that-shouldn't-be-happening is indeed bracketed around one syscall in particular which does not seem to be doing what the docs say it should do. And if a hacker has attempted all of this, I mean, they might still be wrong: but their argument is no longer something of the form "I don't understand the kernel and I don't understand this bug, therefore the kernel caused this bug." It is something more sophisticated than that, and you're doing a disservice by laughing at them.

One and a half of Penrose's books are ultimately about why the computationalist/algorithmist thesis of brain function seems deeply incomplete -- that a hallmark of some certain examples of reasoning appears to be deeply nonalgorithmic. (For example The Emperor's New Mind supplements his usual Godel argument with arguments that if brain plasticity comes from local neural plasticity then it is unlikely to have a great generality, but by a clever analogy if it does have a great generality then not only does that mesh with an idea of global plasticity, but it is very unlikely to be algorithmic. The one and a half books are basically full of little digs that, seen together, do seriously undermine faith in the thesis.) This is essentially the "bug" above. His favorite example is that we are capable of proving to our own mathematical understanding that our mathematical-understanding-algorithm contains true sentences which we will never be able to prove; if this algorithm exists then it is able to prove something that it will never be able to prove, which seems like a straightforward contradiction. But there are one and a half pop-sci books that he's written building up some other problems with this thesis in a way that even if you don't start off with knowledge of the relevant physics/comp-sci/whatever, you can hopefully understand it enough to appreciate the problem.

He follows these up with a principled dive into what's actually underlying these "bugs". That is, he discards ideas about souls and takes it seriously that our reasoning is realized in our brain, and takes seriously that this is a biochemical system, and evaluates whether the noncomputable phenomena that he is "debugging" can come from chaos or randomness or the like. He is able to rule most of these out with auxiliary considerations, and so tries to get one level closer to the hardware: the biochemsitry is well-modeled, we know, by physical chemistry; there are likely no new fundamental interactions or whatever to be found in biochemistry.

Looking into the physical chemistry level he finds that it can be somewhat cleanly divided into two parts: quantum and classical. Technically, it's all quantum: but you can handle a lot more with various classical rules of thumb, and this has basically all been done before him so he can just steal those results:the classical part of physical chemistry and probably even the vast majority of the quantum part of physical chemistry are algorithmic, it is known that quantum computers don't do other things than what computers do; they just might do many things more quickly. There exists only one part of the quantum part of physical chemistry which is not.

Unfortunately, he doesn't have access to the source code, nor docs for what nature does--so he actually constructs physical-chemistry models that could hypothetically do the sort of buggy things that he's seeing at the top-level that he has carefully ruled out at the other levels of explanation.

And this is all to say: as you can hopefully now see, these books contain a lot more than simply "we don't understand X, we don't understand Y, therefore Y causes X." Namely there is an actual understanding for example that X is realized in a system which has to be modeled with Y, and which has some features that can only come from certain corresponding features in Y, which we actually do understand very well. There has been a solid amount of good effort to push down that causal chain until one is left at these syscalls and then saying "something is fishy about those." And his argument might indeed be wrong, there are many little parts where maybe he's wrong about how chaos works and how it could cause a similar bug, just as our programmer above might be wrong about whether two processes are properly synchronized via locks or whatever -- but it's no longer this laughable thing of "ha, he doesn't understand X and Y so he thinks Y causes X!" that you're trying to say.

That's kind of the modus operandi of physics, I suppose. Max Planck started from a specific conclusion, that the spectrum of the Sun is limited at high frequencies in ways that Maxwell's theory clearly is not, and then searched for some way to explain the difference.

Downvoted because Penrose does not actually commit this fallacy, therefore naming it after him is something of a cheap shot, an excuse to not actually engage with his ideas.

To be a bit playful, there is a sort of "Magic: the Gathering" version of this dissent, if it helps people.

So a Conviction is basically a type of enchantment which says you have 3 fewer life points and trouble getting a job. Now someone managed to cast Reverse Conviction, which exiles one conviction -- it's not even in the graveyard, as much as legally possible it's like it never happened, with the only exception being double-jeopardy laws etc. And the question is whether you get those life points back.

According to the majority opinion, having your life points converted into tokens on the State Government card was part of the ongoing enchantment, and so this ended when the enchantment ended: they should be converted back.

According to Clarence Thomas, it was an instant effect that happened when the enchantment was cast, and the ongoing effects were the other parts of the enchantment. So when it was cast, that was the time when you were "deprived" of your life points; it's not an "ongoing deprivation" but a single event which happened in time. You don't get them back unless another card in play says you do.

(A more full analogy would also include the fact that there is this Exoneration Act card which says "(3) Take a conviction token from the State Government and gain a life point. You may not do this if there is an enchantment which creates these tokens either on you or in the graveyard," and a house rule called Due Process which says that you cannot be deprived of life points without some card in the field of play saying so. )

You're not wrong, if the only verb is `c.expand()`. In Haskell you would write:

    -- omitting the definitions as trivial...
    cmdline (Suite box (Compiler cmd _ out_opt) (Test binary sources))
        = intercalate " " [cmd, sources, out_opt, binary]

     testSuites = [Suite srvr comp test |
         srvr <- [box1, box2, box3, box4],
         comp <- [gcc, clang, msvc],
         test <- [frobnicate, loadtest, end2end],
         not (binary test == "loadtest" && ram srvr < 8)]

(Note that Haskell lets you specify what `==` means so probably the above should say `test == loadtest` more directly...)

If there are other verbs then it might not be 100% equivalent. For example one might want a sort of "Non-uniform random choice monad," let's say a monad of "Choosers", which will quickly generate a random candidate test suite. If you wanted to support both, you'd want to quickly define:

    class Monad m => MChoice m where
        choose :: [x] -> m x
        invalid :: m x
        invalid = choose []
        mfilter :: Bool -> m ()
        mfilter True = return ()
        mfilter False = invalid

    instance MChoice [] where choose = id

Then you can say,

    testSuites :: MChoice m => m TestSuite
    testSuites = do
        srvr <- choose [box1, box2, box3, box4]
        comp <- choose [gcc, clang, msvc]
        test <- choose [frobnicate, loadtest, end2end]
        mfilter . not $ test == loadtest && ram srvr < 8
        return $ Suite srvr comp test

In this respect maybe Cartesian programming represents a generalization of the list monad.

It seems like the wheel problem could be solved by a dowel rod that would keep things rolling along until they fell over? I suppose that unfortunately gives another way for the thing to get clogged up?

I'm surprised that this strategy isn't more quicksort-ish, I was expecting a first pass into warm or cool colors, then another pass into large or small lego, etc.

Yep, you got it. The trick happens entirely during that fan-out of cards that Penn and Teller are inserting into. The trick is that Kostya's bottom hand is not a passive receptacle but is actively reaching out underneath the deck to grab any face-down cards and pull them onto the bottom, but he's practiced it so well that it doesn't look unnatural or jerky. The "into" hand is holding in order:

    1. a few face-down cards on top to make it look like it's still mixed,
    2. all the face-up cards plus Penn's card, which went in face-down,
    3. all the face-down cards plus Teller's card, which went in face-up.

At 4:04 Kostya does a simple move which Penn and Teller are totally allowed to see which reorients these; indeed, Penn's bellow at 4:06 is apparently because he was 100% convinced that this was going to be a "blink and you'll miss it" trick: maybe swapping out the deck, maybe the cards are not perfect rectangles and he can separate them at will, maybe a dozen other ways he knows to get the same illusion -- but instead he just saw the guy turn half of the cards over, meaning that they were already split into face-up and face-down: and he had totally missed it because the cards seemed to move so naturally and the hand underneath was 100% totally hidden from him.

Oh man, that is devious. You can just barely see the finger-work from the camera's perspective; but Penn and Teller didn't stand a chance.

Right, in text adventure games it is very easy to code a one-way door (e.g. "your brother Ralph has been kidnapped!") and a door which requires a key (e.g. "if you have the voodoo doll you can give it to Alice, who will then open the portal to the underworld"). If the one-way doors are dynamic (e.g. "if you tell the police the secret, then you piss off the mob boss: afterwards any attempt to go into the mob lair leads to death and restarting from the last save point") and you are not paying careful attention, then that key might easily be in an unreachable part of the game ("crap, if I wait too long to get Ralph back and, before that, I piss off the mob boss, then I can never get the voodoo doll from Ralph, and so Alice will never open the door to the underworld and now there's nothing left that I can really do").

It is especially important because of how frustrating the resulting loss is; it does not even have the dignity that you get from killing Vivec in Morrowind, where the game informs you "sorry, this game just became unwinnable." You just wander around after doing a bunch of actions that made sense at the time, not realizing that your brother Ralph was twisted up in some crazy voodoo plot. "Yes, Alice, I see that you have pains in your arm that you think come from some voodoo doll, I don't see how that has any relevance to anything though: I've searched this whole damn city and there are no voodoo dolls anywhere." Until later "Oh wait... there was that one alley on the other side of the mob lair, it looked empty at the time but what if that's where Ralph is now?"

You're not wrong to notice the VPN side: what are most of our examples? Malicious service providers! What's a VPN? An intermediate service provider!

I did say decrypt, and I did really mean it. SSH and TLS are not nebulously "hard to decrypt", otherwise we wouldn't use it because our servers couldn't decrypt the communications from our clients. They are hard to decrypt if you don't know a shared key. In MITM there are two shared keys: the client shares one key with the interceptor, the interceptor shares another key with the server. That's why the interceptor can decrypt.

Furthermore if we're talking the normal open Internet, the interceptor-server negotiation is dead simple because it looks to the server like any client-server negotiation. If you let anyone on the Internet access your pages through TLS, there is no hope to catch MITM on the server-side. It has to be defended client-side.

There is fundamentally no way to stop an interceptor who you have to send messages through from throwing away those messages and sending you the reply, "why yes, I really am https://mail.google.com/, here's my public key, let's negotiate a shared key so that we can talk in secret." Nothing. Because, you don't have an encrypted connection before you've negotiated that shared key. You aren't encrypted before you're encrypted. So for that setup phase, there's no way to stop them from throwing out those packets and sending that reply; we can only hope to detect that they are lying.

Now they are only telling us one thing, "here is my public key", and we want to know if they are lying about that. We have come up with exactly two strategies to deal with this client-interceptor side.

1. Like SSH does, admit defeat: but only for the very first connection. The very first connection, yeah, that could be intercepted. Then I will store your public key forever. Every time afterwards I will either use that public key, or else I will fire up the klaxons warning my user, and they will have to manually approve connecting and storing the new key. And that means you'll have to keep intercepting my traffic--even if I take my laptop to a different location or whatever--or else I'll find you out eventually.

2. Like TLS does, communicate some way of authenticating that public key through some other mechanism than the current internet connection. This usually happens quietly as part of downloading a web browser: that browser comes with a list of public keys of authorities whose digital signatures are trusted by the browser for authenticating public keys. If a site just sends me their public key? Forget it! They have to send me their public key plus a certificate issued from one of these authorities, saying "Yes, that is a valid public key for that domain," signed by a private key whose public key I know and trust. As long as I can verify digital signatures and they cannot be copied, I am good.

These are called "Trust on First Use" and, well, I'm not sure what you'd call what TLS does. Something like an "out-of-band" configuration of a "web of trust" I suppose. So those are the only options we've gotten working at scale, TOFU and OOBWOT.

I think you're being downvoted because there are two readings of your first question and reading the whole paragraph is needed to understand that the flippant reading "Psh, you say this is happening to you but I don't believe you, show me some evidence" is wrong and the humble reading "hey, how can I know that this is happening to me -- is it in the log files?" is correct. (It could also be that you're confessing ignorance even though you're also claiming certification though.)

The easiest MITM attacks for a civilian to perform involve a wireless router that traffic is routed over, with mildly more complicated but similar setups near a server -- say an untrusted server farm for example, or a malicious employee at a self-hosted location. More complicated attacks require messing with DNS so that people wanting to connect to that host instead connect to you; and really big entities like governments or advertising-hungry service providers could of course try to set something bigger up that affects more people.

The basic necessity is that the MITM computer needs to have an IP address, because the premise of MITM is, "you issue a request to connect securely to server IP 123.45.67.89, but you send your packets through me, and I have access to some IP 98.76.54.32. So now I intercept them rather than forwarding them on, and I connect securely to 123.45.67.89 myself, as well as to you. Now everything you try to send to them gets through, and its response gets back to you, but not before I intercept it and decrypt it and store it for later retrieval.

So the simplest way to do something like SSH is to imagine that I ask for your public key, you give it to me, I encrypt a shared private key with your public key, I send it to you, you decrypt it, and we use this private key for the rest of our communication. (That's not what SSH does, SSH does Diffie-Hellman, but similar reasoning applies.)

A MITM attack is then, you ask for the public key, I make a public/private key pair, I send you that public key, I ask for the remote server's private key for myself. You send me a private key, I send the remote server a different private key, and when you send something to the server, I now decrypt what you sent me, then encrypt it and send to the server.

Your main means of security in this scenario is actually 100% the same as your main means of security in SSH, it is that you trust that the private key of the server does not change very often. Therefore when you connect, you store the first public key you ever see; then each time you connect, you double-check it's the same or else you shout at the user "HEY! someone could be overhearing your data! Are you SURE you want to connect still?"

What's at issue in the article is that this crucial step was totally ignored by Hashicorp, it was brought to their attention and they just missed it.