The Deconstructed Standard Model Equation

For what they're calling "Higgs ghosts": There are two different ways of describing the electromagnetic and weak forces, and which one is best depends on how much energy the particles you're dealing with have. At really high energies, it makes the most sense to talk about a combined "electroweak force", described in terms of four fields with 2 components each (often called W1, W2, W3 and B), and one 4-component field (the Higgs field).

In contrast, at low energies, it makes more sense to talk about the electromagnetic force, with one 2-component field (y), and the weak force, with three 3-component fields (W+, W-, Z0) and a 1-component field (the Higgs field, again). So, where did the other three components of the Higgs field go? Well, we just rearranged things - if you check, the total number of components stayed the same. There are various names for this rearrangement, and I haven't seen this one before, but I guess they're calling these "missing" components "ghosts".

As for the other type, the Faddeev-Popov ghosts, those are more obviously mathematical artefacts. Normally, you'd start by writing down a "physical" Lagrangian ("physical" here meaning something like "written in terms of actual physical fields").

But it turns out that you can't actually calculate with the physical Lagrangian. So you have to rewrite it in a (mostly) mathematically-equivalent way, which involves extra fields. These fields come along with extra rules which basically say "no state you can actually measure involves the ghost fields in any way". Really, they're just there as a calculational aid and aren't physically "real", and they're called "ghosts" to reflect that.

Hope that's at least vaguely comprehensible, it's difficult to explain this stuff without assuming a lot of background knowledge.

1. Medium. Math is mainly done with pen/pencil on paper, or chalk on a blackboard, or marker on a whiteboard. Programming is mainly done with keyboard on a computer. Those media are quite different. In a way, it's about ease of input - it's easier to write out a longer name with keyboard than with a pen.

2. Nature of the activity. A lot of math boils down to manipulating expressions given rules. It involves a lot of scratch work with a lot of backtracking and trying new things. A lot of programming boils down to easily reading and writing code and reasoning about how things work. Imagine writing "integral from a to b of f(x) dx" or "integral(f(x), x, a, b)" by hand a hundred times vs in an IDE and you'll see what I mean.

Explaining the equation you see in English words is what every physics book does, however the equation itself represents a concept that is not human. It comes from an alien universe of symmetries and relations and we have spent centuries to arrive at the current way of writing these down in a way which makes them easy to work with.

You can formulate the solution to a quadratic equation as:

The negative linear term, added and subtracted from the square root of the quantity which is the difference between the square of the linear term and the product of four times the constant term and the quadratic term, all divided by twice the quadratic term.

Modern mathematicians write:

x = (-b +- sqrt(b^2 - 4ac)) / 2a

The difference is night and day. You cannot remove the essential complexity from a problem. You can only try to get close to its representation.

You think mathematicians are minifying/uglifying their 'code' in the same way that one might use switch/case or ternary expressions instead of if/else if/else statements: in the name of concision/premature optimisation.

However, what the mathematical language is really doing is more akin to what jQuery is doing for JavaScript: it wraps low-level, complex and at times verbose mathematical statements into simpler representations.

Minification !== abstraction/syntactic sugar.

Because it is concise, precise, and widely accepted.

>Given the option, most development teams would choose to read and write against verbose source code, rather than scrape obfuscated variables and method signatures out of a minified, transpiled, compressed package.

What's your point? Source code is not the same thing as mathematics, not for the majority of software and not for the majority of mathematics as practiced by mathematicians. Verbosity makes sense when your domain involves concrete entities like "customers" and "widgets" and "thermal sensors." When your domain involves abstract entities like "ring homomorphisms" and "clopen sets" and "vector spaces," it doesn't. If you're writing a database, a name like "transaction_mutex" is more descriptive than "m." If you're universally quantifying over the domain of an arbitrary continuous function on the reals, "x" is about as descriptive -- and as conventional -- as any name you can come up with.

As an aside, I really wish we would dispense with the non-word "transpile." We have a word for translating a program from one language to another: compile.

>So why do we continue this archaic practice of obscure, inscrutable symbols in mathematics?

Because it works very well. I'm not sure what else to say. You spend maybe fifteen minutes learning about, say, the symbol "∂" when you're introduced to multivariate calculus, and then for the rest of time you have an extremely concise way of expressing a variety of combinations of partial derivatives that can be understood by anyone who has also been introduced to multivariate calculus.

Don't get me wrong, there are actual problems with mathematical notation -- overloading, "abuse of notation," and as often as not just plain omitting information -- but the use of non-ASCII symbols and short variable names are not among them.

One of the main things you "do" with expressions like these is to transform them into equivalent expressions that have some desirable form, or examine special cases that allow simplifications, or examine the result of applying some additional operation.

Compact symbols and single letter variables reduce the amount of writing you need to do for each step of such transformations, but they also make the "structure" of expressions more visually obvious.

Programmers also spend time transforming programs into equivalent programs (aka refactoring), but refactoring isn't quite as important to programmers as algebra is to mathematicians and physicists, so (popular) programming languages don't optimize for it to quite the same degree.

-1/2 Tr F_{\mu\nu} F^{\mu\nu}

for a suitably defined F. Or further abbreviated to something like L_g.

It just depends on how much detail you need to expose.