... 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).
Which is possibly why I seem to clash so often with chromatic...
I dunno... I've taken the equivalent of three large novels worth of notes for the Perl 6 design over the past year (and I've written a novel and a half, so I know how much that is), helped quadruple the number of tests for the Perl core, and written a fair few articles here and there.
I've not done as much work as some people, and I'll never claim that I have, but I don't consider myself as having sat on the sidelines.
Re:Talking versus Doing
Alias on 2008-02-01T02:48:09
Most of the clashing I'm referring to in that line is in years past (2005 plus or minus whatever) not in recent times.
I've been hugely impressed by the efforts you've made on Perl 6.Re:Talking versus Doing
chromatic on 2008-02-01T06:51:48
It seems more likely to me that meeting in person moderated our expectations of each other.
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:)
Perhaps chromatic was doing his job which seems to me it would require much talking. And perhaps he was just not talking about the other stuff he was doing (see chromatics response above). Some people are more naturally included towards self-promotion then others, it might be wise if you looked a little deeper next time before making such assumptions.
- Stevan
Re:Not everyone is a showmen
Alias on 2008-02-01T05:41:05
> Perhaps chromatic was doing his job which seems to me it would require much talking... Some people are more naturally included towards self-promotion then others.
Then consider me suspicious of people that choose to do that sort of job (opine, not just report)... and of people that are naturally inclined towards self-promotion.
But I'm quite fine with successful people that both talk and play a big game.
Doubt it. It seemed to me that he was full of himself, or had a lot of time on his hands, because he made a million dollars a few years ago.
Re:Paul Graham
Alias on 2008-02-01T05:43:11
> It seemed to me that he was full of himself, or had a lot of time on his hands, because he made a million dollars a few years ago.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.Doubt it. It seemed to me that he was full of himself, or had a lot of time on his hands, because he made a million dollars a few years ago.
That gives him some leeway to talk about making a million dollars, but then he's only done it once as far as I'm aware (could be wrong).
If he can predict (invest) in a new startup and get it right again, then I get impressed.
I still think it doesn't qualify him to talk about analogies between hackers and painters (unless he's a painter too, which he may well be).Re:Paul Graham
Ovid on 2008-02-01T08:04:34
Methinks you need to read this.
Re:Paul Graham
Aristotle on 2008-02-01T13:27:54
If he can predict (invest) in a new startup and get it right again, then I get impressed.
You know that that’s exactly what he’s been doing for the past couple of years, right? He’s been leading a startup incubator company called Y Combinator that have funded a couple of suitably successful (and of course, as is the nature of such things, a correspondingly large array of failed startups).
He is doing – it’s just that his sphere of “doing” is different from the day-to-day hacking you and I dwell in.
I still think he talks a lot about topics where he is probably less qualified than he seems to think, but he’s not all talk. Which, actually, makes the whole thing a lot more complicated, because one needs to be much more careful about when to be dismissive and when to examine his claims seriously – if he was (mostly) just a blowhard or just an expert, this would all be much easier.
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".
Because the one's a document and the other is a GUI. If I wanted to display a document, I wouldn't use GTKs box model. That's like back in the old days when we just crammed huge texts into VB dialog boxes. If I wanted to display any kind of document (that doesn't already provide a widget), I'd use HTML, even in GTK, KDE, or anything else.
That said, I have no problem in putting a webpage in a big table. I have a problem with 22 nested tables.
(God only knows what we'd use build_requires: perl: for, but it does give us consistency across the dependency specification)
I think cross-compilation can be one example of such uses. Imagine a distribution which may use a later perl to build sources (including generating fancy code and doing pesky pre-computations) which will be then run on a less powerful perl (supported in embedded devices).
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”.
What’s bad about tables is that they mix presentation with content. Tables in content should be used for tabular data.
The fact that CSS only has a print-world-originated float layout model but no screen-UI-originated hbox/vbox packing layout model is a serious shortcoming, not good. I don’t know where you picked that up, but if you were told so by anyone, then that person quite simply doesn’t have a clue.
Problem is, with tables you can’t do float layout, and that’s important for content; whereas with CSS you can’t do hbox/vbox packing, which is important for what’s known as “chrome” in the web app world.
Tables don’t give you hbox/vbox packing either btw, unless you’re willing to live with monstrous nested markup undergrowth… So basically you get an approximation of what you, for the price of utterly butchering your content markup. That is the problem with presentational tables.
Re:Unclear on the concept
Alias on 2008-02-01T19:02:06
I guess I'm just a chrome'y kind of guy.
