... although not because of anything to do with it being any good.
Since I'm not a Lisp programmer, I'm in no position to say whether it's good or not.
Of the two most-commented-on things, I'm anti-ascii-only and (perhaps oddly) pro-tables. I've been bitten too many times by problems with CSS layout compatibility issues, and I find it an amusing double standard that GTK packing boxes are "good" but what amounts to HTML packing boxes (albeit also ones that can be used to display tabular data) are "bad".
Regardless, I'm excited about Arc, because it resolves one of my biggest annoyances about Paul Graham. I have no idea what he's like as a person, but he likes to talk, a LOT.
And I'm naturally suspicious of, biased against, and aggressive towards, people that talk out of proportion with they amount that they DO.
Which is possibly why I seem to clash so often with chromatic
(Although admittedly my respect for him has grown in leaps and bounds since he started "doing" more things, and especially since he started putting in the hard yards on parrot)
If you are going to be outspoken on a topic, to the point where you seriously expect people to accept what you say as truth or for them to do what you say, then the lowest form of discourse is opinion.
Opinions are for places like product feedback, feature requests, usability comments, and movie reviews. Things that CLEARLY contain elements of personal preference.
One of the things I liked about Cringly was the "Mr Toad" imagery on his column. It was an acknowledgeable that his stuff was by default a load of hot air.
One step up, but still not a particularly strong form if argument, are people that speak from experience. If there's one thing that got hammered into my head in the few science'y parts of my engineering course, it's that Correlation Is Not Causation.
It's all well and good for people with experience to relate STORIES. Those are positive. They provide (very often salient) data points. And lacking anything better they make a good starting point.
But since most people talking on subjects are speaking from the perspective of having done things once or twice (usually successfully, otherwise they wouldn't be talking about it) there seems to be a very common mistake of people drawing overly-broad conclusions about TRUTH, when they are speaking historically.
Even if I hypocritically or forgetfully don't always follow it myself, I TRY to hold myself to a standard where if I'm going to propose something as a being some sort of general rule or truth, I can not only provide historical precedents for a hypothesis but also testable predictions.
If I can't, then I try to fall back on the phrase "I think, but cannot prove...".
You need to be willing to admit, in advance, that you might be wrong, and the conditions (outside of your control) for which you admit failure.
This is why New Years Predictions and things like BetFair/InTrade are so great. They both create a solid framework in which to make predictions and have them tested against specific deadlines. Both remove many of the most common ambiguities, and ways in which to wiggle out of your predictions.
But the highest form of argument you can make is to not only make the hypothesis and predictions, but to then have the balls to actually go out and invest your time, energy and income (real or potential) to actively test the prediction yourself.
Call it "Test Driven Discussion" if you want.
Most of what Paul Graham says strikes me as being full of hot air, or an (intentionally or otherwise) exploitation of the cognitive biases of his audience to accept his points.
Granted, he's a good writer. This is essential for being an exceptionally powerful opinion-maker (and why I am NOT an exceptionally powerful opinion-maker, since my writing sucks).
But much of his writings appear to me to be quite fuzzy and without clear testable predictions.
And that is why I'm hugely positive about Arc.
This is Paul elevating himself to a higher level of discourse and personally sticking his neck out for something he believes in.
Either he's going to be correct, and Arc will become a useful and interesting dialect for lisp programmers.
Or he's going to discover SOME of his hypothesis were right, and some were wrong. And he'll fix the parts he was wrong about.
Or he's going to be wrong about something so fundamental that he won't be able to fix it, and will flame out miserably.
So we either get a useful new language, or we get a Paul Graham with better insight on his areas of fallibility and (hopefully) greater humility and less of a tendency to make bold untestable statements.
Either way, the internet wins.
Nothing Can Possibly Go Wrong.
And to finish up, allow me to recant one of my own hypothesis.
I've previously said that having perl: 5.008 in the requires: section of META.yml was a bad idea, and we should move to a clearer explicit perl_version: key.
I thought that the advantages of gaining a clear simple identifier would make it worth the pain of dealing with back-compatibility.
I was wrong.
Not only does keeping that special case and formalizing it let us retain backwards-compatibility with existing implementations, but it would also allow us the additional flexibility of having "requires: perl:" not only in requires, but also in build_requires: and configure_requires: as well.
Which means we gain the ability to explicitly separate the version needed to RUN the code with the version needed to run the Makefile.PL, without having to run the code first and watch it explode in order to determine that the Perl version is too old (God only knows what we'd use build_requires: perl: for, but it does give us consistency across the dependency specification)
And specification is always preferable to execution when you can achieve equivalent fidelity (another hypothesis of mine).