See also:
Article from Paul Graham is in italics. My comments are in regular text.
August 2004
Paul: In a recent talk I said something that upset a lot of people: that you could get smarter programmers to work on a Python project than you could to work on a Java project.
L505: That's a dumb generalization! You knew you would get flamed. Look at yourself in the mirror. Don't make dumb generalizations and you won't get a dumb response. Again, look at yourself in the mirror before asking a question or making a statement.
Paul: I didn't mean by this that Java programmers are dumb. I meant that Python programmers are smart.
L505: Are you trying to be funny, Paul? It's not funny.
Paul: It's a lot of work to learn a new programming language.
L505: No doubt?
Paul: And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.
L505: True - Modern Pascal is in a similar situation. Modern Pascal has a horrible job market compared to C/C++/Java/PHP. However, followers are employees while leaders are employers. I say go out and create jobs for the Pascal (or python) market if you have something to offer. This is what google is doing by requiring python skills for their jobs. This is what Z505 plans to do when we offer jobs to Pascal folks. It's all about someone being brave and creating a job market instead of whining and looking for a job market. Employers are leaders and employees are followers.
Paul: Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job.
L505: I agree that those folks are brave if they are willing to learn a language like Python/Pascal/Haskell which have a small job market. But they also risk going on welfare and being poor for several years. I'm okay with that - but many folks can't take it. It could even cost you your life if you don't have money to pay for food.
Paul: Only a few companies have been smart enough to realize this so far. But there is a kind of selection going on here too: they're exactly the companies programmers would most like to work for. Google, for example. When they advertise Java programming jobs, they also want Python experience.
Paul: A friend of mine who knows nearly all the widely used languages uses Python for most of his projects. He says the main reason is that he likes the way source code looks. That may seem a frivolous reason to choose one language over another. But it is not so frivolous as it sounds: when you program, you spend more time reading code than writing it. You push blobs of source code around the way a sculptor does blobs of clay. So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor.
Paul: At the mention of ugly source code, people will of course think of Perl.
L505: Funny, another one that comes to mind is Lisp, Paul. As Larry Wall reminds us that Lisp is Oatmeal with fingernail clippings mixed in.
Paul: But the superficial ugliness of Perl is not the sort I mean. Real ugliness is not harsh-looking syntax, but having to build programs out of the wrong concepts. Perl may look like a cartoon character swearing, but there are cases where it surpasses Python conceptually.
Paul: So far, anyway. Both languages are of course moving targets. But they share, along with Ruby (and Icon, and Joy, and J, and Lisp, and Smalltalk) the fact that they're created by, and used by, people who really care about programming. And those tend to be the ones who do it well.
L505: All languages are created by people who care about programming. I don't think I know of one language that was created by someone who didn't care about programming?
Paul: It's hard to predict what life will be like in a hundred years. There are only a few things we can say with certainty. We know that everyone will drive flying cars, that zoning laws will be relaxed to allow buildings hundreds of stories tall, that it will be dark most of the time, and that women will all be trained in the martial arts. Here I want to zoom in on one detail of this picture. What kind of programming language will they use to write the software controlling those flying cars?
L505: most likely a language that can be embedded on to a chip. The D language (Digital Mars), ADA, other derivatives of the C++/C language, or other compiled languages like Modern Pascal come to mind. Since D is not very popular right now it will take 50 years for it to become popular. Maybe in a hundred years there will be a D Plus language that mainstream is using for embedded programming.
But Paul, the flying car will not be running Python, Perl, or Lisp. Those languages are not structured, standardized, safe, or embeddable enough like certain compiled languages are. If what you were trying to get at Paul, was that your flying car was going to be run from an interpretted Lisp or Python program (since those are the languages you seem to like), I can tell you that that's not going to happen.
Could a programming language go so far as to get rid of numbers as a fundamental data type? I ask this not so much as a serious question as as a way to play chicken with the future. It's like the hypothetical case of an irresistible force meeting an immovable object-- here, an unimaginably inefficient implementation meeting unimaginably great resources. I don't see why not. The future is pretty long. If there's something we can do to decrease the number of axioms in the core language, that would seem to be the side to bet on as t approaches infinity. If the idea still seems unbearable in a hundred years, maybe it won't in a thousand.
Just to be clear about this, I'm not proposing that all numerical calculations would actually be carried out using lists. I'm proposing that the core language, prior to any additional notations about implementation, be defined this way. In practice any program that wanted to do any amount of math would probably represent numbers in binary, but this would be an optimization, not part of the core language semantics.
L505: Huh? Numbers are useful in even simple situations such as a shopping cart. Adding two dollar values requires a data type such as an integer or a dollar data type. Number data types are useful. We won't be getting rid of those, Paul. What may be introduced into programming languages are data types that are more specific, such as a DOLLAR data type. not just an integer data type, but a very specific dollar data type. Or a meter data type. Or a kilometer data type.
Yes, Paul, we still require specific data types - life is not as simple as jamming everything to a list and calling it a day. Boxes are different than eggs for a reason. You can fit eggs into a box but you don't neccessarily want to use the egg as a box. An egg makes a terrible box. This is why we have data types. You don't always want a string to be an integer - only some times you want this.
I guess what you are getting at Paul, is that Lisp or languages of the future that reduce the number of data types will solve all the world's problems and everyone should be using it because it is so simple and has so few axioms. Uh huh. Your suggestion that we cut out more and more axioms is like saying we should cut out more of the alphabit, or that we should use this SIMPLE language here: http://en.wikipedia.org/wiki/Brainfuck
The problem with overly simplified languages with few data types and few axioms is that they are basically unreadable and unspecific. Having a specific DOLLAR type, KILOMETER type, INTEGER type is very important for the future. Want to calculate the amount of fuel to inject into your engine that powers your flying car? Make a LITRE and MILLILITRE data type. Don't just use integers - use a more specific data type. The future of programming is not about deleting and ignoring the data type. Flying cars require precise calculations - precise calculations require data types. Precise calculations require a language less prone to error - a typeless language with no MILLILITRE data type will not produce a very effecient flying car.
Flying cars will need to be run off small amounts of fuel. Fuel is becoming harder to find and more expensive to produce. Effecient languages (not Lisp, or Python) are going to be needed to power your flying car, Paul. Embedded languages, Paul.
|
