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

61–70 of 125 posts

Re: Paul Graham: Six Principles for Making New Things

#61

Post by stener »

raganwald wrote: post #45
stener wrote: post #41

Earlier quoted context omitted.

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.

Re: Paul Graham: Six Principles for Making New Things

#62

Post by netman21 »

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!

Re: Paul Graham: Six Principles for Making New Things

#63

Post by pg »

nostrademons wrote: post #30
pg wrote: post #17

Earlier quoted context omitted.

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

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.

Re: Paul Graham: Six Principles for Making New Things

#64

Post by kashif »

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.

Re: Paul Graham: Six Principles for Making New Things

#65

Post by pg »

serhei wrote: post #58
pg wrote: post #52

Earlier quoted context omitted.

Arc is a simple solution to the overlooked problem of core language design. http://www.paulgraham.com/core.html

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…

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?

Re: Paul Graham: Six Principles for Making New Things

#67

Post by ivankirigin »

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.

Re: Paul Graham: Six Principles for Making New Things

#68

Post by yters »

iamelgringo wrote: post #54
edw519 wrote: post #46

Earlier quoted context omitted.

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

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

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.

Re: Paul Graham: Six Principles for Making New Things

#69

Post by palish »

iamelgringo wrote: post #54
edw519 wrote: post #46

Earlier quoted context omitted.

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

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

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.

Post reply on HN