Paul Graham's Quotes

Paul Graham's Quotes wiki, Paul Graham's Quotes history, Paul Graham's Quotes review, Paul Graham's Quotes facts Paul Graham's Quotes news, what is Paul Graham's Quotes Paul Graham's Quotes wikipedia
Paul Graham's Quotes information, Paul Graham's Quotes definition, Paul Graham's Quotes timeline, Paul Graham's Quotes location

The following is a list of quotes by Paul Graham. Graham (born 13 November 1964) is an English computer scientist, venture capitalist, technology entrepreneur and essayist.


Quotes


If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.

  • Beating the Averages , paulgraham.com, April 2001, rev. April 2003 [1]


Everyone knows it's a mistake to write your whole program by hand in machine language. What's less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one.

  • Beating the Averages , paulgraham.com, April 2001, rev. April 2003[1]


By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one.

  • Beating the Averages , paulgraham.com, April 2001, rev. April 2003[1]


It's the nature of programming languages to make most people satisfied with whatever they currently use. Computer hardware changes so much faster than personal habits that programming practice is usually ten to twenty years behind the processor.

  • Beating the Averages , paulgraham.com, April 2001, rev. April 2003[1]


Ordinarily technology changes fast. But programming languages are different: programming languages are not just technology, but what programmers think in. They're half technology and half religion.

  • Beating the Averages , paulgraham.com, April 2001, rev. April 2003[1]


Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.

  • Java's Cover, paulgraham.com, April 2001[1]


The best programming languages have been developed by small groups. Java seems to be run by a committee. If it turns out to be a good language, it will be the first time in history that a committee has designed a good language.

  • Java's Cover, paulgraham.com, April 2001[1]


Historically, languages designed for large organizations (PL/I, Ada) have lost, while hacker languages (C, Perl) have won. The reason: today's teenage hacker is tomorrow's CTO.

  • Java's Cover, paulgraham.com, April 2001[1]


It may seem cavalier to dismiss a language before you've even tried writing programs in it. But this is something all programmers have to do. There are too many technologies out there to learn them all. You have to learn to judge by outward signs which will be worth your time.

  • Java's Cover, paulgraham.com, April 2001[1]


Programming languages are for hackers, and a programming language is good as a programming language (rather than, say, an exercise in denotational semantics or compiler design) if and only if hackers like it.

  • Being Popular, paulgraham.com, May 2001[1]


Given an initial critical mass and enough time, a programming language probably becomes about as popular as it deserves to be. And popularity further separates good languages from bad ones, because feedback from real live users always leads to improvements.

  • Being Popular, paulgraham.com, May 2001[1]


So whether or not a language has to be good to be popular, I think a language has to be popular to be good. And it has to stay popular to stay good. The state of the art in programming languages doesn't stand still. And yet the Lisps we have today are still pretty much what they had at MIT in the mid-1980s, because that's the last time Lisp had a sufficiently large and demanding user base.

  • Being Popular, paulgraham.com, May 2001[1]


To become popular, a programming language has to be the scripting language of a popular system.

  • Being Popular, paulgraham.com, May 2001[1]


Brevity is one place where strongly typed languages lose. All other things being equal, no one wants to begin a program with a bunch of declarations. Anything that can be implicit, should be.

  • Being Popular, paulgraham.com, May 2001[1]


The latest hot language, Python, is a watered-down Lisp with infix syntax and no macros. A new Lisp would be a natural step in this progression.

  • Being Popular, paulgraham.com, May 2001[1]


Given an initial critical mass and enough time, a programming language probably becomes about as popular as it deserves to be. And popularity further separates good languages from bad ones, because feedback from real live users always leads to improvements.

  • Being Popular, paulgraham.com, May 2001[1]


To developers, the most conspicuous difference between Web-based and desktop software is that a Web-based application is not a single piece of code. It will be a collection of programs of different types rather than a single big binary. And so designing Web-based software is like desiging a city rather than a building: as well as buildings you need roads, street signs, utilities, police and fire departments, and plans for both growth and various kinds of disasters.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


... hardware is not just something to worry about. When you control it you can do more for users. With a desktop application, you can specify certain minimum hardware, but you can't add more. If you administer the servers, you can in one step enable all your users to page people, or send faxes, or send commands by phone, or process credit cards, etc, just by installing the relevant hardware.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


With server-based software, no one can tell you what language to use, because you control the whole system, right down to the hardware. Different languages are good for different tasks.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


Software companies are sometimes accused of letting the users debug their software. And that is just what I'm advocating. For Web-based software it's actually a good plan, because the bugs are fewer and transient.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


Plans are just another word for ideas on the shelf.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


... paying attention is more important to reliability than moving slowly. Because he pays close attention, a Navy pilot can land a 40,000 lb. aircraft at 140 miles per hour on a pitching carrier deck, at night, more safely than the average teenager can cut a bagel.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


Some amount of piracy is to the advantage of software companies. If some user really would not have bought your software at any price, you haven't lost anything if he uses a pirated copy. In fact you gain, because he is one more user helping to make your software the standard-- or who might buy a copy later, when he graduates from high school.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


Piracy is effectively the lowest tier of price discrimination. I think that software companies understand this and deliberately turn a blind eye to some kinds of piracy. With server-based software they are going to have to come up with some other solution.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


Sometimes Web-based software is offered through ISPs acting as resellers. This is a bad idea. You have to be administering the servers, because you need to be constantly improving both hardware and software.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


There is always a tendency for rich customers to buy expensive solutions, even when cheap solutions are better, because the people offering expensive solutions can spend more to sell them.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


A large part of what big companies pay extra for is the cost of selling expensive things to them.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


Running software on the server is nothing new. In fact it's the old model: mainframe applications are all server-based.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


Why did desktop computers take over? I think it was because they had better software. And I think the reason microcomputer software was better was that it could be written by small companies.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


Desktop software forces users to become system administrators. Web-based software forces programmers to. There is less stress in total, but more for the programmers.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


What's scary about Microsoft is that a company so big can develop software at all. They're like a mountain that can walk.

  • The Other Road Ahead, paulgraham.com, September 2001[1]


23. More open alternatives to Wikipedia. Deletionists rule Wikipedia. Ironically, they're constrained by print-era thinking. What harm does it do if an online reference has a long tail of articles that are only interesting to a few people, so long as everyone can still find whatever they're looking for? There is room to do to Wikipedia what Wikipedia did to Britannica.

  • Startup Ideas We'd Like to Fund, Y Combinator Blog, July 2008 [3]



All information for Paul Graham's Quotes's wiki comes from the below links. Any source is valid, including Twitter, Facebook, Instagram, and LinkedIn. Pictures, videos, biodata, and files relating to Paul Graham's Quotes are also acceptable encyclopedic sources.
Other wiki pages related to Paul Graham's Quotes.
QmNQ3rh8EAzbjbFDQgyzxTHi4Jv7YAezL96G4tXBVmjZK9