Why Command and Vector Processors Rock - <AUTHOR> http://www.codersnotes.com/notes/command-and-vector-processors/ <comment><USER2> This is one thing that amazed me about early mainframes, the hardware was the API. It was designed to be used, not abstracted over and cleaned. In the modern world each abstraction layer fixes problems of the layer below, exposing its own flaws that are fixed by the layer above. With exokernels, nanokernels, picokernels and unikernels mabye we can get some of these qualities back. If an abstraction because pervasive enough, then we can make hardware that implements the abstract hardware interface.

<comment><USER3> Not likely, because the base idea of those "kernels" is for them to drive the VM performance envelope closer to that of a container.

<comment><USER4> Isn't that a core idea of mainframes too?

<comment><USER2> Some of this has been achieved via widely used PCIe devices, those control registers are now a defacto standard for talking to the outside world.

</comment></comment></comment></comment><comment><USER5> The evolutionary growth of the PC platform provided for some powerful things. But we've lost a bit of the "engineered system" principle in the process.

Like the Apple II I suspect such an integrated system was a pain to expand. There were later Amiga OSs so perhaps this was possible, but I don't know how well they maintained compatibility with original programs.

<comment><USER6> As long as one programmed through the OS API, things were guaranteed to work. Even the AGA CustomChips were backwards compatible with ECS, just as ECS was backwards compatible with OCS: the addresses were the same, and so were the control / function bits in them. Newer ChipSets simply added additional CustomChip registers. The biggest source of incompatibility on the Amiga were the processors, as newer ones introduced instruction and data caches: software which used self-modifying code, a concept taken over from the C=64 would crash instantly due to cache being out of sync with memory.

Hardware expansion was and remains a breeze with the AutoConfig protocol and the Zorro-II and Zorro-III expansion buses. Many people run their Amigas with additional sound and graphics cards. There are even PCI bridge expansion cards.

<comment><USER5> My main concern is that if you have a publicly documented chip that explicitly concerns itself with timing it makes it very hard to shave off cycles in the future.

The Apple IIhad similar problems. Woz moved a lot of stuff to software to save chips but it causes compatibility issues in the future.

</comment></comment></comment><comment><USER3> I can't help wonder if this is the root of the schim forming around Linux.

Where more developers, and more and more "admins" are less than interested in the underlying hardware, because all they see during the day is piles upon piles of VMs and containers that abstract away the actual hardware being used.

And then there is a dwindling group of people with at least a token interest in the hardware, but they are either being ignored or ostracized by the abstract software people.

<comment><USER7> That is a side effect of the UNIX culture, because the hardware doesn't matter as long as you have C and POSIX.

Even OpenGL and audio APIs made it so that most of the time the cards you have plugged are irrelevant.

Being a old timer, which also has spent quite a few time with Amiga users/devs back in its golden age, it took me a few years to realise, that in what concerns desktop graphics programming, macOS and Windows communities are much more welcoming than UNIX focused ones.

You see this quite clearly on macOS, those that came from Mac OS days (pre OS X) focus on UI/UX and the whole experience as a dev taking advantage of an unified software/hardware stack.

Those that came from BSD/Linux just use CLI tools as if they were in any other UNIX.

Which is one reason why the demosscene never thrived on GNU/Linux.

<comment><USER3> I think it has less to do with C and POSIX, and more that Unix from day one was multi-user, you can't have someone "bitbang" hardware when there are multiple users accessing.

Also, i think perhaps you conflating issues here.

While sure they may be more interested in the GUI (though you will find plenty of TUI programs in the Unix world, and even some in Windows that has been inherited from DOS) the newer generation is less likely to be interested in the actual hardware beyond that it works to run their precious "apps".

And IMO the demo scene were largely "dead" by the time Linux come on stage anyways.

This because the fixed hardware models of the C64 and like were being supplanted by the mix and match PC, where the only commonality is the BIOS and the CPU ISA.

<comment><USER7> The demoscene is pretty much alive, here are some 2017 events.

[http://www.assembly.org/summer17](http://www.assembly.org/summer17)

[https://2017.revision-party.net/](https://2017.revision-party.net/)

[https://www.evoke.eu/2017/](https://www.evoke.eu/2017/)

[https://nordlicht.demoparty.info/](https://nordlicht.demoparty.info/)

[http://outlinedemoparty.nl/](http://outlinedemoparty.nl/)

And some info about upcoming parties,

[https://www.demoparty.net/](https://www.demoparty.net/)

[https://demozoo.org/](https://demozoo.org/)

</comment></comment></comment></comment><comment><USER8> OP says you can't access the command processor on a modern GPU, but I thought that changed recently, now you can program the GPU hardware?

[http://gpuopen.com/amd-vega-instruction-set-architecture- doc...](http://gpuopen.com/amd-vega-instruction-set-architecture- documentation/)

Am I missing something, or is OP just a little out of date?

<comment><AUTHOR> Shader ISA != command processor

<comment><USER8> So you're saying the open ISA still doesn't allow access to the command processor? What sort of things does that preclude? Suppose you decided to write a game directly to the hardware instead of via DirectX or OpenGL, or a molecular dynamics simulation directly to the hardware instead of via CUDA, what would happen?

<comment><AUTHOR> If you tried to do it directly, you'd a) find it very hard as it's largely undocumented, and b) it'd probably break when the vendors decide to change it without warning on their new GPUs.

As for applications, well I dunno. One particular example would be Render To Vertex Buffer, something that ATI cards used to expose an extension for but NVidia cards didn't. Even though basically _any_ GPU could do it if the driver decided to.

A better use would be to allow the GPU to read the game's scene structure directly without even needing an API in-between.

</comment></comment></comment></comment><comment><USER9> To be fair, Vulkan/Mantle/DX12 and pretty much every console's API is a _very_ thin wrapper around the command buffer.

Like on Nintendo consoles the graphics commands tend to just be a macro to write an opcode and bump a pointer.

Xbox canonicalized this kind of management in their API as "push buffers".

Vulkan /Mantle/DX12 all have 'queues' which are just a memory centric view of the command processor.

<comment><AUTHOR> I wasn't suggesting a way to write your own command buffers, but instead a way to write your own code that _reads_ those command buffers on the GPU side. (running on the GPUs command processor)</comment></comment>


Kurt Gödel and the Mechanization of Mathematics - <AUTHOR> https://www.the-tls.co.uk/articles/kurt-godel-incompleteness-theorems/ <comment><USER2> One of the most interesting things about Gödel's Incompleteness theorem must surely be how _little_ effect it has had on the day to day practice of mathematical research. It's one of the most profound mathematical results in the last 100 years, and yet outside foundational fields like axiomatic set theory (Cohen's work on the Continuum Hypothesis comes to mind) it's quite possible to completely ignore the existence of undecideable statements. Gödel's work had a deep impact on mathematicians' _philosophical_ views of what they do, but that didn't carry down into the actual day to day business of proving theorems.

Isn't that strange? Wouldn't you think that undecidable propositions would be scattered through mathematics and turn up at curious and interesting moments in different fields? But apparently that's not generally the case. The Goldbach conjecture (Knuth) and of course the Riemann Hypothesis have been mentioned as possible candidates (but you might have said the same thing about Fermat's last theorem 30 years ago). If we did find a first-rank conjecture in number theory or some other area that's undecidable in ZFC (or whatever system) then we would at last be stepping through the door that Gödel opened for us.

<comment><USER3> Just like the conservation of energy has little effect on day to day practice of physics, besides blocking off an entire unbounded fruitless field of research into free energy.

In other words, impossibility results make it possible to have a practical discipline where people are focused on feasible approaches instead of spending all their time and money researching pie in the sky technologies that can never work. It's like when alchemy turned into chemistry and astrology turned into astronomy, because the fields became restricted to what is realistic.

Arguably the same still has to occur in other disciplines _cough_ AI _cough_.

<comment><USER4> With respect to Intelligent Systems, there are two important theoretical results.

According to [Shamir, et. al 2019] "given any two classes C1 and C2, along with any point x∈C1, and our goal is to find some nearby y which is inside C2. Our ability to do so suggests that all the classes defined by neural networks are intertwined in a fractal-like way so that any point in any class is simultaneously close to all the boundaries with all the other classes." Their results suggests that gradient classifiers (aka "Deep Learning") could remain forever fragile in ways that cannot be remedied by larger training sets.

Also important are the results on Inference Robust Logic, e.g. speed bumps) in the following:

[https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114)

<comment><USER3> This seems to be the case with all the widely used ML paradigms: NNs, decision forests, and SVMs. Favored for their high accuracy models which seem to come at the cost of massive overfitting and hence fragility.

I used a human in the loop approach for comparison, and those models, while not as accurate, seem much more robust. I think humans are better at identifying the big picture patterns, whereas ML approaches will microoptimize their way to a fragile approximation of the big picture pattern.

Practically, besides likelihood of breakdown, this means these overfit ML models are very susceptible to hacking. I predict once ML becomes more commercially widespread, we'll see a big increase in ML hacking.

</comment></comment></comment></comment><comment><USER5> > The First Incompleteness Theorem tells us that assuming PA is consistent, > one can formulate propositions that cannot be proved (nor disproved) on the > basis of PA, but which are nevertheless true.

As far as I know, that last clause was never a claim made by Godel. Specifically the claim that these propositions are _nevertheless true_. This follows quite simply from the assumption that either a proposition is true, or its negation is true (i.e. the law of the excluded middle). But I recall reading that Godel, in his proofs, went to great lengths to avoid the law of the excluded middle over infinite sets.

Indeed, (again AFAIK) godel's first incompleteness theory still holds in constructive mathematics (roughly where the law of the excluded middle cannot be used). As such, I think the addition that these propositions are 'nevertheless true' actually hides a lot of complexity. Because there are philosophical positions in which these independent propositions are neither true not false.

And really, this is why we call them independent. The truthiness of these propositions is not determined by their axiom systems. It's a rather big philosophical stance to say that the 'truth' of these propositions can be determined outside of the axiomatic systems. It seems to me like that claims there is an objective (as in, not dependent on an axiomatic system) definition of what is true.

<comment><USER6> There _is_ an objective definition of truth in any particular model. For any particular model M of, say, Peano arithmetic, there is an objective, unambiguous, perfectly well-defined notion of truth in that model (of course, the definition of truth cannot itself be formalized within the model).

<comment><USER7> > There is an objective definition of truth in any particular model.

"in any particular model" \- this is exactly parent's point.

From Wikipedia, a restatement of the 1st incompleteness theorem:

> there are statements of the language of F which can neither be proved nor > disproved in F

The truth of a proposition P, within F, means "P is an axiom of F, or can be proved in F".

Saying "there are statements of the language of F which can neither be proved nor disproved in F... but the statements are true nevertheless" is appealing to some 'objective notion' of truth that transcends F.

<comment><USER6> >The truth of a proposition P, within F, means "P is an axiom of F, or can be proved in F".

No, truth and proof are NOT the same thing. The system F needn't have any notion of truth. For example, Peano arithmetic has no notion of truth. Peano arithmetic has notions of zero, successor, addition, and multiplication--none of truth.

Almost all competent mathematicians would agree that there exist theorems in the language of PA which are neither provable nor disprovable in PA but which are nevertheless true. Here, "true" means "true in the standard model of PA", not "true according to PA"\---the latter isn't even meaningful because there is no such thing as "truth according to PA".

<comment><USER7> Out of curiosity, could you give some examples of such theorems?

<comment><USER6> 1\. The original example would be Goedel's own example, namely, the statement (formulated in the language of PA) that PA is consistent, i.e., that PA does not prove 1=0.

Less contrived examples are:

2\. Goodstein's Theorem [https://en.wikipedia.org/wiki/Goodstein%27s_theorem](https://en.wikipedia.org/wiki/Goodstein%27s_theorem)

3\. A theorem stating that every computable strategy is a winning strategy in the hydra game (see [https://faculty.baruch.cuny.edu/lkirby/accessible_independen...](https://faculty.baruch.cuny.edu/lkirby/accessible_independence_results.pdf))

4\. The strengthened finite Ramsey theorem, see [https://en.wikipedia.org/wiki/Paris%E2%80%93Harrington_theor...](https://en.wikipedia.org/wiki/Paris%E2%80%93Harrington_theorem)

<comment><USER7> Thanks!

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> > formalism: the idea that mathematics can be reconstructed in a content-free > manner, or more strongly put, that mathematics itself is nothing but "a > formal game of symbols".

This is a common misrepresentation of Hilbert's Formalism. It doesn't state that _no_ mathematical sentence has content beyond its mere symbols, but that _not every_ mathematical sentence has content beyond its mere symbols.

Formalism was meant as a compromise between the two dueling philosophies of mathematics of the time: Russel's Logicism, which essentially said that all of mathematics can be derived from some self-evident, obviously true, logical axioms, and Brouwer's Intuitionism, which essentially said that the truth of mathematics stems from empirical confirmation that breaks down when infinities are involved, and therefore some logical axioms cannot be taken to be true for infinites. Hilbert tried to accept Brouwer's finitist philosophical position without rejecting any useful axioms. Formalism, then, separates mathematical sentences into two kinds: "real" \-- those dealing with finite quantities and can be tied to physical observation and prediction, and "ideal" \-- those dealing with infinities. Instead of rejecting the latter, Formalism says that as long as they don't introduce inconsistencies that invalidate the former, one could view them -- the _ideal_ sentences -- as having no content beyond symbols, i.e. as not referring to anything "real".

<comment><USER9> Brouwer was absolutely not a finitist! Indeed, he completely rejected the idea that you could use formal logic to bound what mathematics could talk about.

A better (but still not entirely accurate) description would be that Brouwer had an epistemic conception of mathematical truth: mathematicians become able to assert mathematical truths as they engage in the process of constructing mathematical objects. This is indeed a constructive process, but it isn't finitistic -- for Brouwer mathematical reasoning is open-ended rather than a closed set of rules.

So much like Goedel (who disagreed with Brouwer in many other respects), Brouwer was totally committed to the idea that mathematical statements actually mean things. And because they carry meaning, the mathematical process and the properties of the mathematical objects created by a mathematician take precedence over the rules of logic.

This is why Brouwer rejected classical logic -- not because of any finitistic reason, but because (for example) classical logic permits disassembling the continuum into its set of points. Since (for Brouwer) the point of a continuum is that it is continuous, it followed that any logical principles (such as classical logic plus set theory) that permitted you to break up the continuum were fallacious. This is why he spent a lot of time on his so called "strong counterexamples", such as his proof that intuitionistically all total functions on the reals are continuous.

Notice that the direction of reasoning here is exactly the opposite of what a finitist would accept: Brouwer used the properties of the continuum to justify various finitary logical rules, rather than the other way around. The continuum was real, and logic just a façon-de-parler.

I find this kind of thing really interesting because it illustrates that the pretheoretical idea of truth can be formalized in many different ways, and that the various formalizations are not all compatible with each other. We are used to informal ideas like space having many different mathematical realizations -- metric spaces, topological spaces, vector spaces, etc -- but it is a little disconcerting (and a lot fascinating) to realize that logic and truth exhibit the same plural nature.

<comment><USER8> Hey Neel! Brouwer was a finitist in the sense that he did not accept infinitist axioms. His epistemology indeed was one of "mathematicians become able to assert mathematical truths as they engage in the process of constructing mathematical objects," but the justification was empiricism. I.e., his concept of establishing truth was by empirical, and therefore finitist. Here he is in "On the significance of the excluded middle in mathematics", 1923 (in Heijenoort):

> Within a specific finite "main system" we can always test (that is, either > prove or reduce to absurdity) properties of systems, that is, test whether > systems can be mapped, with prescribed correspondences between elements, > into other systems; for the mapping determined by the property in question > can in any case be performed in only a finite number of ways, and each of > these can be undertaken by itself and pursued either to its conclusion or to > a point of inhibition [here is his mention of induction that I provide > below].

> ... On the basis of the testability just mentioned, there hold, for > properties conceived within a specific finite main system, the principle of > excluded middle

> ... It is a natural phenomenon, now, that numerous objects and mechanisms of > the world of perception, considered in relation to extended complexes of > facts and events, can be mastered if we think of them as (possibly partly > unknown) finite discrete systems that for specific known parts are bound by > specific laws of temporal concatenation. Hence the laws of theoretical > logic, including the principle of excluded middle, are applicable to these > objects and mechanisms in relation to the respective complexes of facts and > events, even though here a complete empirical corroboration of the > inferences drawn is usually materially excluded a priori and there cannot be > any question of even a partial corroboration in the case of (juridical and > other) inferences about the past.

Note his use of "testability", "natural phenomenon" and "empirical corroboration." So the source of truth is nature by way of empiricism, and that demands finitism. Even his reasoning about the continuum was finitist: no determination on order/separation can be made after examining a finite prefix of the decimal expansion of a real number (see ibid §2). If he were alive today, I have little doubt he would have been an ultra-finitist -- not any constructivist! -- because, as it turns out, there is no empirical justification (even in principle) to accept inifinite induction. The very arguments he uses to reject LEM must also reject unbounded induction: it is not verified by nature.

(Here's what he says on induction:

> Here the principle of mathematical induction often furnishes the means of > carrying out such tests without individual consideration of every element > involved in the mapping or of every possible way in which the mapping can be > performed; consequently the test even for systems with a very large number > of elements can at times be performed relatively rapidly.

After the discovery of computational complexity he would have had no choice but to be an ultra-finitist.)

As to the notion of truth, I completely agree, but here Alan Turing came up with a completely different perspective. Whereas both Brouwer and Russel were looking for Truth in mathematics (and Hilbert, too, although he was content to Truth in the contentual "real propositions" and the finitist rules of inferene), Turing rejected that notion altogether. To him, mathematics was a means whose intrinsic truth is irrelevant. It is valuable inasmuch as it is useful, not because it is true (see [https://mdetlefsen.nd.edu/assets/201037/jf.turing.pdf](https://mdetlefsen.nd.edu/assets/201037/jf.turing.pdf)).

<comment><USER9> You are being a bit too quick to equate finitism and constructivism. Hilbert was a finitist, but not a constructivist, and Brouwer was a constructivist, but he was not a finitist.

Brouwer's analysis of the continuum depends heavily upon the notion of a "free choice sequence" (aka a lawless sequence). The idea is that a creating subject -- i.e., you or me -- is free to make an unbounded sequence of choices to produce a sequence. At any finite time, you can only have made a finite number of arbitrary choices, but if you wait long enough you can make any number of arbitrary choices. Because these choices are arbitrary, free choice sequences cannot be described as being generated by any finite rule.

This is a constructive process, if you imagine (for example) generating a lawless sequence by throwing dice or from the clicks of a Geiger counter. But it's not a finitist one, because there is no finite data from which a choice sequence can be computed. This let Brouwer retain the idea that a mathematician can only have considered a finite amount of information at any point, without having to make any identification of the real numbers with computable functions.

In terms of complexity, there's an interesting analogy between choice sequences and the question of whether randomization gives you extra power -- the Miller-Rabin primality test lends immense force to the intuition that RP is stronger than P, but we might be centuries from proving it.

Even if we set aside randomness, though, an ultra-finitist/complexity-aware- logic is something that basically every logician I've ever talked to has agreed should exist, except we basically don't know how to do it. It's something that pretty clearly demands more creative insight than technical grunt, and unfortunately imaginative leaps don't come on demand. :/

<comment><USER8> We need to separate Brouwer's construction of the choice sequences from his philosophical justification for them; in the transition between the two there were just things he couldn't have known. His entire conception of choice sequences was because the mathematician's mind is finite. He couldn't have based his choice sequences on computation because the notion didn't exist yet, but if it had, he wouldn't have needed "lawless sequences". There is just nothing that requires them either in his chosen axioms or in his philosophy -- their salient feature is that one cannot predict their behavior, something that, after Turing, _we_ know is true even for "lawful sequences" _but Brouwer didn 't_. I, therefore, do not think it is correct to say that he wasn't a finitist because he relied on randomness. As far as he knew, randomness was consistent with a finite mind, the finiteness is what mattered to him, and anyway, he cared about undecidability, not randomness, but didn't know the former can exist without the latter.

What _is_ essential to his philosophy is that the only justification for the axioms can come from nature by way of empiricism, and is therefore finite. If you accept Russel's, Brouwer's and Hilbert's belief that mathematics contains Truth, and if you then accept Brouwer's belief that the only source of truth is nature by way of empiricism, you have no choice today but to reject both LEM and induction. It is perfectly fine to work in constructive mathematics, and, in the Turingian sense it is of value, but it is no longer justified by Brouwer's philosophy of mathematical truth. Brouwer would have had to reject today's constructive mathematics on the same grounds he rejected classical mathematics: its axioms are unjustified by nature and empirical observation, even in principle. In fact, I don't think there is _any_ philosophy of mathematics that could distinguish between constructivism and classical mathematics on any reasonable philosophical grounds today.

I would say that Brouwer's philosophy is (with today's knowledge) constructivist and ultra-finitist. BTW, Brouwer was not opposed to formalism as much as he was to logicism, and he even tried to propose a way to reconcile the two ("Intuitionistic reflections on formalism", 1927).

<comment><USER9> In modern terms, you can identify sequences and automata: a sequence is a current state, plus a transition function giving you the next element of the sequence and the next state. However, if every function is tracked by a computable process, then the transition function must also tracked by a computable process, and so every infinite sequence must be generated by a computable process.

This identification is precisely what choice sequences are used to rule out. If a sequence is genuinely arbitrary, then you cannot describe it up front with a finite amount of data and a finite rule for updating that data. Instead, you have to imagine a mathematician adding a new axiom at each time step about the next element of a choice sequence, and requiring that any constructions they do works uniformly regardless of what axioms may be chosen in the future.

In this picture, the total amount of axiomatic data is actually going up over time, and this is actually important for the results Brouwer proved. In particular, without the axioms for choice sequences, you cannot derive the strong counterexamples, because you need classically-false axioms to prove classically-false theorems (like the continuity of all real-valued functions).

<comment><USER8> > This identification is precisely what choice sequences are used to rule out.

But you don't _need_ to rule them out -- Brouwer certainly didn't. He just wanted to rule out _decidable_ sequences. It's the undecidability that's important to his result, not arbitrariness, and that's perfectly compatible with automata. He just didn't know about computational undecidability and thought that undecidability requires lawlessness, but it doesn't. In any event, he didn't think randomness violates finitism. That only finite systems can be the source of axioms has been a constant refrain of his. I see that according to Wikipedia's definition of Finitism, he would be a "classical finitist."

> In particular, without the axioms for choice sequences, you cannot derive > the strong counterexamples, because you need classically-false axioms to > prove classically-false theorems (like the continuity of all real-valued > functions).

The continuity of all real-valued functions can be proven with just computable sequences because of undecidability; you just can't do it if computational undecidability hasn't been discovered yet. In fact, it doesn't even become quite "classically false", but can be "embedded" in classical mathematics by restricting the "all": all _computable_ real functions are continuous is a classical theorem. AFAIK, all constructive theorems can be embedded in classical mathematics by restricting them to computable entities. Do you have an example of any result that relies on uncomputable sequences?

<comment><USER10> > It's the undecidability that's important to his result, not arbitrariness

Undecidability _is_ arbitrariness - to say that, for example, the axiom of choice is independent of ZF is the same thing as saying that there is a arbitrary choice[0] between ZF+C and ZF+!C. Similarly, the sequence[1] G(PA),G(PA+G(PA)),G(PA+G(PA)+G(PA+G(PA))),... requires (at least) one additional arbitrary bit per item.

0: not asserting anything about what _makes_ that choice, though.

1: where G(X) is the Godel sentence, roughly "X cannot cannot prove G(X)"

<comment><USER8> What I meant was that Brouwer doesn't need lawless sequences; all the results are valid with lawful sequences only. He just didn't know that because he didn't know that lawful sequences can be undecidable. You can call it arbitrary, but it doesn't have to be random, it just needs to be unknowable, which is the case even if it's chosen by a computational rule. It is true that most of the sequences of the kind you presented are not computable, but I don't think any result of Brouwer's is affected.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> > Note that if a system is inconsistent then everything is provable, thus if a > system is consistent there must be a proposition which cannot be proved.

¬ ∀ (P Q : Prop), (P → Q) → (¬P → ¬Q)

</comment><comment><USER12> Along these lines, a book I've seen recommended here:

Computability: Turing, Gödel, Church, and Beyond. B. Jack Copeland, Carl J. Posy, Oron Shagrir (2013) MIT Press

Description:

In the 1930s a series of seminal works published by Alan Turing, Kurt Gödel, Alonzo Church, and others established the theoretical basis for computability. This work, advancing precise characterizations of effective, algorithmic computability, was the culmination of intensive investigations into the foundations of mathematics. In the decades since, the theory of computability has moved to the center of discussions in philosophy, computer science, and cognitive science. In this volume, distinguished computer scientists, mathematicians, logicians, and philosophers consider the conceptual foundations of computability in light of our modern understanding. Some chapters focus on the pioneering work by Turing, Gödel, and Church, including the Church-Turing thesis and Gödel's response to Church's and Turing's proposals. Other chapters cover more recent technical developments, including computability over the reals, Gödel's influence on mathematical logic and on recursion theory and the impact of work by Turing and Emil Post on our theoretical understanding of online and interactive computing; and others relate computability and complexity to issues in the philosophy of mind, the philosophy of science, and the philosophy of mathematics.

<comment><USER4> Using Orders on propositions, the construction of Gödel's proposition _I 'mUnprovable_ is blocked because the mapping Ψ↦⊬Ψ has no fixed point because ⊬Ψ has order one greater than the order of Ψ since Ψ is a propositional variable. Consequently, some other way had to be devised to prove inferential incompleteness without using Gödel's proposition _I 'mUnprovable_. A complication is that theorems of strongly-typed theories of the natural numbers and computation are not computationally enumerable because there are uncountable instances of the induction axiom in each theory. However, proof checking is computationally decidable :-) The complication can be overcome using special cases of induction axioms to prove inferential incompleteness of the theories. See the following:

[https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003)

</comment></comment><comment><USER13> >One way of describing the Incompleteness Theorems (1931) of the Austrian logician Kurt Gödel is to say that he proved, in the form of a mathematical theorem, that the possibility of a fully automated mathematics can never be realized

What Gödel apparently missed (although it's hard to tell without going over his writings carefully), is that _humans, by the same criterion, can 't "solve" mathematical problems_. This is essentially a re-statement of the halting problem (undecidability).

You can't expect to go to the best mathematician in the world (o.c. that's not a thing, but say for example Terry Tao), give him an arbitrary problem and expect the problem to be solved within a fixed time. Or even some arbitrary but finite time (even if he had infinite scratch paper). If he had an obligation to solve the problem (within an axiomatic basis), there could be problems that go unsolved. Any mathematician knows this -- there's no guarantee the Riemann hypothesis will be resolved -- it could be within a year, within a century, or never.

It's very attractive to think we have some kind of higher powers (that transcend ordinary matter, or computers, or w.e.), but we do not and mysticism is not necessary to explain our abilities.

<comment><USER14> Yeah I was confused by that and maybe the article could have clarified this in relation to the Church-Turing thesis.

</comment></comment><comment><USER15> It's an open question if it is decidable to show that P=NP problem is decidable :). We may live in a universe where undecidable problems exist and it may not ever be possible no show that they are undecidable. Which imho is kind of beautiful. Even if we live in a simulation it is so incomprehensible that it might as well be God to us.

</comment><comment><USER16> I always get a feeling articles like the OP (and there seem to be many) are pushing some kind of mysticism instead of clearly explaining...

Can anybody give an example of mathematics that mathematicians consider "true", but which is not provable in ZFC?

If no such mathematics exist, then mathematics is essentially just a game of symbol manipulation, right?

<comment><USER17> Sure. Most mathematicians think it's true that ZFC is consistent; but that can't be proved in ZFC.

 _mic drop /Halmos block_

<comment><USER4> However, the consistency of ZFC can be proved in strongly-typed higher-order theories that subsume ZFC.

<comment><USER16> What does that mean though?

Does it only mean that ZFC is consistent when subsumed within a strongly-typed higher order theory, or does it mean that ZFC by itself is consistent?

<comment><USER4> The strongly-typed higher-order theory _Ordinals_ is consistent because it has a unique up to isomorphism model by a unique isomorphism. Consequently, ZFC is consistent because it is a special case of the theory _Ordinals_.

</comment></comment></comment></comment></comment><comment><USER18> >One way of describing the Incompleteness Theorems (1931) of the Austrian logician Kurt Gödel is to say that he proved, in the form of a mathematical theorem, that the possibility of a fully automated mathematics can never be realized.

Which suggests the following solution : limit our endeavors to that part of mathematics that CAN be automatically proven (and drill down infinitely into details thereof). And stub off the rest with good-enough axioms (aka holy doctrine).

Crazytalk? Well it's basically how we as a culture handle pretty much everything, epistemologically (and ontologically) speaking.

It could be very efficient. It could be a dystopian nightmare.

</comment><comment><USER19> What would be a good starting point to learn more about the topics described in this article? I felt like I understood the gist, but a lot of things went over my head.

<comment><USER20> Douglas Hofstadter's "Gödel, Escher Bach" does a very slow gradual walk through Gödel's incompleteness theorem. If you can get into his writing style, it's a good way to really "get" the points.

<comment><USER19> Thanks for the recommendation! I actually just picked it up off a friend's bookshelf yesterday and it's next on my list of books to read.

I appreciate your response!

</comment></comment></comment><comment><USER21> [http://archive.md/iyvzm](http://archive.md/iyvzm)

</comment><comment><USER22> are there any practical impacts (direct or indirect) of these results?

<comment><USER3> The computer theory version of Godel's result is the halting problem, and that is applicable all over the place, in the same way that physical conservation laws imply a large variety of invention are impossible.

For example, it is impossible in general to understand what an English sentence says, because that sentence may describe the operation of an arbitrary program, and understanding an arbitrary program is undecidable.

Another example, it is impossible to detect all variants of malicious programs, because that requires understanding what all programs do, which requires identifying whether an arbitrary program halts or not.

Yet another example, optimal machine learning is impossible, since that is based on Solomonoff induction, based on Kolmogorov complexity, which is uncomputable due to the halting problem.

And another off the top of my head, it is impossible to create a general program creating program, such that you give it a well defined specification and it spits out a program that meets the requirements, if the requirements are satisfiable, since that requires solving the halting problem.

Finally, humans, while not optimally satisfying all the above tasks, do quite a decent job at these tasks, which is surprising if humans themselves were some sort of algorithm. So, this strongly suggests the human mind is doing some operation beyond computation, which in turn would imply that human intelligence level AI is impossible in theory, and thus impossible in practice. Furthermore, if the human mind is indeed doing something uncomputable, this has technological implications that human in the loop computation approaches are inherently more powerful than computation alone, a vastly under researched concept, although arguably the secret to the success of most AI/ML/datamining companies these days, such as Google, Facebook, Amazon, and Palantir. And the software industry in general is proof of this concept that humans are program generating processes performing much better than the halting problem would lead one to expect if humans were indeed mere computation.

Anyways, a whole bunch of impossibility implications, which have the practical application of protecting your wallet from comp. sci. snake oil salesmen, and the intriguing possibility 'beyond computation' technology.

<comment> pure-awesome > Finally, humans, while not optimally satisfying all the above tasks, do > quite a decent job at these tasks, which is surprising if humans themselves > were some sort of algorithm.

Whilst I agree with everything in your comment before this point, I don't agree with this.

There is a very big difference between _almost_ achieving something and _actually_ achieving it. For example, there exist algorithms which are able to determine whether a given program halts, for a large class of programs, or to give some probability that a program halts prior to some point, even if they are unable to solve the general halting problem. So you haven't really argued that humans are doing something computers can't do.

In addition, I take issue with your statement that humans "do quite a decent job at these tasks". On the face of it, I agree that yes, (when sufficiently motivated) (some) humans do indeed do a pretty good job of e.g. proving mathematical theorems and writing programs that halt when they should. Certainly better than the best computers we can build. But that "pretty good" is a _far_ cry from the optimality referenced in the theorems you've stated. And if you are using this "pretty good" to indicate that humans are better than any possible algorithm, that argument doesn't follow-through.

I think that human-level algorithms are in principle possible. They will have to incorporate a lot of probability and approximate results and the like, and likely will have something similar to "intuition" where the path from input to output is not clear, whether to human onlookers or to the algorithm itself (whatever that might mean). We already see hints of this today with our deep learning algorithms. Not to say that we are necessarily close to achieving this, or that we ever will, but on the other hand it might very well be just around the corner!

<comment><USER3> Sure, this observation is not a definitive proof, it is more along the evidential lines.

There is also a class of deciders that can decide for an infinitely large class, which cannot be decided computationally, yet is not complete. I'd say humans most likely fall in this class, since they far exceed anything we can do with the best algorithms we've dreamed up, yet also cannot solve everything.

Of course, you can always say there is a yet undiscovered algorithm to fill the gap between state of the art and human performance, but at some point that hypothesis is less well supported by the evidence than the uncomputable mind hypothesis, and I'd say we are well past that point.

<comment> pure-awesome Humans exceed our current computers in the same way that a large asteroid impact exceeds our current nuclear weaponry. It's a matter of scale, not of kind.

If we track the capability of computation machines from binary adders through old-school chess AI, expert systems and robotics, to the neural networks playing Go, chess, Starcraft, DOTA, we see an ever expanding sphere of ability and influence - often exceeding what humans predicted was impossible for computers.

> Of course, you can always say there is a yet undiscovered algorithm to fill > the gap between state of the art and human performance

This implies a kind of asymptotic approach towards human intelligence, that it's something we keep trying to approach but will never reach.

But beyond "filling the gap" I believe computers have the potential to shoot past us in ability. And if they do, I think it's going to be a pretty shocking experience, because I think the rate of increase in intelligence at that point is going to be bigger than we expect - there's no reason to believe the exact level of intelligence is a special border, objectively speaking.

To claim that the evidence so far supports the uncomputable mind hypothesis seems to me like if we had managed to build tiny motors which had been getting bigger and better each year, and then claiming that we would never be able to beat an elephant in strength because no motor up to that point had yet been able to do so. Yes, our metaphorical motors are still tiny, and yes, it takes other extra pieces of engineering beyond motors to actually push down a tree, and indeed it's possible we will perhaps never build a big enough machine. But to take each larger motor as somehow being evidence AGAINST us ever getting to that point is a strange viewpoint.

<comment><USER3> I don't see why you believe this. From my perspective, all the recent gains in AI abilities is purely due to faster hardware. But, due to the combinatorics of search spaces, exponential speed increase only gets you linear AI improvements. So, we'll rapidly hit peak AI in the near future, falling way short of even emulating human abilities.

As it is, compare the amount of processing, space and energy humans have to expend to perform equivalent tasks to computers, and there is no comparison. Computers are extraordinary orders of magnitude inferior to human performance. The only reason there is the appearance of parity is because we are not looking at the back end of what it takes computers to accomplish these tasks.

It is like we flipped a coin to create the works of Shakespeare, and waited the many eons necessary for just the right sequence to occur. We then say a coin is just as capable as Shakespeare, but that's only because we've ignored how much effort it took to flip the coin vs how much effort it took Shakespeare.

So, I'm not arguing our motors will not become bigger. I'm arguing that as our motors become bigger, the returns are diminishing exponentially, much more rapidly than can get us to true human parity.</comment></comment></comment></comment></comment></comment>


Chinese Say They're Building 'Impossible' Space Drive, the EmDrive ('Relativity Drive') - <AUTHOR> http://blog.wired.com/defense/2008/09/chinese-buildin.html

<comment><USER2> _"According to Roger Shawyer, the British scientist who developed the concept, the drive converts electrical energy into thrust via microwaves, without violating any laws of physics."_

Wouldn't it be much more interesting if they actually _did_ violate the laws of physics?

</comment><comment><USER3> Obviously, this is a crazy idea. But, with Feynman, I have to ask: "Is it crazy enough to be worth taking seriously?". I wish I had enough physics to answer that question.

</comment><comment><USER4> interesting. in essence what we have here is a variation on the photon drive where instead of being bounced off an open reflector to generate momentum you have a closed cone. at first glance this would seem absurd since the forces acting on the two ends of the cone should cancel each other out. where it gets interesting is that this guy claims that the math shows that the photons are operating in a special frame of reference: essentially even though the photons are enclosed they behave as if they were not. thus momentum is imparted in one direction and all you have to do is keep pumping microwaves into the cone. being able to use electricity instead of some sort of stored propellant would be a huge step towards sustainable space flight. here's hoping it works.

and even if it doesn't, science needs weirdos who are willing to work on edge cases. tesla's professor told him that the AC motor was a perpetual motion device and thus impossible.

<comment><USER5> _science needs weirdos who are willing to work on edge cases_

Yes, but there's more than one kind of edge.

The edge of scientific knowledge is worth paying people to explore.

The edge of your own knowledge is worth exploring on your own.

The edge of your funding agent's credulity is very profitable to explore, but such work doesn't help science at all.

</comment></comment><comment><USER6> He ignores the forces on the sides of the tapered wave-guide, calculating forces only for the end caps[1]. If he was to include the forces on the sides, I'm quite sure he would find that F_g1 = F_g2 + F_sides exactly.

[1] page 2, <http://emdrive.com/theorypaper9-4.pdf>

<comment><USER4> He mentions that axial forces (the momentum imparted by deflection off the tapered sides of the cone) are taken into account, it might still be wrong but he didn't just ignore it. keep in mind that the force being produced here is tiny: 85 milli newtons, and it obviously needs a power source to run. assuming that the math doesn't add up to a 100% or greater efficiency in the conversion from electrical energy to momentum i see no reason why this is impossible.

If the drive works as claimed i wonder what the efficiency is in the transformation from electrical energy to momentum.

<comment><USER6> > He mentions that axial forces are taken into account

If he does, he's not included it in his theory paper. Take a look, there is no mention of "axial forces" or "deflection" in the paper.

In equation 7, he calculates the thrust T using only the difference in propagation velocity at each plate, but makes no mention of _how_ the propagation velocity changes. If he did, it would be obvious that you have to account for radiation pressure on all sides on the tube, not just sides which happen to be perpendicular to the tube's axis.

> efficiency in the conversion from electrical energy to momentum

The efficiency will be about 0%, so no need to worry.

<comment><USER4> you're right. in the paper he is simply doing F2-F1 to give the thrust without any mention of the surface area of the cone walls. he mentions constructing the cone to give a "reflection free transmission" which is impossible.

i guess junk science is right. oh well.

from page 6: Note that the reflection-free interface, with matched wave impedances , will ensure no forces are produced at the interface. <\-- that doesn't sound possible.

</comment></comment></comment></comment><comment><USER7> China doesn't seem to have very good science filters. They're also funding one of the most hopeless AI projects I know of.

<comment><USER8> which one?

<comment><USER9> Maybe he's thinking of Japan's Fifth Generation Computer project?

<http://en.wikipedia.org/wiki/Fifth_generation_computer>

</comment></comment></comment><comment><USER10> The Chinese also said their female Olympic gymnasts were 16 years old. I think it's a good policy to take what the Chinese say with a grain of salt.

</comment><comment><USER11> Sounds like a hoax.

</comment><comment><USER12> I'll be more interested once they start building a possible one.

<comment><USER13> How about just a plain improbability drive?

</comment></comment><comment><USER13> I have no doubt that one day one of these crazy web stories will be true -- somebody will invent a field propulsion system.

Odds are this ain't it, though.</comment>


Learn to program in 21 days (comic) - <AUTHOR> http://abstrusegoose.com/249 <comment><USER2> Please link to the original website (abstruse goose): <http://abstrusegoose.com/249>

</comment><comment><USER3> I wouldn't mind those kinds of book titles so much if they just said "Learn basic [language] syntax in [n] [units of time]". Not as catchy I guess, though.

<comment><USER4> Speaking as someone who has had to maintain code written by someone who "learned" from these books, I completely agree. What was there was certainly C++ in a purely linguistic sense, but as code it was complete gibberish.

<comment><USER5> I am maintaining "code" written by person who was given this kind of book and told to build ERP. (This person don't have any previous knowledge on programming, mathematics or even computers)

10 years later it is worst than your nightmares.

</comment></comment></comment><comment><USER6> Day 21.001: Fade out of existence because you forgot -- despite your years of physics training -- that killing your younger self is a time paradox.

<comment><USER2> Well, there would be several schools in terms of time travel (mutable/immutable timelines).

</comment></comment><comment><USER7> Someone forgot "Perfect doppleganger technology, then go back in time to kill Stroustrup, replace him, and write C++ in a way that you actually can learn it in 21 days. Also, obsolete Sun Microsystems."

</comment><comment><USER8> I think everyone is taking the title a little too literally. The "24 hours" gimmick is just a way of constraining the information into discrete concepts. Once you know 24 facets of a language, you are certainly qualified to start testing out the language. Is there anyone who really thinks that by reading any number of books on a topic you could consider yourself an expert?

<comment><USER9> " Is there anyone who really thinks that by reading any number of books on a topic you could consider yourself an expert?"

Depends on what exactly "reading" encompasses. If you can _work through_ a _good_ book (say SICP) doing all the exercises etc and writing a lot of code, I'd be very surprised if you don't "level up" very fast. If you've worked completely through "C Interfaces and Implementations" by David Hanson, you should be a pretty good C programmer at the end.

Working through a _series of_ great books will amplify this effect.

so yes you can achieve a lot through proper use of books but 21 days, no way.

</comment></comment><comment><USER10> It's doubly funny when you look at the difference between "use knowledge to make an age-reversing _potion_ " which follows with "use knowledge to build flux capacitor"

</comment><comment><USER11> If you go back in time and have sex with yourself, does that count as homosexuality, or just masturbation?</comment>


Show HN: Speaketto, an Online Marketplace for Conversations - <AUTHOR> https://www.speaketto.com <comment><AUTHOR> Speaketto is an online marketplace for conversations, where language learners can practice speaking any language with a language helper that matches their needs.</comment>


It's official: developers get better with age. And scarcer.  - <AUTHOR> http://coding-and-more.blogspot.com/2011/06/its-official-developers-get-better-with.html

<comment><USER2> Since I don't see this specifically addressed in the text: I suspect this is a classic case of survivorship bias. The same way the stock market looks better and better the further back you go, because you aren't tracking the stocks of companies that are no longer in business, developers probably look better and better the further they are into their careers, since all the ones who've fallen by the wayside probably were the weaker developers who found something better to do with their time.

As a somewhat older developer, I find this a surprisingly difficult question to answer honestly. Comparing myself to myself from 10 years ago, I sincerely think I'm more effective, but self-delusion may play a part in that. I've probably lost some of my "step", in terms of raw capacity to memorize and compute mentally, and I have more commitments outside of the world of software, which dilutes my efforts further. Then again, the strategic ideas I have are more dependably correct, and I spend less time chasing down dead ends, either because I've been down them before or had the good luck of witnessing them second- or third-hand.

I've gotten a chance to see a world-class developer very closely between the ages of 36 and 45. He started this period as, very easily, the greatest engineer I'd ever even heard stories of, and I'm pretty sure he got better over that decade. It can be done.

<comment><USER3> I don't feel any smarter than I were on my 20's. OTOH, software has gotten much more complex. Mastering the Apple II ROM routines is one thing, but understanding how every piece in a complex web application (app server, rdbms, non-relational storage, cache) interact is much harder. After wrapping my brain around some concepts, it feels very thin. We rely on Google and the web to supplement our memories for things that 25 years ago depended on books and synaptic pathways.

I'm quite sure I am much more effective today than I were 25 years ago, but a lot has to do with cognitive prosthetics.

<comment><USER4> I find web development less enjoyable than 5 or 10 years ago because of the increasing size and complexity of the stack.

At least us old fogies have had the last 15 years to learn web development. How the hell do young programmers learn such a big stack in a few years? I'm guessing half using youthful energy and the other half skipped in blissful ignorance?! :)

<comment><USER5> That's the point - you don't learn the whole stack, you let your framework manage it.

<comment><USER6> This is one of my problems with younger developers. They slap framework code together rather than actually figuring out what's going on underneath.

It's one of the reasons I still use PHP. It's the perfect balance between framework and coding.

</comment></comment></comment></comment></comment><comment><USER7> Aaargh! The data doesn't say this, all the data says is "Older StackOverflow users have disproportionately high SO reputation."

An alternate explanation is that for some reason older developers are more likely to be addicted to Stack Overflow.

A big problem here is the unproven assertion that high SO reputation means you are a "better developer." Does it really? (After all, with few exceptions, the more active you are on SO, the higher your reputation, _period_ , regardless of your answer quality, partly because downvoting is strongly disincentivized. And the article itself notes that older programmers don't receive significantly more upvotes per post!) Until that's shown, the article's conclusion is highly suspect.

Frankly, I'm embarrassed so few people seem to be calling out the terrible reasoning behind this post. It may well be that older programmers are "better," but what we have here is nothing more than a colossal failure to understand science, reasoning, and evidence.

<comment><USER8> Yeah, my conclusion from the data was "senior developers know more things and have more time on their hands to tell others about those things", which is exactly what you'd expect. The more senior you get, the more your role is as guide and mentor than immediate implementor.

<comment> brown9-2 One of alan's points is that it is incorrect to assign behaviors of "older Stackoverflow users" to the universe of "older developers".

The population of "older Stackoverflow users" is not randomly drawn from the population of "older developers", and nothing is put forward to claim that the former is representative of the latter, so you cannot make this assumption.

<comment><USER9> Exactly. The graph showing that older coders' answers are not significantly better than those of younger coders is a case in point: maybe the good older coders are too busy actually coding to spend time answering questions on StackOverflow.

</comment></comment></comment></comment><comment><USER10> I'm 45 with a little short of 30 years of programming experience. Our team at HP (I'm not a manager) has a few programmers that are significantly older and a few that are very young. From my observation, what's different about young vs. old programmers is not related to the speed at which we pick up new technologies (we all love to tinker with the latest stuff) but at the general approach to problem solving.

Older engineers tend to compare new problems to experiences from the past. The tools at our disposal have become much better but the fundamental mechanisms haven't changed that much so it's easier to identify whether there's a real benefit to using a new tool or if it's better to stick with what you have.

As an experienced developer it's a little easier to avoid sinking effort into novel but misguided technologies.

As a young developer it's a little easier to be open-minded about promising technologies.

But don't pay any attention to me - my SO rep is less than 30% of the average for my age bracket...

</comment><comment><USER11> Tell HN:

On a barely related subject, tomorrow is my 49th birthday.

<comment><USER12> So that's why you're such a good blogger!

Thanks for blogging and contributing on HN, you've really improved my understanding of software, and how to think about software.

Happy Birthday.

<comment><USER13> Hmm. I have upvoted you automatically: in the past it did not just mean I think your argument is interesting, but also (in cases like this one) that I share the sentiment and do not want to litter HN with "+1" comments. Of course, now that none except you can see your score, this is no longer working like that.

Happy birthday to raganwald!

</comment></comment></comment><comment><USER14> I don't disagree with the conclusion: people who aren't as dedicated to or good at programming transition to people or product/program/project management[1]; the remaining folk receive additional experience which allows them to capitalize further on their passion and talent.

However, this isn't exactly proven by the data: what Stackoverflow shows is that older developers are better at talking intelligently about programming. That's extremely useful (and helps career wise), but it isn't the same thing as being a better developer. Sometimes it correlates (the best programmers I've known have also participated in organizations like IETF, written RFCs and have also thoroughly documented their work), but it isn't a total ordering (I know plenty of programmers who are better than I, but who don't participate in any public forums).

On the other hand, I've yet to find a successful programming language made by someone before their thirties. Contrast it, on the other hand, with some of the most ground changing academic work in Computer Science and Mathematics being done by people in their twenties.

[1] There's nothing wrong with that: Google's APM program particularly is a great example of "engineers who don't want to code" being extremely useful. See also "The Russian Lit Major" by rands: [http://www.randsinrepose.com/archives/2006/09/06/russian_his...](http://www.randsinrepose.com/archives/2006/09/06/russian_history.html)

<comment><USER15> Historically, it would seem like 30 is almost a "sweet spot" for language creation.

* Dennis Ritchie was 27 or 28 in 1969 when C got going.

* McCarthy was about 30 in 1958 for Lisp.

* Sussman was 28 and Steele was 21 in 1975 for Scheme.

* Alan Kay made Smalltalk between 28 and 31.

And while it used to be true that lots of game-changing mathematics was done early, I don't see much of that lately. A huge amount is done by junior faculty and postdocs, but that's usually late 20s and 30s.

</comment></comment><comment><USER16> What this really shows is that developers get better at answering technical questions with age. There is probably _some_ correlation to development skill, but the data doesn't demonstrate that. I'd expect developers to know more things as they get older, and I wouldn't be surprised if they got better at answering questions. Not sure that makes them better at the development part.

<comment><USER17> I think that this is showing a correlation between those programmers that enjoy programming and want to share their knowledge with others, and those programmers that stick with it for more than a decade.

I bet that if you could separate out the younger developers who will still be developing in 10-20 years, that their rep on SO is similar to that of older developers. Those developers that'll wash out in the next 5 years are dragging down the participation numbers of their peers.

So it isn't the age that's important, it's the personality type which is correlated to those people that'll stick with development.

</comment></comment><comment><USER18> I used to think younger developers were better, but with the experience of age, I now realize that older developers are better.

Honestly, though, I think programming is a "young man's game", partly because you are sharper, have more energy etc when young; but mostly because when everything is reinvented each decade, you are better off starting fresh, without being aware of other choices.

The exception is for higher-level tasks, such as marketing, managing people, strategic business decisions, and code architecture. Also, I would think, language/library/API/framework design. I hesitate a little, because many of these are based on the needs of current programmers, which the front-line troops know better because they are doing it (they are the users). However, for deeper insights, age has the benefit of seeing deeper patterns over decades, and over generations of usage. Most language designers seem to be older (but is that just because their languages are now old?)

</comment><comment><USER19> Age correlates with experience.

If you've been something longer, you've had time to learn what works and what doesn't, and why.

Thus, you can do a better job at guiding people who are newer to the material.

<comment><USER20> But if you started programming at 50... that's different than having done it for the last 30 years.

<comment><USER21> That's pretty rare though, I think _most_ programmers in their fifties have been doing it for many years.

</comment></comment></comment><comment><USER22> Honest question: what happens to developers after they are no longer "Developers"?

As a 29-year-old I'm kind of freaked out by the fact that I'm on the older part of that distribution.

<comment><USER23> I do not have stats to base this claim, but when I worked at my last job, I heard from an employee in another department that the normal lifespan for a software developer was 7 years, after which they have some sort of career change, be it management or logging.

</comment></comment><comment><USER24> Maybe with coding, it's either up or out. Older developers who have better skills most likely enjoy what they are doing and are somewhat good at it. If they weren't, they would have left the profession, maybe to become project managers or some related position. It's not like you're always forced out of your position, it's just that when you look down the road, you can see that if you're not a great coder, it may be best to find something you're better at. A 25 year old coder may still be figuring out if that line of work is sustainable over the course of a career.

</comment><comment><USER25> Wow, the chart only goes up to 49 years old?

For me, that is about 4 programming languages ago :-)

<comment><USER26> He said he only took age cohorts for which he had 100 or more data points.

</comment></comment><comment><USER27> A quote from this really stuck out for me:

"So, senior coders earn their higher reputation by providing more answers, not by having answers of (significantly) higher quality."

A lot of people here are focused on "being smarter" or "doing a better job" or "higher quality"

Excluding all of the self-taught developers, and limiting ourselves only to people who follow the standard "get a 4-year college degree then go out in the real world and work" crowd, as that's pretty sizable. Make extrapolations as necessary.

Remember your first year (or two?) of development? Looking back, you were probably way in over your head, had mentors looking after you, making tons of mistakes etc.

Fast forward 5 years. Can you write code faster? Probably not. Can you write better code? Sometimes. It's all about experiences and learning from them. When you take a new job, or a new project, or a new anything, you call upon past experiences to guide the efforts of this process. It might be something as vague as "I am going to write tests first because I found it helped me earlier", or (ignoring TDD), "I'm not going to write this function like this, because I know the code will be hard to test when I get around to writing a test for it later"

You learn this all from experience. Senior people who have been in the field longer have more experience. They aren't "better" in the sense that they are smarter or have more intelligence, they just know MORE because they've been exposed to more.

It's also why so many people (especially in hacker news) have been successful without degrees. It's not a degree that matters it's EXPERIENCE.

It might be a fine line differentiating between smartness gained from pure intelligence and "smartness" gained via experience, but I think it's an important distinction, and one that I think this post highlights well.

</comment><comment><USER28> Hardly seems like they get better with age, just more active in educating other developers. The quality of posts doesn't look related to age at all. As far as I can tell, that should be the parameter to measure if you are going to make any sort of induction about the quality of a dev from their SO profile.

And obviously, the fact that this only takes data from SO means whatever the conclusions, they only hold true for the kind of people that post there.

<comment><USER29> The main question, if you really were to judge something like quality, is _why_ older devs answer more questions.

Is it your assumption that they are just more invested in educating others, or is it e.g. because they have a broader range of experience and can answer more/more difficult questions.

As it is, this data set is merely an interesting conversation starter. I hope somebody takes it and does some research on it, because it sure could be interesting

<comment><USER30> The cynic view: they may have more time on their hands to was^C^C^Cspend on StackOverflow.

<comment><USER29> Even if I subscribed to the cynical viewpoint - how come they _do_ have that time? The snooty old dev in me counters the cynic with "Because we get stuff _done_ " ;)

So, still, lots of room for a more detailed look.

Edit: The reply is of course tongue-in-check. The second reply to the GP seems to provide a better explanation.

</comment></comment></comment></comment><comment><USER31> Is the decrease in number of developers due to real scarcity or due to fewer people that actively using Stack Overflow?

<comment><USER32> I think it's real scarcity. I'm 41 and am always one of the oldest in any group of devs (except for that Usenix event I attended :-).

Most people get into their career in their twenties. For computers it's often even younger. But it seems relatively rare for someone to pick up programming in their 30s or older.

If you're 40+ today, your twenties were ending around the time that the "tech boom" was beginning. But there just wasn't as much information and inspiration around for getting into software development. Even through the mid-90s a college degree and programming skills was no sure ticket to cushy employment.

<comment><USER33> Sometimes it's good to be a late bloomer.

<comment><USER26> Or just so obsessed that you stayed in programming even when it wasn't obviously a good idea. Come to think of it, it's still not obviously a good idea.

</comment></comment></comment></comment><comment><USER34> I think there might also be another selection bias here, in that StackOverflow might be a bit self-selecting for developers who know their stuff.

It's hard to say what this says about developers as a whole, including the ones not on SO, which I assume is a large number.

An alternative hypothesis might be this: Good developers get better over time, whatever that means.

I would suspect that people who form bad habits early on don't enjoy the same benefits of experience as those who built on solid foundations.

</comment><comment><USER35> Interesting hypothesis, but the faulty data renders the results presented useless. Namely, only 53% of SO users enter their age. Therefore the data may be wildly biased towards people who are willing to enter their age in an online profile.

In addition this only represents SO programmers, which while a great bunch, is hardly representative of all programmers.

</comment><comment><USER36> This analysis is completely wrong because the bell shaped curve is not measuring number of developers. It is measuring number of SO users. There are SO users that are not developers, and a lot of developers that are not SO users, so there is no valid conclusion that can be taken from these numbers about the general population of developers.

<comment><USER37> The bell-shaped curve gives me more confidence in the result, not less. It shows that Stack Overflow has enough developers that the graph isn't choppy.

<comment><USER36> The bell curve is a result of the distribution for any population: developers, guitar players, sci-fi readers, etc. In this case, the curve happens to represent SO readers.

<comment><USER37> The bell curve can be choppy when you've got too little data or bad data.

<comment><USER36> You're just looking at the shape of the bell curve. It tells you that it represents a population, but it doesn't tell you _what_ population it actually is. That bell curve could be for the age of people owning cats, for example. There is no evidence that SO users is a good sample of the developers population, in fact it makes sense that it is skewed towards young people that have lots of time to search and answer programming questions on the web.

<comment><USER37> Stack Overflow is geared towards developers and doesn't have anything I can see to attract a particular kind of developer, except the curious kind. I can't think of a place to get a better sampling of developers right off hand. Certainly, while Hacker News is popular among developers, it would be a less accurate sampling of developers than Stack Overflow, because people here tend to be attracted to startups.

I disagree with what you said in your first post, that it is _completely wrong_ , and that _no valid conclusion that can be taken from these numbers_. It's not perfect but it's far from being a terrible sample. It's a general- interest developer site rather than a specific-interest one. There are all types of developers. In a reverse-sorted list of popular recent tags, there are c#, javascript, php, java, jquery, .net, and android. Also, developers didn't choose to be a part of this graph; they merely got put into the survey result because they had Stack Overflow accounts. If it had been a survey that was announced on twitter it would be biased towards people who want to take surveys. This would be a worse bias IMO than people who want to ask and answer technical questions.

I wouldn't take issue if you had said it was problematic, but instead you went straight to a one-sided conclusion.

<comment> brown9-2 What about developers that don't spend much time online? Or that don't find much personal joy in answering the questions of strangers?

Just because Stack Overflow might be one of the best places to get a sampling online doesn't mean it is actually a correct sampling of the population of software developers.

<comment><USER37> Those are good points and I agree that there are numerous reasons why it isn't a correct sample. What I'm trying to say is that it's hard to get a correct sample for developers and that if someone is curious about the subject matter it's worth keeping this data until some clearly superior data comes along. There are plenty of datasets that are worse than this, either by having fewer data points or by being even more biased.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> Is there any other career where this would not be accepted as a given?

<comment><USER39> Teaching, from grade school through college professors.

<comment><USER40> Why would you say that? Teachers have an incredibly high attrition rate. Barely half of the new teacher classes make it 5 years.

The vast majority of the highly-regarded teachers I know are ones who have been doing it for 25 years or more.

<comment><USER39> The original topic was: "It's official: developers get better with age. And scarcer."

I was answering the posted question "Is there any other career where this would not be accepted as a given?".

So my post was that for teachers it is not accepted as given that they get better and scarcer with age. I did not make a statement whether that was true or not, just that it was not accepted as a given. In support of my view I would offer the numerous recent news stories calling for the end of last- hired, first-fired rule when laying off public school teachers.

<comment><USER40> I see your point, but I'm not quite sure that the two things go hand in hand.

If the vast majority of developers were publically financed and had LIFO laws, I'd imagine that there'd be calls to end that practice as well. In both cases, though, I'd argue it's outliers that are the source of the consternation.

I think most education reform advocates would agree teachers get better as they gain experience.

</comment></comment></comment></comment></comment><comment><USER39> The title s/b "Stackoverflow developers get better with age. And scarcer."

Stackoverflow is not representative of the overall developer population. As an example of an alternate view compare the relative number of items tagged on SO with C#, Java, and PHP. Then compare that to the number of listings of those tags on Dice.

<comment><USER39> So why the downvote? If you disagree with what I wrote then offer a rebuttal. Simply downvoting is churlish.

</comment></comment><comment><USER41> There's one huge hole in the analysis: the dataset.

The older someone is, the less chance they'll spend time on an internet community site, especially at work, which is when a lot of people access stackoverflow.

Old dudes work while they're at work, because they learned their work ethic in pre-internet times.

</comment><comment><USER42> The myth that engineers lose their game when they get older always seemed a little off to me. It usually gets clumped in with all the software jobs are going to go to China. I have met a lot of very bad developers that were older as well as very good ones. The same goes for young developers.

</comment><comment><USER43> _"On the graph we can see a textbook example of a bell distribution curve."_

Is this an actual bell curve? It's not symmetrical. (<http://en.wikipedia.org/wiki/Normal_distribution>)

<comment><USER44> It's hard for anything dealing with age to be a true symmetrical bell curve - it usually winds up being cut short by old age & death, or foreshortened by, well, not existing. Notice that the ages start at 16. You'd have to be pretty precocious to give high quality answers at age 10 or 5.

<comment><USER45> Not hard, impossible. Bell curves go to infinity.

Edit: Shouldn't have said that. Everyone knows basic stats here and I was being pedantic.

<comment><USER44> Yeah, it is literally impossible for a real bell curve to exist, but if you want to be pedantic, that's also because people are clumpy. The bell curve might say there ought to be 0.00000067 excellent answerers at age 12, say, but reality insists on there being 0 or 1 excellent answerers aged 12.

Whenever we look at real data, we acknowledge that it's a discretized approximation to a bell curve and not a real (continuous) one; the point was that on top of the discrete approximation, we have the additional problem of anthropic biases - people not existing or dying at either end.

</comment></comment></comment></comment><comment><USER46> Seeing that 70% decline in number of developers (on SO) from age 30 to age 40 and assuming they are still working, what do the older "has-been" developers do now and what titles do they have? Perhaps they have never heard of SO? Or they have stopped needing and/or using SO? Statistics based on educational website usage seem to always skew younger.

Analogously, if I measured academic skills and availability by time spent in libraries and time spent teaching, I'm sure we'd see a similar peak in 20's because grad students spend so much time doing both these things and productive professors need this less.

</comment><comment><USER47> One could also find another, not so positive trend in the article:

The older the developer, the less curious they are <= the less questions they have.

Of course you could say it's because the older developers are more experienced. But would that quality per se quell the thirst for new knowledge?

Just thinking aloud...

<comment><USER48> Alternatively, as you get better and deal with complex issues and have more sophisticated thoughts, you realize that SO can't answer the majority of your problems.

That's what I've learned about SO: it's fine for popcorn questions, but for the in-depth knowledge and discussions... _meh_.

<comment><USER47> That's a very fair point. Overall the deeper answers are probably more in the books or at conferences, not in blogs and online forums.

</comment></comment></comment><comment><USER49> I hope it doesn't mean that older developers are more likely to be unemployed and therefore have more time to waste on SO.

</comment><comment><USER50> Number of developers by age is likely inversely proportional to the growth in the industry. I'd also say people get into development at a later date in their lives - late 20s - because they started doing something else before making the jump - marketers, engineers, painters, physicists.

</comment><comment><USER51> Older people have, on average, been using stackoverflow for longer. SO rep scales roughly linearly with time spent contributing.

This probably isn't enough to explain the entire effect shown in the graph, but in 10 years (if people still use SO), it would be.

</comment><comment><USER52> I'm a little surprised to see that they provide more answers, but that they aren't of better quality. I would have expected experience to show more.

Of course, we only know they are older, not that they have more years of experience.

<comment><USER53> I think its one of those things where the real issue is if you have an answer at all. Of those ppl that have answers the quality of answers, I'd expect to be similar (across a population).

</comment></comment><comment><USER54> I wonder that they didn't do the correlation of length of time on SO (i.e., since join date) vs. reputation. Did the older developers join SO earlier, on average? How many rep points per day did older vs. younger devs accumulate?

</comment><comment><USER55> A minor nit, I know, but a bell curve is symmetrical. So the graph shows some sort of fat-tailed distribution, and we cannot "see a textbook example of a bell distribution curve".

<comment><USER56> Another minor nit:

You can still do a fit to a bell curve and find a chi-squared value. If your chi-squared is horrible, obviously you should be considering a different probability density function as your model is incorrect, but if it's decent enough you can omit the features and call it a "bell curve"

That being said, I could see this as a composition of two gaussian bell curves with the means correlating to the ages of people in college and their early/mid career (let's say 23 and 28 respectively)

</comment></comment><comment><USER26> How did this post title come from that article? If anything, we old fogies are just more prolix - but not necessarily better. (Judging from his statistics, anyway.)

</comment><comment><USER57> What if there's a filtering effect where lower-quality developers are less likely to stick with the profession past age 27?

</comment><comment><USER58> My guess is that the older developers have more time to comment and follow up. Plenty of times I have looked for solutions on stackoverflow, but have been too busy to post responses because of looming deadlines. This is like saying my grandparents would make for better farmers because they spend their whole day on Farmville.

<comment><USER59> I don't think a 45-year-old developer has inherently more free time than a 25-year-old. Given that a 45-year-old is more likely to have a family than a 25-year-old, I'd expect them to have less free time.

<comment><USER58> While this is true, you also don't see many 45-year-olds doing 60 and 70 hour work weeks.

<comment><USER59> Yes, but presumably they aren't spending those extra 20-30 hours writing StackOverflow answers.

</comment></comment></comment></comment><comment><USER60> What's up with the 48 year olds?

<comment><USER31> There are 148 of them, I'd wager there are a couple with super-high stats who throw off the average.

<comment><USER61> Using a median instead of a mean might help w/ this.

<comment> brown9-2 Yes - median is a far better method to use in a situation like this, especially when what is being measured (reputation) has a bounded minimum and an unbounded maximum, and double especially when the sample size in each age bucket is relatively small.

</comment></comment></comment></comment><comment><USER62> It's official: developers spend more time on stack overflow with age.

</comment><comment><USER63> '63 was a good year!

</comment><comment><USER64> Maybe it's because great developers end up in management positions... each day I write less and less code...

</comment><comment><USER65> By looking at the Reputation by Age graph it looks more like there are just a few really good older developers. The rest probably are so out of touch they do not participate in developer communities such as Stack Overflow.

In my experience it has been that older developers hold on to old coding habits that are today considered dangerous and are reluctant to change that.

<comment><USER66> _The rest probably are so out of touch they do not participate in developer communities such as Stack Overflow._

If you're curious about the down-votes, it may be because the above quote is an example of the particular kind of bigotry commonly referred to as "ageism". For future reference, if you are ever in a management position, that kind of thing is actionable in a work environment. You could get your backside sued off, is what I mean, if you are found to have used that in a hiring decision, for example.

<comment><USER32> I'm old enough to feel like employers may sometimes find younger and cheaper people to do dumb stuff faster.

What you say about the HR liability potential agrees with what I've heard from HR people, but never seen it be a factor in reality. In practice I can't imagine suing over a development gig. I can think of a million bad reasons people might not hire/let go a good developer (e.g. questions about manhole covers) but the "he's a curmudgeon who's reluctant to slap stuff together quickly" argument seems halfway legitimate.

So I say, bring it on, let's have an open discussion about who's smart, who's fast, who's wise, and when it even matters.

<comment><USER65> I agree with you. Experienced developers with skills are key for higher level functions such as architecture and system planning due simply to the "been- there" factor. My statement above was geared toward the "curmudgen".

</comment></comment></comment></comment><comment><USER67> What this post shows me is that older developers are less willing to ask questions, less willing to admit when they don't know something, less willing to do anything to fix it.

My personal experience is that older developers just don't get it. They haven't kept up with the exponential increases in productivity that we have had in the last 5 years. Things that used to take 2 days 10 years ago can be done in 2 minutes now, but they are still used to thinking that they did it quickly if they finish it in 2 days, so that's how long it takes them to do it.

Also my personal experience is that older developers can't handle the asynchronous nature of modern communications very well. They always want to work on only one thing at a time and get confused/ much slower if they have to work on multiple things, whereas younger developers will happily be able to switch in between tasks while waiting for the previous task to finish compiling/running without problems.

<comment><USER68> _They always want to work on only one thing at a time and get confused/ much slower if they have to work on multiple things_

This is the case with everyone. Multitasking negatively affects overall performance. There are many studies that confirm that. If some developers avoid it, maybe it means they are better at evaluating their own productivity?

<comment><USER67> So how old are you? Do you have any coworkers below 25? How well do they do with multitasking? Better than you?

Twitter, text messages and facebook have trained our minds to work differently. Have you been keeping up?

<comment><USER44> > Twitter, text messages and facebook have trained our minds to work > differently. Have you been keeping up?

Have _you_?

> In a much-cited 2009 paper* in Proceedings of the National Academy of > Sciences, for example, Stanford's Eyal Ophir, Clifford Nass, and Anthony D. > Wagner show that heavy media multitaskers demonstrate significantly less > cognitive control than light multitaskers. The heavy multitaskers "have > greater difficulty filtering out irrelevant stimuli from their environment" > and are also less able to suppress irrelevant memories from intruding on > their work. The heavy multitaskers were actually less efficient at switching > between tasks - in other words, they were worse at multitasking.

* [http://memorylab.stanford.edu/Publications/papers/OPH_PNAS09...](http://memorylab.stanford.edu/Publications/papers/OPH_PNAS09.pdf)

<comment><USER67> If you read the details of that paper, they are really not relevant to what I mean.

Let me be more specific.

So when I talk about the asynchronous nature twitter/texting/facebook what I mean is that there are people now (usually young people) who are comfortable with carrying out multiple conversations with different people/groups of people that occur at different rates of time. I am not suggesting that someone who is frequently using twitter/texting/facebook while at work would be more productive than someone who doesn't, but that this experience helps them be able to manage multiple workflows better.

From my own experience, when I talk about multi-tasking as far as it relates to a developer anyway, let me give you an example of something that I can do all the time: I get assigned a bug, I look at the bug board to see what other similar or related bugs there might be, and I assign them to me. Usually this means that some or all of the steps to reproduce the bug are the same, so that if I have to step into the debugger to identify the problem I can set breakpoints in places that should help me figure out more than one bug at a time. In the middle of this, a co-worker sends me an instant message asking for something. I don't immediately know the answer, but I know the general area of the code to look for the answer, so I dig around for a few minutes and then either reply with what was asked or a "I don't know but xyz worked with that code and might be able to help you better." Then I go back to my debugging. I find the bug, or I find a clue that will lead me to the bug, and I write some code, deploy it on the test server, and start a test, which I know will take 20 minutes or so. In the meantime I might reply to some e-mail, do some code review to see what might be refactored to be more readable and/or maintainable, or work on another set of bugs. Then when the earlier test completes I go back to check on it. I might not immediately go back to it after 20 minutes depending on where I am with my other tasks, I would probably find a good natural stopping point first, but the point is at the end of the day I am able to finish all these tasks much faster than if I did them one at a time sequentially.

I don't think what I just described takes particular mental prowess and most of the younger people at my work (and a few of the older ones too) do the same as well. But there are enough older workers who just get hopelessly lost if you ask them to do more than one thing at a time, whereas if I ask a younger co-worker to do the same thing they have no problems, that I have noticed it.</comment></comment></comment></comment></comment>


ATT Uverse and Cell Phone Service Down for all of the Bay Area - <AUTHOR> Around 11:40 ATT Uverse and Cell Phone Service stopped working correctly. Some sites such as Facebook were accessible, but images didn't load properly. Many other sites were not available. ATT Uverse was down till about 12:40PM. A DNS issue is the most probable cause.<p>Twitter went wild: https://twitter.com/search?q=%40att&src=typd <comment><USER2> It wasn't just the Bay Area, happened to most of us here in Austin, and to some family in Iowa as well. I'm assuming it had something to with AWS?

[http://downdetector.com/status/att/map](http://downdetector.com/status/att/map)

<comment><USER3> Wasn't just UVerse & cell either, my AT&T DSL service in San Diego had a severe partial outage for close to an hour. I could access some limited subset of the net in general but most connection attempts resulted in 100% packet loss.</comment></comment>


A virtual counter-revolution - <AUTHOR> http://economist.com/node/16941635

<comment><USER2> The Economist and I seem to have a different definition of "open".</comment>


Vonnegut's Asterisk (2013) - <AUTHOR> https://axelhow.com/2013/01/19/vonnegut-asterisk/ <comment><USER2> One of my favorite quotes by him (well, technically a character of his):

> "Be careful what you pretend to be because you are what you pretend to be."

Seems quite apropos these days (also!) in which quite a few people who've dabbled in the "trolling for the lulz!" pond have ended up drowning, metaphorically speaking.

<comment><USER3> Was that from Mother Night? That is an amazing book.

By pretending to be a Nazi to spy for the allies, he turned out to be very good at being a Nazi.

It's a dizzying trip around the age-old question of are we defined by what's in our hearts or by our actions, or perhaps our actions are the clearest indicator of what's in our hearts.

<comment><USER4> That was my primary takeaway from Mother Night.

I have found the idea that there isn't some authentic, secret me that no one really knows to be very useful in my life. Many of us have large discrepancies between how we see ourselves and how other people see us, and I have seen a lot of people file off the gear teeth in the clockwork of their minds (to use another idea from Vonnegut); fantasizing that there is a "real" us that other people just can't see is a useful tool for doing that kind of work.

As I understand it our human being ness is largely bound to how other folks perceive us, and when we get feedback from others it's important to listen to how they seem to understand us... that's been a hard thing to learn and apply, but it's been useful in changing that feedback into (hopefully positive) changes to how I treat other people.

</comment></comment></comment><comment><USER5> Vonnegut is the author that I wish I was, and was a major influence on my reading, thinking and creating. Strongly recommend picking up a few of his novels, you wont be able to put them down. My favorites are Slaughterhouse Five, Cats Cradle, Breakfast of Champions and God Bless You, Mr. Rosewater

<comment><USER6> I agree that everyone should _try_ and read Vonnegut but don't expect everyone to enjoy it or find in it the awakening I sure did.

I think his writing really clicks with a particular type of person at a particular time in their life; if either is not quite right it seems reactions range from disinterest to hostility.

I discovered Sirens of Titan and Player Piano in high school and loved them immediately (unlike so much assigned reading) but I'm not sure I'd feel the same if I was to read them for the first time at this stage in my life. For instance, I still enjoy re-reading Hocus Pocus or Jailbird but not so much Slaughterhouse Five. I can't precisely say why, but so it goes...

<comment><USER7> I kinda had the same feeling with Slaughterhouse Five as you. I know with music this has happened to me...but some albums, if I listen to them enough, I start to really like them. Maybe you should try reading SH5 a few times and see how it settles in...the first time reading it was soo good...

</comment></comment></comment><comment><USER8> I have a cereal bowl that has this image printed within it. I can figuratively and literally eat the "Breakfast Of Champions" with it.

</comment><comment><USER9> For those who don't know, that's not an asterisk.

<comment><USER6> It sure looks like the Greendale Community College flag to me...

<comment><USER10> _E pluribus anus_

</comment></comment></comment><comment><USER11> I don't seek vengeance but when I am redeemed : "Ting-a-Ling , you son of a ..." runs through my soul. Thanks Mr. Vonnegut.

</comment><comment><USER4> I dunno if it is authentic, but I own a paperback copy of Slaughterhouse-5 signed "With Love, Billy".

<comment><USER12> I have a letter he sent me (embarrassing story actually). Someone asked me if he had signed the letter with an asterisk. Didn't know that was a thing of his. (I mean I had read the book but didn't know he used it when he signed his name ... sometimes?)

</comment></comment><comment><USER10> My only regret is that I have but one asterisk for my country.</comment>