21–30 of 125 posts
Is it just me or Twitter fits perfectly in that definition?
Evan is a great product designer. That's his secret weapon.
- 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.
Earlier quoted context omitted.
I'd add the closing paragraph to this as well: 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. Perfect.
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 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 (usua…
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.
"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 seriousl…
I've put the book on my list.
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.,…
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 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.
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 (usua…
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 skil…
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.