There's one paragraph in there that I think sums the entire essay. When I read it I was so stuck by it that I put that paragraph on my desktop image (http://www.cocunderground.com/desktop.jpg).
Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.
So when you look at something like Reddit and think "I wish I could think of an idea like that," remember: ideas like that are all around you. But you ignore them because they look wrong.
Reading PG's essays makes me very happy. Quoting again:
Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.
I remember reading Paul's essays, pre YC. When he wrote the essay announcing it, I remember thinking, "This guy is crazy, all he's gonna get is a bunch of school projects." Sure enough, he did, and wrote about it. I felt vindicated by that, saying to myself, "I knew THAT was going nowhere." People like to be correct in predicting failure for others, for whatever reason.
After reddit, loopt, zenter, anywhere.fm, etc., however, I don't think I was completely accurate in my prediction....
People like to be correct in predicting failure for others, for whatever reason.
I know there are a lot of people like this, but there is also a perhaps equally-large number of people who feel the opposite way. Personally, I love to be proven wrong when I predict failure, unless I have some other reason for wanting someone to fail (they use unethical practices, they're my direct competition, etc.).
I think people like to be correct in predicting the failure of crazy-sounding ideas because they don't want to feel like they are missing out on something big. I know I predicted that Google was all hype when it was selling at $200/share and unloaded the few shares I had. I kick myself for it now obviously, and even though it made no financial difference to me whether it sunk to $25 or went up to $600 (since I no longer owned shares), I still couldn't help hoping it would tank so I would feel like I made the correct decision.
I think this is really why you don't have to worry about competitors. If your idea is good enough, everyone will think you are crazy/naive. If your idea is simply decent, you'll never pick it anyway (because it's not exciting enough to you) and it will end up getting done by some existing company. Either way whatever you actually choose to work on will be unique until it's proven, by which point no competitor is catching you anyway.
> so I would feel like I made the correct decision
It's not just about feeling. If Google had tanked, you would be more justified (in a statistical sense) to think that you're smart and to engage into more financial transaction.
The difference is that the negative folks are the most vocal, while the positive folks are trying arc instead of whining about their perception of Paul's behaviour.
For example, I was just over on programming.reddit.com. The majority of the comments on this essay are smearing Paul's character. If you went by that, everyone hates it.
Yet the essay has +115 points. So there are 115 people who liked the essay for each person who dislikes it. Where are their comments?
Maybe they vote because they want the story to stay on top a while, either to convince others (Ron Paul) or because they want to see the discussion. Reddit is like a reality show. You might vote for the candidate you liked best, but you might also vote for a troublemaker to ensure a good show.
Maybe the ability to reach customers around the world much cheaper than any other way? Remember that the first (and most of the) customers were already-existing businesses, hence they presumably already had a method for processing transactions.
I don't think anyone was really processing credit cards through the web at that point, at least not unless you paid out the nose for a custom system. "Sales" could still be made over the web, you just couldn't receive payment for them - like an online catalog really.
They wanted to be able to generate a good-looking site with large numbers of products and a way for people to order them. Till about 1997 online order volumes were so small that it was no problem for merchants to manually punch in credit card nos on their POS terminal.
I agree on general principle, but there's a big difference between Viaweb & YCombinator vs. Arc:
Market.
Viaweb and YC were each aimed at the overlooked low end of a market. Small businesses may not be sexy, but they had a pressing need for a web presence, and the can't write it themselves.. College students and young professionals may not be experienced, but they have a real need for money and advice, and they (usually) can't fund it themselves.
Arc, however, is explicitly aimed at the high end. It's meant to be a "LFSP". And smart people can write Arc themselves (and have ;-)). They don't need a new programming language; if they wanted one, they could invent it themselves.
Hence the contemptuous reaction, and why I think Arc is in more trouble than either Viaweb or YC. It's not really a problem when your peers are contemptuous, because that just means they're less likely to compete with you. It's a big problem when your users are contemptuous, because that means they don't need your project.
If I were in charge of Arc marketing, I'd position it as the "PHP for the ones that PHP forgot". PHP initially got its start as a way to throw a quick & dirty webapp prototype up on the web, and then incrementally refine it. But around version 5, it started getting complex and adding all these features from Java. That's left a vacuum at the bottom of the web language market. Rails and Django tried to fill it, but the average Django user is quite a bit more sophisticated than the average PHP user circa 1999. And Arc's design is already pretty well-suited to throwing a design up on the screen quickly.
Right now, the majority of Arc users seem to be disenchanted Lispers. Disenchanted Lispers tend to be smart people, and they also tend to be interested in language design. So instead of doing things with the language, they do things to the language. On arclanguage.com, I've seen one person write an app with the language, and several dozen people write enhancements of the language itself, either in the form of macros or as hacks to the interpreter itself.
Upmodded for your first half. But Arc is definitely not drop in replacement for PHP. And you can use PHP 5 in basically the same ways you could use PHP 3.
They don't need a new programming language; if they wanted one, they could invent it themselves.
Where is it, then? Where is the final, perfect Lisp that's so easy to write?
What you seem to be saying is that being smart automatically makes people good at language design. And you are just dead wrong. Being smart may make you a good language implementor, but there's little correlation between that and the kind of skills you need to be a good language designer. Some of the worst languages in the world were designed by smart people.
It's a big problem when your users are contemptuous, because that means they don't need your project.
The Arc users on arclanguage.org don't seem that contemptuous.
So instead of doing things with the language, they do things to the language.
That seems a good sign to me. Munging the language is what you do with Lisp, like numerical calculations are what you do with Fortran. So what this means to me is that the users are real Lisp hackers, using the language as Lisp is meant to be used.
Plus I explicitly said that at this stage I'm mostly interested in the core language, and that I want to hear new ideas in that department.
"Where is it, then? Where is the final, perfect Lisp that's so easy to write?"
Maybe there isn't a final, perfect Lisp. Maybe there are lots of individual Lisps that are each perfect for some class of problems. That's one of the great strengths of Lisp: if an existing implementation is almost-but-not-quite what you need, you can throw a few macros on it and adapt it into a new language that is what you need.
It's one of the greatest weaknesses too: you don't see the same willingness to say "This is good enough; let's move on to more interesting problems" that you get with, say, Python/PIL or Ruby on Rails.
If you're going to create a new Lisp (and expect people to use it; creation for the sake of creation is another thing, and doesn't need justification), you've gotta answer why it's superior to throwing a few macros on top of an existing Scheme or CL implementation. After all, wouldn't an individual programmer know his specific problem better than you do? They don't have to worry about harmonizing a variety of concerns, because they don't have to worry about other people's concerns. They could just build the language that's best for their specific problem and keep it in their own private toolbox.
What you're doing is arguing semantics. Whoever feels like replying to a reply of a reply long enough that all meaning has been lost and the other person stops posting, is the "winner." Whover is smarter and can come up with great examples can easily make another person defensive and tired of arguing. This person can then "win" arguments simply because the person who just wrote about actually developing something is busy developing.
This is actually what causes that disparity between what people think of new technology when it first comes out and two years later, as long as it still exists: one party was busy developing, the other party was busy coming up with reasons it can't be done, getting pats on the back for being so smart, then riding that dopamine rush to nowhere fast for two years until they meet the product again and just say "oh, I was wrong." Then this cycle continues. That's what PG's essay is about.
But being unable or unwilling to argue semantics does not make the original poster's ideas wrong. The only way to prove a determined person wrong is to engage in direct competition, and from the rear, of course, as the other party is already ahead of you. For obvious reasons, it's easier and "smarter" to come up with "logical" reasons than to "do the full experiment" to show it's wrong. We're not talking about math equations here, so a productive person's potential is more than his writing but also his skills, experience, credibility, and dedication, which can't all be ignored.
Actually you're wrong because you're assuming that writing (trolls or anything) isn't a skill. It is, and if you got trolled it's your own fault and I'm your feelings were hurt. In addition, you obviously don't understand the first thing about "semantics."
If you're going to create a new Lisp... you've gotta answer why it's superior to throwing a few macros on top of an existing Scheme or CL implementation.
If that were true, Scheme and CL wouldn't exist themselves. Everything you can do in those languages you could have done by writing a few macros on top of their predecessor, Maclisp.
What you seem to be saying is that the evolution of programming languages has now stopped. No one ever needs to make a new LFSP, because SPs can do whatever they need by writing macros on top of existing languages. Do you realize how unlikely this is, historically? Especially in a field like programming languages, which is at the moment in a period of ferment.
If you think CL is the last word in Lisp, you probably have a higher opinion of it than any of its designers. They were in the kitchen when it was being made, and they are all too aware of all the hacks and kludges that went into it.
"Right now" doesn't and will never matter. "Right now" is incompetence, lazyness, lack of awareness, comfort, and politics all rolled into one. That's the definition of "right now." It is a horrible, horrible measure of what can or should be achieved.
I don't think Paul intended this to be a ground-breaking article. I doubht he's saying that those specific examples lead him to a certain process with a certain guaranteed successful result. In other words, he's not saying because a=b, and b=c, a=c. In that case, if you can disprove the examples, Paul's theories don't stand.
What I interpreted PG to say is that he has done things a certain way for a while, and has noticed correlation where people reject change time and time again, but that this is normal, and in fact, one of the steps in the process of innovation.
You need to 1) come up with a simple concept that benefits someone, especially yourself or someone you know who might care to look at it when it's ready (that you know you can do in a weekend even if it actually takes you a while) 2) promise to that person or anyone else besides you that you will release the software you promised 3) release the crappiest version you can that has the least features and is so unimpressive that it's stunning (esp. if you release before your deadline which gets you feedback sooner) 4) take criticism and make adjustments 5) come up with a system to make promises to do x by a certan date and a parallel system to make and measure forward progress towards any of the objectives 6) stick with it because people really love it when you've been so dedicated to a project 7) you're now an expert and have a lot of design and coding experience under your belt, as well as happy users who like that you're improving the app and listening to them.
Most people never get past step 1 or 2, even though at those steps you really don't have to do anything.
Oh, and step 8) you will learn what makes your body tick and become very efficient and feel like you're "improving exponentially" and 9) you will come up with ideas and insights that may make you sound insane, especially since you'll be so confident and focused you'll be blurting them out, but that 10) a year or two later will have been proven 100% true.
As a final word of product development advice, Levchin encouraged founders to think about the Bible’s seven deadly sins - especially greed, sloth, envy, pride and gluttony. These characteristics, he said, describe many of the primal motivations for users.
I think there's very interesting thing happening around Arc. It appears that people there are less afraid of making mistakes or repeating past attempts. Maybe because pg broke some Lisp traditions so that others feel more free to step out of them as well. Maybe because people with other language background are gathering so there are more divergence of minds.
I have my own Scheme implementation (Gauche) and I live on writing software in it, and I keep trying new ideas with it. For that regards, I don't need Arc. But that kind of atmosphere at arclanguage.org, that's not something I can get without Arc.
Maybe most of the ideas tried there will turn out not to work, but new ideas need a place like there to come out. In a sense, Arc isn't a new programming language, but a medium that sheds a new light to the language design process.
And I'm watching it closely to steal whatever good ideas that come out :-)
It's funny, I was commenting to a friend a couple days ago that I really liked arclanguage.com because people were hacking there instead of talking about hacking or arguing about hacking. Kinda at odds with what I'm saying on this thread. Maybe I'm just a natural contrarian.
I dunno. I could certainly be wrong - I was about Reddit. (Though I was also wrong about Xobni, and they did basically the opposite of everything PG suggests in this article.)
Maybe I'm just not the target market for Arc. I'd like to think I'm a smart person, and I did download it and play around with it and reimplement it. But right now, I'm finding that Python and JavaScript let me do more cool things, so I'd rather play around with them.
Agree- very small market for Arc. I know hundreds of people who can benefit from Viaweb, tens of people who can benefit from YC, no single person who will use Arc.
Agree. There is a world market for maybe five computers.
Ok, I am joking you may be right. But it is notoriously difficult to predict the market for programming languages. had you attended LL2 on [November 9, 2002](http://weblog.raganwald.com/2007/01/where-were-you-on-saturd...), could you have predicted which of the languages discussed would be popular... five years later?
I dont know. Market for this kind of computer language vs eshop solution and funding is very small in comparison. Market means someone will pay for using Arc.
Is it for a programming language startup to make money if you have a superior language? Say you have a programing language that is to Lisp as Lisp was to Fortran, how (if at all) can you make money from it?
Do you think that the language you use matters much? i.e. if you have a language that makes you twice as productive as in Arc, would that be a big advantage or a small one? (compared to having money, a good idea or being smart, etc.)
Assuming that a significant portion of your time in a software startup is spent programming, a language that makes you twice as productive means you can try twice as many ideas, or develop the same software and free half your time for finding capital or users, or shortening your time to market by 50%, wouldn't any of these be a significant advantage???
From my experience in most startups (2/3) spend the first 4 months almost entirely on programming. Later stages are obviously more balanced as other activities begin to take the spotlight.
So according to your stats you get a 25% improvement in productivity by using non-Blub language (don't worry as you gain familiarity with non-Blub programming this will actually improve) and that means launching a month earlier.
The only reason to not use a non-Blub language is that you need to write in the Lowest Common Denominator of your team and if the entire team isn't comfortable in a specific language you'd better not use it.
The only exception to the above rule is if you separate your efforts in a very specific way, if instead of using the entire team to build project A, you use part of the team to build tools that help build projects like project A easily and the rest of the team uses the tools the other half created to actually build project A. In which case the tool building group can use more powerful languages without any adverse effects.
It's been tried, eg. Clean, Dylan, or Miranda. Results are not really encouraging, and the language often gets open-sourced after its owner realizes they can't make money off it. And those languages are really nice languages (Dylan is my favorite Lisp variant, and Clean and Miranda are in many ways friendlier versions of Haskell).
Companies tend to have much better luck if the language is attached to a product, either as a scripting language or as part of a RAD suite. Think of AutoCad/AutoLisp, Flash/ActionScript, or Visual Basic.
Yes, when Evan came to speak at YC recently I was struck by the similarities. Here was an idea that was literally right under everyone's noses for about 10 years, and everyone ignored it.
Evan is a great product designer. That's his secret weapon.
Yesterday I was watching Smith&Jones, Britcom also has much of this, constructing ideas around the stupidly obvious and ignored on the perspective of the comic writer.
"When I first laid out these principles explicitly, I noticed something striking: this is practically a recipe for generating a contemptuous initial reaction."
Jeffrey Rosen has some good stuff to say about this in his book The Unwanted Gaze. One of his defenses of the right to privacy is that new ideas often seem wrong at first, especially when they're still only half baked. And because of this, progress is seriously impeded when the government has the ability to go through our journals and sketchbooks at any time. This is especially true in our made-for-TV society where most people won't put more than thirty seconds into trying to understand something, esp. considering the factors PG mentions. He suggests that for these reasons innovation may not be possible in a fully transparent society.
The saying I have for this negative reaction is "people see only what is in front of them." A good concept with poor presentation will be dismissed, and in the case of a language like Arc, presentation could also be defined to include "number of features, immediate utility, etc."
I know my reaction was similar to the crowd, but even so I recognize that it's the wrong thing to look for. If Arc's initial release state could be summed up as "Lisp with some cleaned-up and rearranged features," then it's really not that different from say, Digital Mars D, which is best described as "C++ with some cleaned-up and rearranged features." The difference is, D has a massive compiler backing it, and its scope is unlikely to change. Arc's minimal implementation substance only makes it easier to change tack midway.
I've only gradually learned to restrain my sense of ego and take a similarly minimal approach with my own projects(indie games) - my newest process is to always start the final implementation with a text console interface. Besides encouraging better architecture in preparing for a later graphical interface, it's easier to debug the key elements this way than to have "stuff moving on the screen" at 30 or 60FPS and get frustrated figuring out which of those frames is the one where you're getting an error, let alone what routine is causing the problem.
I like to add a 7th - the ability to ignore problems that are irrelevant to the problem at hand. PG actually mentioned it all over the essay, but seems to have left it out.
btw, thanks PG, this essay has a very profound effect for me; makes me rethink some of the "ideas" I have and how I will approach them.
I like a lot of what this essay says, but I still don't think it applies to Arc. Because the criticisms of Arc would have happened no matter what the design had been.
For the most part, Lisp people will never like any modification to the language that changes their pure abstract computation engine into something that more people would want to use.
Behold, a Usenet post from 2000 on the notion of a "lispscript" that could compete with perl or awk:
That said, I personally have no idea if Arc is all that good or not. I get it, but it doesn't inspire me the way Haskell or Erlang do right now. But Arc seems to be successful by the designer's own standards.
I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.
I'm still trying to get a handle on which of these apply to Arc. Perhaps I'm looking at it the wrong way, but Arc feels a little light in areas (a-c).
In general, at this stage, the amount of flak that Arc has received is so disproportionate to the normal amount of flak that new ideas receive because it hasn't solved any problems that real hackers have encountered, well enough that they'd want to switch to writing programs in it. You haven't really solved the overlooked problem of core language design until people start using your cleaner core language, and to do that you'll have to give people compelling reasons to start using it. If you don't agree, the BeOS people have solved the overlooked problem of operating system design and are on their way to meet you, together with the people who invented Esperanto.
It solves the problem hackers face in every program they write, and which high level languages exist to solve: making programs smaller.
Try translating some Arc programs into Common Lisp or Scheme and you'll see what I mean.
And incidentally, I don't have to give hardened users of existing languages reason enough to switch. There are new people learning to program all the time, and to them, all languages are on a level playing field. If they look at Arc and CL and see that programs are 50% longer in CL, why would they choose CL?
Ok, I think I get it now if I look at the "Arc approach to language design" instead of "Arc in its present form". The problem isn't to come up with a better language, it's to set a good example of the better language production process and in doing so perhaps get a better language as a byproduct. Here are the morphisms I see:
a) Programs in "high level" languages can fail to be shorter than their lower-level equivalents. The simple solution: be merciless in keeping the important things short!
b) The overlooked problem in language design is high-level language brevity.
c) The "language design" problem that needs to be solved is... not sure about this one. I'm guessing it's the fact that the rate of change in the field is putting more programmers into the role of language designers at an increasing rate and anything that helps them avoid bad decisions based on ignorance is significant.
d) deliver informally as possible: when designing a new language, write enough to make the goals clear, address issues in a discussion group and put the code somewhere without sweating organizational details like setting up code repositories, bug tracking systems, regression frameworks, etc.
e) crude version 1: implement the minimal stuff using an existing system and don't worry about the fact that to the unaware it may seem just like a trivial program in that system.
f) iterate rapidly: don't get bogged down by things like release processes and backward compatibility. Just focus on getting feedback, experimenting, measuring and looking for improvements.
Arc solves the problem of making programs smaller, I agree. I'm not merely admitting that: that's exactly the thing that's impressed me about Arc 0 in the first place. But the problem with programming languages is that they aren't single-purpose honed tools: they're more like a swiss army knife, or a house that the programmer has to live in, or an operating system for the programmer's thoughts, if you will. What a programming language has in common with all of the above is that it has to solve very many problems at once: in order to be considered an unequivocal advancement, it has to solve _all sorts_ of problems at least as well as languages people are already using. Arc currently solves only one problem, albeit very well, and solutions to all of the other problems (copious libraries, that profiler thing you mentioned in one of your essays, abundant and welcoming documentation - all stuff you've identified as necessary for a successful programming language in your own essays, in fact) are being delayed until a later release, an unspecified date in the future.
Taking the analogy to a house, Arc is like a half finished construction project. The frame is up, they're still putting insulation in, and there's one finished room with a cot, a table, and a hot plate which Paul Graham is using to cook the news.yc software. Sure, you might attract scads of interior decorators by opening your house up to random strangers, but very few programmers will be willing to come over to live in Arc. They'll stay in their own houses which are already well stocked with comfortable furniture, decorations, etc., even if it is all a little cluttered and you have to go through the kitchen in order to reach the library from the bedroom.
Some of the people speaking out against Arc are genuine trolls, but some are just saying in a non-tactful way that they'd prefer to stay in a house with drywall, thank you very much.
Does Arc make JavaScript look really verbose? I'm guessing it does, if conciseness is its primary goal. How much of the delta is due to its macro system?
I think the six-principles approach is great, and it really shows why the initial reaction will always be contemptuous and therefore doesn't mean anything.
Of course, not everyone can easily copy the approach, you need to be an original thinker in order to not overlook overlooked problems.
I don't understand the last part of the essay about reddit as a classic example. "Tell people what was new", was that an overlooked problem? News agencies have been around for a long time. "Stay out of the way" was only possible because of the user-submission-and-voting system, which seems to me a clever and non-obvious idea. What I like most about this idea is the voting part, it tells me what's interesting, I don't care about whether it's new.
I enjoyed the article, as I enjoy most of Paul's articles.
But, I'm coming to the tech world after having worked in the health care industry for 15 years. And, I studied art for 6-7 years, thinking that I could make a career out of it. So, I guess that I have a different perspective on the geek/hacker culture. And, something about hacker culture that never really set well with me was this--the nastiness.
Paul referenced it in his article, referring to the trolls. I just don't understand why people troll like they do. I didn't understand why people were so up in arms about Paul's trying to write a new language and offer it up for public consumption. I don't understand why people have been so quick to criticize Y Combinator. I don't understand the hating that goes on in language flame wars, or OS flame wars.
I understand that people are passionate about technology, and passionate about their language of choice, or OS of choice, but... really. Do people really need to get nasty about it? Why aren't people able to have a discussion about the merits of a language, or strengths and weaknesses without getting personal or mean about it. I just don't understand.
A great doctor that I worked with, was explaining to me why he got out of teaching at a medical school. What he said struck a chord with me: The reason that there's so much back-biting and politicking in academic medicine is very simple--it's because the stakes are so low.
Which leads me to ask the question--Are the stakes really so low in the technology world, that people are so nasty? I have a hunch that for many trolls, that's really true.
I know that shortly after reddit got purchased the trolls made camp and set up a small troll swamp. There are a few cool sub-reddits, though. Why did that happen? Because the stakes became so low.
Interesting angle, but I really don't believe nastiness has much to do with it.
We hackers are just dying to let others know how smart we are. It's what makes us tick.
So we come here (and other forums and blogs) because most of us have trouble finding peers who even understand what we're talking about. Add in a lack of writing style and the anonymity of the internet, and our puffing and strutting APPEARS to be nastiness.
Put us in a room together to discuss the same subjects and I'm sure it would be much more civil.
Honestly ask yourself. Whenever you heard someone else getting a compliment for being smart, (Alan made the Dean's list!), (Joe is a great chess player!), (Fred wrote the best program I ever saw!), don't you get JUST A LITTLE BIT JEALOUS. You almost want to scream out, "Hey! What about me? I'm smarter than that!" We hold back in person because we're polite. But we don't hold back here, because most of us understand. Sometimes I think that if you DON'T think like that, maybe you shouldn't be a hacker.
Reminds me of an old story that Rabbi Harold Kushner told about a young man trying to temper his competitiveness, so he joined an ashram in Japan. He wrote to his father, "Dad, this environment has helped me evolve to the point of enlightenment where I no longer have to compete with others to achieve my bliss. The meditation has done it. I'm one of the top 5 meditators here, and hopefully, by next year, I'll be Number One."
[UPDATE: I just read the comments about this pg essay on Reddit, and realize that it's different over there. They ARE nasty. What's happened to Reddit? Whatever it is, I sure hope it never happens here.]
> Interesting angle, but I really don't believe nastiness has much to do with it.
My experience is that this is a limitation of communication without subtext, inflection, etc. I don't have a whole lot of time right now for details, but I have noticed a few tendencies that exacerbate emotions in online discussions:
- Deprecating humor seems especially biting without the wink and smile, and the inevitable response from others then appears like an attack
- Posters lump all critics together, and tend to forget who made which argument (but are especially sensitive to having their points glossed over, misinterpreted)
- Often those within technical circles don't realize that different people weigh evidence differently (i.e., two parties may reach separate conclusions simply because they have differing views of which facts are important). Unlike in the math world, discussions and conclusions cannot be reduced to a few simple axioms--there's always the experience of the observer necessary to interpret data.
- There's a tendency to skim critics posts and respond to individual sentences/words (rather than the sum of what was actually written).
I hear what you're saying in terms of people not being able to write well, and that people are trying to beat their geeky chests in a sort of hacker bravado.
I also don't get a really nasty vibe from Hacker news, like I do on Reddit. I was referring to the Hacker culture at large when I was referring to "nastiness". I believe that there is a lot of bravado and competition in Geek culture. But there's also a lot of nastiness, too. In fact, we are developing the English language by devising new language for people being assholes online: griefing, trolling, powning, flames, flamewars, Greater Fuckwad Theory, Godwin's law, STFU, RTFM, STFW, etc... It's only a matter of time before these terms hit the mainstream to describe asshole behavior offline.
Even though he doesn't say it, I believe that Paul has been rather hurt about this often enough several of his last essays have referred to these people as "trolls". Steve Yegge has had enough problems with this, that he's turned comments off on most of his blogs. Pmarca also thinks that this is enough of a problem, that he (to my knowledge) never turned on comments on his blog.
For instance, I went to a boarding school for a year, and was in a dorm with 45 high school boys. There's friendly competition, and then there's getting 64 wedgies like I did that year. (I was the youngest kid in the school, and quite a nerd). A lot of time, putting your work into the intarweeb slipstream of geek/hacker culture is like walking around with your fruit-o-the-looms sticking 2 inches outside of your pants at a boarding school. It's only a matter of time before some asshole gives you a wedgy. And, then you have brown streaks.
My question is this: why do we (not Hacker News, but Geek culture in general) tolerate that behaviour? There is no need for it. If you want to prove how smart you are, make something cool. Or, explain String theory in a way that mere mortals can understand. But, walking around saying that Arc sux because of this and that, or Yegge is a wind bag, or what was J Gosling thinking when he designed the turd that Java is... This isn't productive.
If people make these comments maybe it's because their stakes are so low.
I think it's pretty hard to remove nastiness from competition, since it's such an easy 'win.'
On a tangent, is competition necessary or even beneficial for progress? The world today seems to be founded on this idea, but things would be much different if people didn't believe competition was important. Competition makes products ego based, and I don't think ego based products are the best. People have to aim beyond themselves and the felt needs of others to make something truly excellent.
Hackers don't tolerate bad behavior. They avoid communities that accept mean people (unless they are also mean).
Paul probably only visits Reddit to read comments about something he's done. I left the chatroom #lisp because of the assholicism. (Leaving was an excellent decision. Everything about Lisp can be learned from CLHS, SICP, On Lisp, gigamonkeys.com/book, other books, and Google. It takes patience, but you'll learn far more than by asking someone.)
Communities are a source of power - if you've built a strong one, you can usually get rich. But they require huge amounts of time. Unless you're working toward a specific goal, it seems best to be a lone wolf (or part of a small team) and to operate without considering what everyone else has to say, or to offer you.
I learned to program almost exclusively by asking people and experimenting. It was a mistake to ask people how to do things. You can learn orders of magnitude faster by reading manuals and books than by trying to get someone to help you. Hacker culture isn't necessary, except to feel good about yourself, which isn't necessary. John Carmack knows so much because he spent most of his time in quiet isolation, meditating on problems, not hanging around communities.
I think a middle approach is optimal: Have one or two friends to study with, preferably people you know in real life. You get interesting conversations and gentle pressure to keep up without trolls or groupthink.
I mostly agree with you. But I don't think it's a geek thing per se. Just look at the comments on political blogs. It's the same thing there.
It's the anonymity. Combined with a 95% male audience. If each reddit commenter had to sign with his full name, and his picture would be shown next to his comments, the tone would be quite different.
The reason is very simple. Most of the trolls are nerds, and so they never get laid. Because of sexual frustration they decide take it out on someone by trolling. So trolling stems out of nerd sex denial. Sigmund Freud has explained the critical role sex plays in human psychology; even all wars & bloodshed that happens is in one way or the other connected to sex. In the end, its darwinian instinct.
As for why trolls exist at all, I think it is because it is so darned easy to be rude and generally small-minded and full of self-puffery when the troll has such near-anonymity and therefore no sense of responsibility. I also think that geek communication tends to be brief, and it is easy to be rude with a few short direct words... in the real world, such behaviour is not tolerated but in forums, the troll can just keep posting, and posting, and posting.
As readers, we also absorb rudeness better, and remember the smallest slights, whereas we skip over the fluffy bunny comments where someone chips in with a happy "me too!" or "hug" and a row of smiley faces.
I don't believe this effect is restricted to the computer-related industries. I distinctly remember there being some rather vicious altercations between artists, particularly during the Renaissance period, over whose style was better.
What it boils down to is reputation. Trolls seek only to reduce the reputation of his victim.
If you work on overlooked problems, you're more likely to discover new things, because you have less competition.
I'd like some help interpreting this sentence.
Why does the lack of competition make it more likely you'll discover new things? (And what is things referring to?)
I assume it means you can attack a problem at a more leisurely pace, so you see solutions you would have missed if you were in a feature-copying war with competitors. But I doubt PG would advocate running your startup leisurely.
"Robert L. Helmreich [tested] the relationship between achievement, on the one hand, and such traits as the orientation toward work, mastery (preference for challenging tasks), and competitiveness, on the other. A sample of 103 Ph.D. scientists were rated on these three factors based on a questionnaire. Achievement, meanwhile, was defined in terms of the number of times their work was cited by colleagues. The result was that "the most citations were obtained by those high on the work and mastery but low on the competitiveness scale."
This startled Helmreich, who did not expect that competitiveness would have deleterious effect. Could the result be a fluke? He conducted another study, this one involving academic psychologists. The result was the same. He did two more studies, one involving male businessmen, measuring achievement by their salaries, and the other with 1300 male and female undergraduates, using grade point average as the attainment criterion. In both cases he again found a significant negative correlation between competitiveness and achievement.
...
But Helmreich did not stop there. As of 1985, he had conducted three more studies. The first compared the standardized achievement tests of fifth- and sixth-graders to their competitiveness. They were negatively correlated. The second examined the relationship between performance of airline pilots and competitiveness. The relationship between the latter and superior performance was negative. The third looked at airline reservation agents and again found a negative correlation between performance and competitiveness.
...
Consider the question of artistic creativity. The little research that has been done suggests that competition is just as unhelpful here as it is in promoting creative problem-solving. In one study, seven- to eleven-year-old girls were asked to make "silly" collages, some competing for prizes and some not. Seven artists then independently rated their works on each of 23 dimensions. The result: "Those children who competed for prizes made collages that were significantly less creative than those made by children in the control group." Children in the competitive condition produced works thought to be less spontaneous, less complex, and less varied.
...
Consider journalism, a profession that, while no more competitive than many others, is worth exploring by virtue of its unusual visibility to outsiders. The frantic race for news generates terrific levels of anxiety ... on the part of journalists. Can we at least point to better reporting as the result of this competition? Setting reports against one another in a battle for space on the front page or the first block of a television news show probably lowers the quality of journalism in the long run, and so, too, does the contest among news organizations for subscriptions or ratings."
Thanks, Paul! I always enjoy reading your insigts. Some of the best free advice around. You might find that my companies design philosphy (for some reason...) is similiar to yours!
Your point about having a version 1 and iterating quickly based on real world input reminds me of my experience as a mechanical design engineer. The most costly mistakes made in that field resulted from too much design and not enough prototype phases. The typical design process back in the 80's was to meticulously draw every aspect of a component, send it to a machine shop for tooling, get manufactured parts and put them on the test stand. Only then would you discover that the gage was too light, the material was the wrong spec or the welds had to be moved.
I introduced the concept of prototype early and often. Actually re-introduced, as this is how most products were engineered in the olden days. Someone would suggest a new gage, weld placement, cross section, and I would don my overalls, head to the shop, cobble up something and demonstrate its feasibility before the draftsmen could decide what size paper to draw it on. When I worked at Chevrolet I took this to the max and prototyped entire vehicles years before the official prototype build phase.
When I transitioned to the world of networks and software I was shocked at how little prototyping there is. Website developers would deliver project plans that had two weeks of "QA" built in before the launch date. It was crazy, any major problem uncovered in that two weeks would delay the launch. It is still challenging to get a programmer to demonstrate a prototype early. So, I think you are on to something. Good luck with ARC!
You know PG, you can't discuss Arc beyond a point - the whole discussion gets trivial - not the content but just the fact that there have been so many discussions on the subject that one tends to skip or hurry through it.
I think the best response will be your continued work at Arc as opposed to a well written essay.
How does this mesh with "don't try to create trends, find and ride them"? That's advice I've heard a lot.
The final note about Reddit seems to say the opposite: "The Reddits pushed so hard against the current that they reversed it". That is probably incorrect. They found a local maxima in the trend for social news before others spotted it.
This doesn't really repudiate anything you say in the essay. But people shouldn't get the idea that just because there is resistance, they are doing something good. There needs to be a reason why the critics fail to see the light for you to claim you're working on an overlooked problem.
The trick here is that while you're working on it, you don't know if it something that needs to be solved.
How does this mesh with "don't try to create trends, find and ride them"?
You mean Joe Kraus's advice? That's advice for making money at something before your funding runs out. If burn rate is a factor, you may not be able to survive a contemptuous initial reaction, even if you're right.
Yes, I meant Joe Kraus's advice. It's interesting how I took it to mean something different than you did: a bad idea generally, not just if you don't have enough money for it.
I suppose you're right and I only found it general advice because it completely applies to my current state in life. Lots of people make that mistake: "this totally applies to me, it must be good advice generally"
After the first $10B, once I start working on a space elevator and robotic asteroid mining, I expect the luxury of a contemptuous initial reaction.
124 comments
[ 2.3 ms ] story [ 160 ms ] threadHere it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.
So when you look at something like Reddit and think "I wish I could think of an idea like that," remember: ideas like that are all around you. But you ignore them because they look wrong.
Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.
Perfect.
Hence the gnomes' predicament is solved.
After reddit, loopt, zenter, anywhere.fm, etc., however, I don't think I was completely accurate in my prediction....
I know there are a lot of people like this, but there is also a perhaps equally-large number of people who feel the opposite way. Personally, I love to be proven wrong when I predict failure, unless I have some other reason for wanting someone to fail (they use unethical practices, they're my direct competition, etc.).
I think this is really why you don't have to worry about competitors. If your idea is good enough, everyone will think you are crazy/naive. If your idea is simply decent, you'll never pick it anyway (because it's not exciting enough to you) and it will end up getting done by some existing company. Either way whatever you actually choose to work on will be unique until it's proven, by which point no competitor is catching you anyway.
It's not just about feeling. If Google had tanked, you would be more justified (in a statistical sense) to think that you're smart and to engage into more financial transaction.
For example, I was just over on programming.reddit.com. The majority of the comments on this essay are smearing Paul's character. If you went by that, everyone hates it.
Yet the essay has +115 points. So there are 115 people who liked the essay for each person who dislikes it. Where are their comments?
Which Feynman quotation is this referring to?
At least, that's my guess.
Market.
Viaweb and YC were each aimed at the overlooked low end of a market. Small businesses may not be sexy, but they had a pressing need for a web presence, and the can't write it themselves.. College students and young professionals may not be experienced, but they have a real need for money and advice, and they (usually) can't fund it themselves.
Arc, however, is explicitly aimed at the high end. It's meant to be a "LFSP". And smart people can write Arc themselves (and have ;-)). They don't need a new programming language; if they wanted one, they could invent it themselves.
Hence the contemptuous reaction, and why I think Arc is in more trouble than either Viaweb or YC. It's not really a problem when your peers are contemptuous, because that just means they're less likely to compete with you. It's a big problem when your users are contemptuous, because that means they don't need your project.
If I were in charge of Arc marketing, I'd position it as the "PHP for the ones that PHP forgot". PHP initially got its start as a way to throw a quick & dirty webapp prototype up on the web, and then incrementally refine it. But around version 5, it started getting complex and adding all these features from Java. That's left a vacuum at the bottom of the web language market. Rails and Django tried to fill it, but the average Django user is quite a bit more sophisticated than the average PHP user circa 1999. And Arc's design is already pretty well-suited to throwing a design up on the screen quickly.
Right now, the majority of Arc users seem to be disenchanted Lispers. Disenchanted Lispers tend to be smart people, and they also tend to be interested in language design. So instead of doing things with the language, they do things to the language. On arclanguage.com, I've seen one person write an app with the language, and several dozen people write enhancements of the language itself, either in the form of macros or as hacks to the interpreter itself.
Where is it, then? Where is the final, perfect Lisp that's so easy to write?
What you seem to be saying is that being smart automatically makes people good at language design. And you are just dead wrong. Being smart may make you a good language implementor, but there's little correlation between that and the kind of skills you need to be a good language designer. Some of the worst languages in the world were designed by smart people.
It's a big problem when your users are contemptuous, because that means they don't need your project.
The Arc users on arclanguage.org don't seem that contemptuous.
So instead of doing things with the language, they do things to the language.
That seems a good sign to me. Munging the language is what you do with Lisp, like numerical calculations are what you do with Fortran. So what this means to me is that the users are real Lisp hackers, using the language as Lisp is meant to be used.
Plus I explicitly said that at this stage I'm mostly interested in the core language, and that I want to hear new ideas in that department.
Maybe there isn't a final, perfect Lisp. Maybe there are lots of individual Lisps that are each perfect for some class of problems. That's one of the great strengths of Lisp: if an existing implementation is almost-but-not-quite what you need, you can throw a few macros on it and adapt it into a new language that is what you need.
It's one of the greatest weaknesses too: you don't see the same willingness to say "This is good enough; let's move on to more interesting problems" that you get with, say, Python/PIL or Ruby on Rails.
If you're going to create a new Lisp (and expect people to use it; creation for the sake of creation is another thing, and doesn't need justification), you've gotta answer why it's superior to throwing a few macros on top of an existing Scheme or CL implementation. After all, wouldn't an individual programmer know his specific problem better than you do? They don't have to worry about harmonizing a variety of concerns, because they don't have to worry about other people's concerns. They could just build the language that's best for their specific problem and keep it in their own private toolbox.
This is actually what causes that disparity between what people think of new technology when it first comes out and two years later, as long as it still exists: one party was busy developing, the other party was busy coming up with reasons it can't be done, getting pats on the back for being so smart, then riding that dopamine rush to nowhere fast for two years until they meet the product again and just say "oh, I was wrong." Then this cycle continues. That's what PG's essay is about.
But being unable or unwilling to argue semantics does not make the original poster's ideas wrong. The only way to prove a determined person wrong is to engage in direct competition, and from the rear, of course, as the other party is already ahead of you. For obvious reasons, it's easier and "smarter" to come up with "logical" reasons than to "do the full experiment" to show it's wrong. We're not talking about math equations here, so a productive person's potential is more than his writing but also his skills, experience, credibility, and dedication, which can't all be ignored.
If that were true, Scheme and CL wouldn't exist themselves. Everything you can do in those languages you could have done by writing a few macros on top of their predecessor, Maclisp.
What you seem to be saying is that the evolution of programming languages has now stopped. No one ever needs to make a new LFSP, because SPs can do whatever they need by writing macros on top of existing languages. Do you realize how unlikely this is, historically? Especially in a field like programming languages, which is at the moment in a period of ferment.
If you think CL is the last word in Lisp, you probably have a higher opinion of it than any of its designers. They were in the kitchen when it was being made, and they are all too aware of all the hacks and kludges that went into it.
I don't think a comma is required after 'it'.
I don't think Paul intended this to be a ground-breaking article. I doubht he's saying that those specific examples lead him to a certain process with a certain guaranteed successful result. In other words, he's not saying because a=b, and b=c, a=c. In that case, if you can disprove the examples, Paul's theories don't stand.
What I interpreted PG to say is that he has done things a certain way for a while, and has noticed correlation where people reject change time and time again, but that this is normal, and in fact, one of the steps in the process of innovation.
You need to 1) come up with a simple concept that benefits someone, especially yourself or someone you know who might care to look at it when it's ready (that you know you can do in a weekend even if it actually takes you a while) 2) promise to that person or anyone else besides you that you will release the software you promised 3) release the crappiest version you can that has the least features and is so unimpressive that it's stunning (esp. if you release before your deadline which gets you feedback sooner) 4) take criticism and make adjustments 5) come up with a system to make promises to do x by a certan date and a parallel system to make and measure forward progress towards any of the objectives 6) stick with it because people really love it when you've been so dedicated to a project 7) you're now an expert and have a lot of design and coding experience under your belt, as well as happy users who like that you're improving the app and listening to them.
Most people never get past step 1 or 2, even though at those steps you really don't have to do anything.
Oh, and step 8) you will learn what makes your body tick and become very efficient and feel like you're "improving exponentially" and 9) you will come up with ideas and insights that may make you sound insane, especially since you'll be so confident and focused you'll be blurting them out, but that 10) a year or two later will have been proven 100% true.
And yet that's what the market generally pays for.
Your list reminds me of Levchin's advice from http://venturebeat.com/2007/03/26/start-up-advice-for-entrep...
As a final word of product development advice, Levchin encouraged founders to think about the Bible’s seven deadly sins - especially greed, sloth, envy, pride and gluttony. These characteristics, he said, describe many of the primal motivations for users.
I have my own Scheme implementation (Gauche) and I live on writing software in it, and I keep trying new ideas with it. For that regards, I don't need Arc. But that kind of atmosphere at arclanguage.org, that's not something I can get without Arc.
Maybe most of the ideas tried there will turn out not to work, but new ideas need a place like there to come out. In a sense, Arc isn't a new programming language, but a medium that sheds a new light to the language design process.
And I'm watching it closely to steal whatever good ideas that come out :-)
I dunno. I could certainly be wrong - I was about Reddit. (Though I was also wrong about Xobni, and they did basically the opposite of everything PG suggests in this article.)
Maybe I'm just not the target market for Arc. I'd like to think I'm a smart person, and I did download it and play around with it and reimplement it. But right now, I'm finding that Python and JavaScript let me do more cool things, so I'd rather play around with them.
Ok, I am joking you may be right. But it is notoriously difficult to predict the market for programming languages. had you attended LL2 on [November 9, 2002](http://weblog.raganwald.com/2007/01/where-were-you-on-saturd...), could you have predicted which of the languages discussed would be popular... five years later?
That's exactly the question I wanted to ask! So is a significant portion of your time spent programming? Do YC startups measure this?
I find that if I code in a Blub language I spend 4 hours coding, but in a non Blub language I spend 2 hours thinking and 1 hour coding.
So according to your stats you get a 25% improvement in productivity by using non-Blub language (don't worry as you gain familiarity with non-Blub programming this will actually improve) and that means launching a month earlier.
The only reason to not use a non-Blub language is that you need to write in the Lowest Common Denominator of your team and if the entire team isn't comfortable in a specific language you'd better not use it.
The only exception to the above rule is if you separate your efforts in a very specific way, if instead of using the entire team to build project A, you use part of the team to build tools that help build projects like project A easily and the rest of the team uses the tools the other half created to actually build project A. In which case the tool building group can use more powerful languages without any adverse effects.
Companies tend to have much better luck if the language is attached to a product, either as a scripting language or as part of a RAD suite. Think of AutoCad/AutoLisp, Flash/ActionScript, or Visual Basic.
But for general-purpose languages, not so much.
It fits perfectly with your essay. Good write btw.
Evan is a great product designer. That's his secret weapon.
Jeffrey Rosen has some good stuff to say about this in his book The Unwanted Gaze. One of his defenses of the right to privacy is that new ideas often seem wrong at first, especially when they're still only half baked. And because of this, progress is seriously impeded when the government has the ability to go through our journals and sketchbooks at any time. This is especially true in our made-for-TV society where most people won't put more than thirty seconds into trying to understand something, esp. considering the factors PG mentions. He suggests that for these reasons innovation may not be possible in a fully transparent society.
I've put the book on my list.
- Albert Einstein
I know my reaction was similar to the crowd, but even so I recognize that it's the wrong thing to look for. If Arc's initial release state could be summed up as "Lisp with some cleaned-up and rearranged features," then it's really not that different from say, Digital Mars D, which is best described as "C++ with some cleaned-up and rearranged features." The difference is, D has a massive compiler backing it, and its scope is unlikely to change. Arc's minimal implementation substance only makes it easier to change tack midway.
I've only gradually learned to restrain my sense of ego and take a similarly minimal approach with my own projects(indie games) - my newest process is to always start the final implementation with a text console interface. Besides encouraging better architecture in preparing for a later graphical interface, it's easier to debug the key elements this way than to have "stuff moving on the screen" at 30 or 60FPS and get frustrated figuring out which of those frames is the one where you're getting an error, let alone what routine is causing the problem.
btw, thanks PG, this essay has a very profound effect for me; makes me rethink some of the "ideas" I have and how I will approach them.
http://www.squeezedbooks.com/book/show/13/the-innovators-dil...
http://itc.conversationsnetwork.org/shows/detail135.html
For the most part, Lisp people will never like any modification to the language that changes their pure abstract computation engine into something that more people would want to use.
Behold, a Usenet post from 2000 on the notion of a "lispscript" that could compete with perl or awk:
http://perl.plover.com/yak/12views/samples/brief/why-lisp-wi...
That said, I personally have no idea if Arc is all that good or not. I get it, but it doesn't inspire me the way Haskell or Erlang do right now. But Arc seems to be successful by the designer's own standards.
I'm still trying to get a handle on which of these apply to Arc. Perhaps I'm looking at it the wrong way, but Arc feels a little light in areas (a-c).
http://www.paulgraham.com/core.html
Try translating some Arc programs into Common Lisp or Scheme and you'll see what I mean.
And incidentally, I don't have to give hardened users of existing languages reason enough to switch. There are new people learning to program all the time, and to them, all languages are on a level playing field. If they look at Arc and CL and see that programs are 50% longer in CL, why would they choose CL?
a) Programs in "high level" languages can fail to be shorter than their lower-level equivalents. The simple solution: be merciless in keeping the important things short!
b) The overlooked problem in language design is high-level language brevity.
c) The "language design" problem that needs to be solved is... not sure about this one. I'm guessing it's the fact that the rate of change in the field is putting more programmers into the role of language designers at an increasing rate and anything that helps them avoid bad decisions based on ignorance is significant.
d) deliver informally as possible: when designing a new language, write enough to make the goals clear, address issues in a discussion group and put the code somewhere without sweating organizational details like setting up code repositories, bug tracking systems, regression frameworks, etc.
e) crude version 1: implement the minimal stuff using an existing system and don't worry about the fact that to the unaware it may seem just like a trivial program in that system.
f) iterate rapidly: don't get bogged down by things like release processes and backward compatibility. Just focus on getting feedback, experimenting, measuring and looking for improvements.
Taking the analogy to a house, Arc is like a half finished construction project. The frame is up, they're still putting insulation in, and there's one finished room with a cot, a table, and a hot plate which Paul Graham is using to cook the news.yc software. Sure, you might attract scads of interior decorators by opening your house up to random strangers, but very few programmers will be willing to come over to live in Arc. They'll stay in their own houses which are already well stocked with comfortable furniture, decorations, etc., even if it is all a little cluttered and you have to go through the kitchen in order to reach the library from the bedroom.
Some of the people speaking out against Arc are genuine trolls, but some are just saying in a non-tactful way that they'd prefer to stay in a house with drywall, thank you very much.
"Do Something Small But Useful Now"
which he also wrote as ((((DO SOMETHING!) SMALL) USEFUL) NOW!)
so that it became this sequence:
Do Something
Do Something Small
Do Something Small But Useful
Do Something Small But Useful Now
see http://www.trailing-edge.com/~bobbemer/ for more info
Of course, not everyone can easily copy the approach, you need to be an original thinker in order to not overlook overlooked problems.
I don't understand the last part of the essay about reddit as a classic example. "Tell people what was new", was that an overlooked problem? News agencies have been around for a long time. "Stay out of the way" was only possible because of the user-submission-and-voting system, which seems to me a clever and non-obvious idea. What I like most about this idea is the voting part, it tells me what's interesting, I don't care about whether it's new.
But, I'm coming to the tech world after having worked in the health care industry for 15 years. And, I studied art for 6-7 years, thinking that I could make a career out of it. So, I guess that I have a different perspective on the geek/hacker culture. And, something about hacker culture that never really set well with me was this--the nastiness.
Paul referenced it in his article, referring to the trolls. I just don't understand why people troll like they do. I didn't understand why people were so up in arms about Paul's trying to write a new language and offer it up for public consumption. I don't understand why people have been so quick to criticize Y Combinator. I don't understand the hating that goes on in language flame wars, or OS flame wars.
I understand that people are passionate about technology, and passionate about their language of choice, or OS of choice, but... really. Do people really need to get nasty about it? Why aren't people able to have a discussion about the merits of a language, or strengths and weaknesses without getting personal or mean about it. I just don't understand.
A great doctor that I worked with, was explaining to me why he got out of teaching at a medical school. What he said struck a chord with me: The reason that there's so much back-biting and politicking in academic medicine is very simple--it's because the stakes are so low.
Which leads me to ask the question--Are the stakes really so low in the technology world, that people are so nasty? I have a hunch that for many trolls, that's really true.
I know that shortly after reddit got purchased the trolls made camp and set up a small troll swamp. There are a few cool sub-reddits, though. Why did that happen? Because the stakes became so low.
We hackers are just dying to let others know how smart we are. It's what makes us tick.
So we come here (and other forums and blogs) because most of us have trouble finding peers who even understand what we're talking about. Add in a lack of writing style and the anonymity of the internet, and our puffing and strutting APPEARS to be nastiness.
Put us in a room together to discuss the same subjects and I'm sure it would be much more civil.
Honestly ask yourself. Whenever you heard someone else getting a compliment for being smart, (Alan made the Dean's list!), (Joe is a great chess player!), (Fred wrote the best program I ever saw!), don't you get JUST A LITTLE BIT JEALOUS. You almost want to scream out, "Hey! What about me? I'm smarter than that!" We hold back in person because we're polite. But we don't hold back here, because most of us understand. Sometimes I think that if you DON'T think like that, maybe you shouldn't be a hacker.
Reminds me of an old story that Rabbi Harold Kushner told about a young man trying to temper his competitiveness, so he joined an ashram in Japan. He wrote to his father, "Dad, this environment has helped me evolve to the point of enlightenment where I no longer have to compete with others to achieve my bliss. The meditation has done it. I'm one of the top 5 meditators here, and hopefully, by next year, I'll be Number One."
[UPDATE: I just read the comments about this pg essay on Reddit, and realize that it's different over there. They ARE nasty. What's happened to Reddit? Whatever it is, I sure hope it never happens here.]
My experience is that this is a limitation of communication without subtext, inflection, etc. I don't have a whole lot of time right now for details, but I have noticed a few tendencies that exacerbate emotions in online discussions:
- Deprecating humor seems especially biting without the wink and smile, and the inevitable response from others then appears like an attack
- Posters lump all critics together, and tend to forget who made which argument (but are especially sensitive to having their points glossed over, misinterpreted)
- Often those within technical circles don't realize that different people weigh evidence differently (i.e., two parties may reach separate conclusions simply because they have differing views of which facts are important). Unlike in the math world, discussions and conclusions cannot be reduced to a few simple axioms--there's always the experience of the observer necessary to interpret data.
- There's a tendency to skim critics posts and respond to individual sentences/words (rather than the sum of what was actually written).
I also don't get a really nasty vibe from Hacker news, like I do on Reddit. I was referring to the Hacker culture at large when I was referring to "nastiness". I believe that there is a lot of bravado and competition in Geek culture. But there's also a lot of nastiness, too. In fact, we are developing the English language by devising new language for people being assholes online: griefing, trolling, powning, flames, flamewars, Greater Fuckwad Theory, Godwin's law, STFU, RTFM, STFW, etc... It's only a matter of time before these terms hit the mainstream to describe asshole behavior offline.
Even though he doesn't say it, I believe that Paul has been rather hurt about this often enough several of his last essays have referred to these people as "trolls". Steve Yegge has had enough problems with this, that he's turned comments off on most of his blogs. Pmarca also thinks that this is enough of a problem, that he (to my knowledge) never turned on comments on his blog.
For instance, I went to a boarding school for a year, and was in a dorm with 45 high school boys. There's friendly competition, and then there's getting 64 wedgies like I did that year. (I was the youngest kid in the school, and quite a nerd). A lot of time, putting your work into the intarweeb slipstream of geek/hacker culture is like walking around with your fruit-o-the-looms sticking 2 inches outside of your pants at a boarding school. It's only a matter of time before some asshole gives you a wedgy. And, then you have brown streaks.
My question is this: why do we (not Hacker News, but Geek culture in general) tolerate that behaviour? There is no need for it. If you want to prove how smart you are, make something cool. Or, explain String theory in a way that mere mortals can understand. But, walking around saying that Arc sux because of this and that, or Yegge is a wind bag, or what was J Gosling thinking when he designed the turd that Java is... This isn't productive.
If people make these comments maybe it's because their stakes are so low.
On a tangent, is competition necessary or even beneficial for progress? The world today seems to be founded on this idea, but things would be much different if people didn't believe competition was important. Competition makes products ego based, and I don't think ego based products are the best. People have to aim beyond themselves and the felt needs of others to make something truly excellent.
Paul probably only visits Reddit to read comments about something he's done. I left the chatroom #lisp because of the assholicism. (Leaving was an excellent decision. Everything about Lisp can be learned from CLHS, SICP, On Lisp, gigamonkeys.com/book, other books, and Google. It takes patience, but you'll learn far more than by asking someone.)
Communities are a source of power - if you've built a strong one, you can usually get rich. But they require huge amounts of time. Unless you're working toward a specific goal, it seems best to be a lone wolf (or part of a small team) and to operate without considering what everyone else has to say, or to offer you.
I learned to program almost exclusively by asking people and experimenting. It was a mistake to ask people how to do things. You can learn orders of magnitude faster by reading manuals and books than by trying to get someone to help you. Hacker culture isn't necessary, except to feel good about yourself, which isn't necessary. John Carmack knows so much because he spent most of his time in quiet isolation, meditating on problems, not hanging around communities.
It's the anonymity. Combined with a 95% male audience. If each reddit commenter had to sign with his full name, and his picture would be shown next to his comments, the tone would be quite different.
"University politics are vicious precisely because the stakes are so small."
http://www.quotedb.com/quotes/1477
As for why trolls exist at all, I think it is because it is so darned easy to be rude and generally small-minded and full of self-puffery when the troll has such near-anonymity and therefore no sense of responsibility. I also think that geek communication tends to be brief, and it is easy to be rude with a few short direct words... in the real world, such behaviour is not tolerated but in forums, the troll can just keep posting, and posting, and posting.
As readers, we also absorb rudeness better, and remember the smallest slights, whereas we skip over the fluffy bunny comments where someone chips in with a happy "me too!" or "hug" and a row of smiley faces.
Andrew.
What it boils down to is reputation. Trolls seek only to reduce the reputation of his victim.
People have been wondering about that since he was a small child.
I'd like some help interpreting this sentence.
Why does the lack of competition make it more likely you'll discover new things? (And what is things referring to?)
I assume it means you can attack a problem at a more leisurely pace, so you see solutions you would have missed if you were in a feature-copying war with competitors. But I doubt PG would advocate running your startup leisurely.
"Robert L. Helmreich [tested] the relationship between achievement, on the one hand, and such traits as the orientation toward work, mastery (preference for challenging tasks), and competitiveness, on the other. A sample of 103 Ph.D. scientists were rated on these three factors based on a questionnaire. Achievement, meanwhile, was defined in terms of the number of times their work was cited by colleagues. The result was that "the most citations were obtained by those high on the work and mastery but low on the competitiveness scale."
This startled Helmreich, who did not expect that competitiveness would have deleterious effect. Could the result be a fluke? He conducted another study, this one involving academic psychologists. The result was the same. He did two more studies, one involving male businessmen, measuring achievement by their salaries, and the other with 1300 male and female undergraduates, using grade point average as the attainment criterion. In both cases he again found a significant negative correlation between competitiveness and achievement.
...
But Helmreich did not stop there. As of 1985, he had conducted three more studies. The first compared the standardized achievement tests of fifth- and sixth-graders to their competitiveness. They were negatively correlated. The second examined the relationship between performance of airline pilots and competitiveness. The relationship between the latter and superior performance was negative. The third looked at airline reservation agents and again found a negative correlation between performance and competitiveness.
...
Consider the question of artistic creativity. The little research that has been done suggests that competition is just as unhelpful here as it is in promoting creative problem-solving. In one study, seven- to eleven-year-old girls were asked to make "silly" collages, some competing for prizes and some not. Seven artists then independently rated their works on each of 23 dimensions. The result: "Those children who competed for prizes made collages that were significantly less creative than those made by children in the control group." Children in the competitive condition produced works thought to be less spontaneous, less complex, and less varied.
...
Consider journalism, a profession that, while no more competitive than many others, is worth exploring by virtue of its unusual visibility to outsiders. The frantic race for news generates terrific levels of anxiety ... on the part of journalists. Can we at least point to better reporting as the result of this competition? Setting reports against one another in a battle for space on the front page or the first block of a television news show probably lowers the quality of journalism in the long run, and so, too, does the contest among news organizations for subscriptions or ratings."
Because if few are looking where you're looking, there's more chance that things you discover will be new.
By things I mean pretty much anything that could be the object of "discover", from mathematical concepts to narrative techniques.
www.ensigntech.com
I introduced the concept of prototype early and often. Actually re-introduced, as this is how most products were engineered in the olden days. Someone would suggest a new gage, weld placement, cross section, and I would don my overalls, head to the shop, cobble up something and demonstrate its feasibility before the draftsmen could decide what size paper to draw it on. When I worked at Chevrolet I took this to the max and prototyped entire vehicles years before the official prototype build phase.
When I transitioned to the world of networks and software I was shocked at how little prototyping there is. Website developers would deliver project plans that had two weeks of "QA" built in before the launch date. It was crazy, any major problem uncovered in that two weeks would delay the launch. It is still challenging to get a programmer to demonstrate a prototype early. So, I think you are on to something. Good luck with ARC!
I think the best response will be your continued work at Arc as opposed to a well written essay.
The final note about Reddit seems to say the opposite: "The Reddits pushed so hard against the current that they reversed it". That is probably incorrect. They found a local maxima in the trend for social news before others spotted it.
This doesn't really repudiate anything you say in the essay. But people shouldn't get the idea that just because there is resistance, they are doing something good. There needs to be a reason why the critics fail to see the light for you to claim you're working on an overlooked problem.
The trick here is that while you're working on it, you don't know if it something that needs to be solved.
You mean Joe Kraus's advice? That's advice for making money at something before your funding runs out. If burn rate is a factor, you may not be able to survive a contemptuous initial reaction, even if you're right.
I suppose you're right and I only found it general advice because it completely applies to my current state in life. Lots of people make that mistake: "this totally applies to me, it must be good advice generally"
After the first $10B, once I start working on a space elevator and robotic asteroid mining, I expect the luxury of a contemptuous initial reaction.