gruseom

That the site looks old and minimal seems to me an advantage.

Your comments have evidently not been disabled!

Have you perhaps misunderstood the karma restriction to mean that people with less karma will have their comments be less visible? That's not the idea.

If the number of comments, on the other hand, hadn't gone up since 2012, I'd be shocked.

The idea that downvoting for disagreement is not legitimate is a classic instance of the canonical invasive species on HN, the Redditism.

No, that's wrong. Downvoting for disagreement is how downvoting is meant to be used, as pg has made clear on HN many times over the years.

[I edited the previous sentence to make it less ambiguous.]

The confusion persists because Reddit's rules are different, and people remember those and mistakenly assume they apply to HN.

I may have asked you this before, but do you know of any finding in the research literature that you don't consider pseudoscience? The only one I know of that might come close is research on code size. I've heard that the literature on code inspections is good, but that may just be another myth.

I did like the paper on code size very much. The principle that code size is the best measurement of complexity and a good predictor of error rates is probably the finding I'd name if I had to answer my own "name one that isn't folklore" question. At least that one has multiple studies behind it. Even so, most of them (that I've seen) aren't very good.

You place so much emphasis on dismantling the 10x claim (writing an entire book about it) rather than software research in general, that an observer might reasonably be left with the impression that there's something more "mythy" about that claim than others. If so, I'd say that's misleading.

Folklore isn't ipso facto false. If folklore gets repeated as persistently as 10x does, I'd say that speaks weakly in its favor. (Please note that I said "weakly".) Because of this, I don't think it's irrational to continue to favor that view, even after debunking those studies. For one thing, the opposite claim is even less supported by data. For another, it fits loosely with my experience and that of others I talk to. Experience in the field may not be controlled measurement, but that doesn't make it rational to dismiss it.

I do think there's something to the 10x claim about individuals; I think interaction between individuals is even more important—100x, one might metaphorically say—and that question is even less amenable to formal study. I doubt that we'll ever see convincing quantitative results on either of these things. Building teams will remain an art, and folklore and myth are the stuff that art is made of.

[Edit: deleted mistaken impression here.]

In software, one source of irrational ideas has been the management models that were developed for industrial and manufacturing organizations. Since building software is a design process, not a manufacturing one, these models don't apply. The industry is slowly figuring that out, but that has left plenty of room for an inefficient market in the meantime—middle managers being perceived as more valuable than programmers and all the rest.

"Mr. Davies mentioned my name, and respectfully introduced me to him. I was much agitated; and recollecting his prejudice against the Scotch, of which I had heard much, I said to Davies, 'Don't tell where I come from.'--'From Scotland,' cried Davies roguishly. 'Mr. Johnson, (said I) I do indeed come from Scotland, but I cannot help it.' I am willing to flatter myself that I meant this as light pleasantry to sooth and conciliate him, and not as an humiliating abasement at the expence of my country. But however that might be, this speech was somewhat unlucky; for with that quickness of wit for which he was so remarkable, he [...] retorted, 'That, Sir, I find, is what a very great many of your countrymen cannot help.'"

Had Boswell been more thin-skinned or less stubborn, we might have had no Life of Johnson, and so no Johnson either.

I don't think there's any "statistical significance" (using the term loosely) in the failure of Lisp, Smalltalk, or any other language to become a big success. There are too many non-technical and historical factors that can easily explain all these outcomes. Meanwhile the sample sizes are so small—consider how short the list would be of all programming languages that ever had a major turn at bat—that we have no way of drawing true conclusions about this.

For example, it's easy to make a case that Smalltalk lost to Java because (a) the Smalltalk vendors were short-sighted and (b) Java was magically "the internet language" just when the internet was everything new and important. Those are historical accidents that had nothing to do with abstractive power.

A word about the 'antisocial' argument, which I think is deeply wrong about both Lisp and Smalltalk.

It's true that Lisp and Smalltalk let you define "if". That's a measure of their power. But anyone who thinks that Lisp and Smalltalk programmers willy-nilly define "ifs" all over the place (or do anything at that level very often) does not understand the culture of these languages. There are many examples of such willy-nillyness, but that's because it's a phase most programmers seem to go through with this stuff. (I did.) Experience teaches you to be more discerning, and culture, when you're lucky enough to be exposed to it, accelerates experience.

Thus the solution to the misuse of abstractive super-power is culture and community, which work perfectly well in both Lisp's and Smalltalk's case, as their long historical records amply show. A friend of mine was part of the later wave of Smalltalkers in the pre-Java days, and he talks fondly both of how much he learned from the older Smalltalkers (over BBS mostly, since he grew up in a small town) and also how the community as a whole gradually learned to use the power of extending the language well—as well as what to avoid. So it's wrong to attribute some weird anti-social property to these languages. There's even a vibrant counterexample going on right now in Clojure.

In my experience, the kind of language hacking that goes on in Lisp systems is not as you describe it. Rather, it's akin to what any programmer does when extracting duplicate code into a function. A better word for this than "DSL" is "factoring"; Lisp's strength is that it offers a simple and powerful way of factoring that is harder in other languages.

I can't comment on Smalltalk, except to say that the way you've lumped it in with Lisp makes your argument weaker. Those two languages achieve their flexibility in such different ways.