Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Thursday January 31, 2008
07:44 PM

Arc is Released, and it Makes Me Happy

[ #35548 ]

... 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).

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.

    • 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.
      • 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 [perl.com] 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 li

    • > 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.
  • 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.

    • 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.

      > 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).

      • Methinks you need to read this [idlewords.com].

      • 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 d

  • I pity the people who, perhaps thru faulty judgment or having someone misrepresent Graham, spend time investigating Arc, only to find it's a waste of time. I'm not worried about those who realize clearly what sort of risk they are undertaking.
  • 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 :)
    The chromatic I know you can barely get a word out of him. When you do, it's sarcasm anyway. :P That mean he does a whole lot?
  • 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 doc

    --
    Ordinary morality is for ordinary people. -- Aleister Crowley
  • (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’

  • Is that he actually did enough years ago to earn some serious respect. You probably aren't aware of it because you're not in the Lisp community. Therefore you haven't seen what he did there, or read the resulting classics like On Lisp.

    Back in the mid-90s he decided to show that his knowledge of Lisp was not just theoretical. With a group of fellow elite Lisp programmers (his co-founder was Robert Morris - you know, the guy who took down the entire internet back in the 80s) they founded a company that suc