Ron Garret

This document reinforces my opinion that most coding standard documents suck. I’ve seen a countless number of coding standards from different companies (some of the companies I even worked for) and they all sucked. No exception. Even though coding standards have some common sense advice and guidelines which is generally helpful for producing code of good quality, the amount of arbitrary irrational rules and beliefs that coding standards writers put into the standards and try to enforce through the standards actually end up hurting the quality of the code produced by developers trying to follow those rules.

Case in point with examples from the NASA JPL coding standards for C:

* no direct or indirect recursion
What is it, FORTRAN-77? Some algorithms are way easier to implement recursively whereas the iterative algorithm can be much less straightforward and buggier. Think sorting: it’s easy to prove that the recursion is finite and that the implementation of the algorithm is correct. Do they use sorting in NASA or is it prohibited by this rule?

* no dynamic memory after initialization
FORTRAN-77 again! While dynamic memory management can be challenging in real-time systems and the generic malloc/free implementation is not acceptable, it doesn’t mean that statically pre-allocated fixed-size memory is better. It inevitably leads to brittle code ripe with excessive memory use, bugs like static buffer overruns, and sometimes even inability to use dynamic data structures…

As someone who doesn't follow his blog, my summary is: "lots of people have 'weird' interests. I think Smalltalk is the best programming language. It's so good it can help save the world."

Sure, there might be explanations elsewhere, just like there are evangelists for Lisp ... or Perl 6. And with similar arguments.

Take http://flownet.com/gat/jpl-lisp.html from 2002 as an example:

> I did try to introduce Lisp to Google. Having had some experience selling Lisp at JPL I got all my ducks in a row, had a cool demo going, showed it to all the other members of the ads team, and had them all convinced that this was a good idea. The only thing left was to get approval from the VP of engineering. The conversation went something like this:

Me: I'd like to talk to you about something...
Him: Let me guess - you want to use Smalltalk.
Me: Er, no...
Him: Lisp?
Me: Right.
Him: No way.

That was 17 years ago! Any essay which doesn't take into account the "Lisp-weenie" stereotype (see http://wiki.c2.com/?SmugLispWeenie ) is preaching to the choir.

I ended up putting this essay into the pile of other advocacy-for-language-X pieces I've read, with no interest in reading other blog postings.

But I did anyway. https://medium.com/@richardeng/how-does-python-make-thinking-in-code-easier-35a4dbb94711 ("Pythonistas will also tell you that Python’s syntax reads like English"). 1) It's a strawman argument, as I'm a Pythonista and I don't say that, and 2) AppleScript is…

I love following article: http://www.flownet.com/ron/QM.pdf

It basically shows that observation (measurement) and entanglement are the same things.

Think about it: particles are not magically going out of superposition as we observe (measure) them. We (our atoms) become entangled with those particles, we become superposition. It's just propagation of entangled state.

Why we don't perceive ourselves as in superposition? "It turns out that this result generalizes to any number of mutually entangled particles. If we ignore any one particle, the entropy diagram of the remaining particles looks like a system of N-1 particles in a classically correlated state with a non-zero entropy.". That means each atom of our bodies perceives other atoms entangled with it as they were not in any superposition (though as a whole, the system is still in superposition). We (atoms) are constantly entangled and in superposition with our environment, but we perceive it as classical state.

In what state each atom "sees" every other? According to probability. That's why in double slit experiment we see only one of most probable outcomes, not a random one.

Time could be rate of entanglement propagation. Entanglement propagates with speed of light (speed of particles), so we seem live in same timeline. But if something moves away from us with speed of light, the time for this object goes slower, but only relative to us.

Until two particles interact with any way, they live in totally different…

One of the better sources for these differences and their magnitude is Peopleware. Instead of citing vague research "somewhere", they did their own primary research. More specifically they set up coding wars where different programmers at different companies assigned to the same task independently.

They found 10x differences in time spent on the average coding war (which was typically a pretty small sample) with those finishing faster typically producing programs that worked better. So by any reasonable measure, at least 10x productivity.

There is your 10x, right? Wrong. They found that the best predictor of programmer performance was the performance of another programmer at the same company. Furthermore they managed to correlate a lot of that performance factor to specific factors, such as having a phone that turned off, a private room, adequate desk space, and so on. There was still something like an unexplained factor of 3 left over, but they didn't know whether it was environment variables they had not looked at (eg training), individual ability (which might be correlated across institutions), etc.

It is true that this research happened in the 80s, before the Internet was widespread. I would love to see it replicated again.

(Note, I'm aware of the existence of many other poorly controlled studies, see http://www.flownet.com/gat/papers/lisp-java.pdf for an example, but what is critical in the Peopleware study is that they acquired information both about…

Interestingly to me, a lot of your points apply to my own favourite language, Lisp.

Regarding a lack of private anything, it's possible to monkey-patch any Lisp package or class however one wants. And of course, one can get true privacy in JavaScript if one wants, by using closures — the same trick applies in Common Lisp.

Lisp debugging is great: one can set up all sorts of condition handlers and restarts, and invoke them from the debugger.

Lisp is a great blend of imperative, functional & object-oriented programming styles, enabling you to use the right tool for the problem at hand.

Lisp is incredibly fast, faster than C & C++ in a few cases and almost always Fast Enough™. It's dynamic, but inner loops can be made very static for performance. There's even a standard way to trade off safety and performance, if that's what's important in a particular case.

I don't know for certain, but I believe that Lisp was the language that invented hot-patching (well, I suppose one could always have done it from assembler …). It was even used to debug a problem on a NASA probe[0]: 'Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem.' As with JavaScript, the Lisp debugger is part of the standard and is always available. This can be profoundly useful.

And Quicklisp is a nice, modern way to pull down…

I'm having a difficult time following his explanation. Here are a few of my stumbling points. Maybe you can help me out.

1) What does it mean that entangled particles are supercorrelated? How can S(A|B) = 2 or -1?

2) The formula for Von Neumann entropy is S = -Tr(p log(p)), where p is the density matrix. How do you take a log of a matrix?

3) Why does the interpretation rely on the density matrix? I've always thought of the density matrix as something that gives information about our ignorance rather than the system (this is why the density matrix mixes classical probabilities in alongside quantum amplitudes/probabilities - observer uncertainty is classical). Therefore, to me, any good interpretation of quantum mechanics ought to work without density matrices.

Unfortunately his paper here (http://www.flownet.com/ron/QM.pdf) doens't seem to have significantly more information than his talk.

Thanks for any help you can offer.