Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Paul Graham: Six Principles for Making New Things

paulgraham.com

Post reply on HN
Print view View original

91–100 of 125 posts

Re: Paul Graham: Six Principles for Making New Things

#91

Post by marcus »

jules wrote: post #88
pg wrote: post #77

Earlier quoted context omitted.

The only way I can think of would be to keep it secret and write applications in 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???

Re: Paul Graham: Six Principles for Making New Things

#92

Post by blahblah »

I like Arc, but there's just no way that it follows the six principles laid out here.

(a) simple solution - yes

(b) to overlooked problem - no. It's just a personal spin on Lisp/Scheme. It covers exactly the same territory.

(c) that actually needs to be solved - no. Programmers have many good languages to choose from. Arc is a nice little wrapper on top of Lisp to make it pretty, but any undergrad could do the same thing.

(d) deliver them as informally as possible - no. You don't write long essays about a language 5+ years before you show a prototype if "informality" is your goal.

(e) starting with a very crude version - yes

(f) iterating rapidly - no. You could get a master's degree in computer science in the time it took for the minimal prototype of Arc to show up.

Re: Paul Graham: Six Principles for Making New Things

#93

Post by konsl »

This is an interesting take on (b) overlooked problems:

A few years ago, Gary Hamel and colleagues analyzed more than a hundred cases of business innovation to learn why some individuals, at certain points in time, are able to see opportunities that are invisible to everyone else. They learned that you need to pay close attention to four things that usually go unnoticed:

1. Unchallenged orthodoxies—the widely held industry beliefs that blind incumbents to new opportunities.

2. Underleveraged competencies—the “invisible” assets and competencies, locked up in moribund businesses, that can be repurposed as new growth platforms.

3. Underappreciated trends—the nascent discontinuities that can be harnessed to reinvigorate old business models and create new ones.

4. Unarticulated needs—the frustrations and inconveniences that customers take for granted, and industry stalwarts have thus far failed to address.

original @ http://discussionleader.hbsp.com/hamel/2008/01/innovation_ha...)

Re: Paul Graham: Six Principles for Making New Things

#94

Post by jules »

marcus wrote: post #91
jules wrote: post #88

Earlier quoted context omitted.

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???

> Assuming that a significant portion of your time in a software startup is spent programming

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.

Re: Paul Graham: Six Principles for Making New Things

#95

Post by Mistone »

the crux of the essay is the process Paul refers to(steps a-e). This model gives me great confidence that we are on the right track, and while we were not able to launch as fast as we would have liked we still see the basic unsolved, overlooked, problem that inspired us to begin.

At the same taime its what annoyed me about being passed up last funding round, if this is how they judged ideas, how could they have glossed over us. Oh well, until we are a success they where correct.

@pg: thanks for the inspiration and clarity as always

Re: Paul Graham: Six Principles for Making New Things

#96

Post by electric »

pg wrote: post #17
nostrademons wrote: post #10

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…

"Where is it, then?"

I don't think a comma is required after 'it'.

Re: Paul Graham: Six Principles for Making New Things

#97

Post by jacabado »

pg wrote: post #21
jacabado wrote: post #13

Is it just me or Twitter fits perfectly in that definition?

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.

Re: Paul Graham: Six Principles for Making New Things

#98

Post by skmurphy »

konsl wrote: post #93

This is an interesting take on (b) overlooked problems: A few years ago, Gary Hamel and colleagues analyzed more than a hundred cases of business innovation to learn why some individuals, at certain points in time, are able to see opportunities that are invisible to everyone else. They learned that you need to pay close attention to four things that usually go unnoticed: 1. Unchallenged orthodoxies—the widely held in…

This is a great list and nicely expands "(b) overlooked problems." In his book "Innovation and Entrepreneurship" Peter Drucker offered the following observation on the frame of mind need to spot opportunities for innovation.

"Innovation requires us to systematically identify changes that have already occurred but whose full effects have not yet been felt, and then to look at them as opportunities. It also requires existing companies to abandon rather than defend yesterday."

He goes on to suggest seven places to search systematically for opportunities

  The Unexpected
  The Incongruous
  Weak Link In Existing Process
  Industry Or Market Structure Change
  Demographics: Size, Age Structure
  New Zeitgeist: Perception, Mood, Meaning
  New Knowledge

Re: Paul Graham: Six Principles for Making New Things

#99

Post by marcus »

jules wrote: post #94
marcus wrote: post #91

Earlier quoted context omitted.

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???

> Assuming that a significant portion of your time in a software startup is spent programming 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.

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.

Re: Paul Graham: Six Principles for Making New Things

#100

Post by wumi »

iamelgringo wrote: post #44

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 referen…

the takes are very small in all academia
Post reply on HN