Design(paulgraham.com)
paulgraham.com
Design
http://paulgraham.com/design.html#hn
117 comments
> C is a ridiculously good language, smalltalk and lisp? They've always struck me as pretty specialist.
It's funny because my impression is completely the opposite: C is a very specialist language suitable for a narrow domain of low-level code. For everything else, it's just begging for rampant bugs and security issues.
On the other hand, Lisp and Smalltalk (well, maybe just Lisp--I am not really familiar with Smalltalk) are very general-purpose languages. You could reasonably use them for all sorts of tasks. And you would avoid whole classes of bugs common in C.
Just because many people didn't use them doesn't mean the languages weren't well-suited. Sure, they were never populist langauges, but that's ultimately of little consequence. Especially for "hackers".
It's funny because my impression is completely the opposite: C is a very specialist language suitable for a narrow domain of low-level code. For everything else, it's just begging for rampant bugs and security issues.
On the other hand, Lisp and Smalltalk (well, maybe just Lisp--I am not really familiar with Smalltalk) are very general-purpose languages. You could reasonably use them for all sorts of tasks. And you would avoid whole classes of bugs common in C.
Just because many people didn't use them doesn't mean the languages weren't well-suited. Sure, they were never populist langauges, but that's ultimately of little consequence. Especially for "hackers".
By specialist I mean "big learning curve". I tried learning Lisp once and felt that it was an obviously powerful language, but there were easier languages to learn that would do as good a job for general purpose needs.
Well, I can't speak much for Common Lisp, but you couldn't be much more wrong for Scheme--Scheme is easily one of the easiest language to learn, full stop. The intro CS course at my university used to be taught in Scheme and people with literally no programming experience could get the hang of most of the language in the first couple of weeks.
The only reason some people view it as difficult is that it is very different from the C-like languages they're already familiar with. Once you've learned one of those, the others are, of course, very easy to pick up. Not because the languages themselves are simple but because they're similar. Scheme, by comparison, has a very different--and much more regular--syntax and very different ways of doing things.
Besides, C is relatively difficult to learn: there are a whole bunch of low-level concepts (pointer arithmetic), a large amount of syntax and a ton of edge cases and undefined behavior. Not to mention the preprocessor. It takes much more effort to get even a basic result with C than it does with another language like Scheme.
The only reason some people view it as difficult is that it is very different from the C-like languages they're already familiar with. Once you've learned one of those, the others are, of course, very easy to pick up. Not because the languages themselves are simple but because they're similar. Scheme, by comparison, has a very different--and much more regular--syntax and very different ways of doing things.
Besides, C is relatively difficult to learn: there are a whole bunch of low-level concepts (pointer arithmetic), a large amount of syntax and a ton of edge cases and undefined behavior. Not to mention the preprocessor. It takes much more effort to get even a basic result with C than it does with another language like Scheme.
What is difficult about programming in Lisps is the same thing that is difficult about driving 911's - doing so in the manner that experts do requires a radically different mindset. If you've seen 911's slinging oversteer around a road course and schemers...well writing scheme - it's apparent that neither thinks about driving or programming like the people against whom they are competing.
What was hard about learning Lisp? And which Lisp?
"Please don’t assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list."
– Kent Pitman
– Kent Pitman
(2 time and current 911 Owner here)
"Porsche have spent years keeping the brand and style consistent. It was expensive and exclusive, which made it desirable."
True. Would add that the seeds were planted for me to want one of these many years ago.
"But that care (sic) was very hard to drive."
Also true even with the current model. I also owned a mini cooper s a few years ago and that was much easier and actually much more fun to drive.
"These were not always people who could get the true performance out of the car."
Having a car that goes from zero to 60 so quickly and corners so well doesn't have much utility unless you happen to live near a race track or in the country where there are winding roads and limited police presence. Acceleration of 0 to 60 in, say, 4 seconds when you take away the amount of time to get up to the point on the power curve where the fun starts give you about 1.5 seconds of thrill. Before you know it you are at 70mph on a 40mph road and have to slow down.
"But if I had to pick a car that was most likely to be reliable today then the Cad is an obvious choice."
Especially if you have to cart around adults. The two rear seats in the 911 won't hold an adult.
What's interesting about your comment is that since I have no idea about Arc I would automatically assume that PG is right in what he says. Even though knowing about the 911 I can see your argument and know you have a point.
Add: I love the 911 but sometimes I wonder how much of that love is manufactured in my head. Actually I think a large portion of it is but I'm still happy. It's like trying to analyze why breasts are nice to look at. They just are.
"Porsche have spent years keeping the brand and style consistent. It was expensive and exclusive, which made it desirable."
True. Would add that the seeds were planted for me to want one of these many years ago.
"But that care (sic) was very hard to drive."
Also true even with the current model. I also owned a mini cooper s a few years ago and that was much easier and actually much more fun to drive.
"These were not always people who could get the true performance out of the car."
Having a car that goes from zero to 60 so quickly and corners so well doesn't have much utility unless you happen to live near a race track or in the country where there are winding roads and limited police presence. Acceleration of 0 to 60 in, say, 4 seconds when you take away the amount of time to get up to the point on the power curve where the fun starts give you about 1.5 seconds of thrill. Before you know it you are at 70mph on a 40mph road and have to slow down.
"But if I had to pick a car that was most likely to be reliable today then the Cad is an obvious choice."
Especially if you have to cart around adults. The two rear seats in the 911 won't hold an adult.
What's interesting about your comment is that since I have no idea about Arc I would automatically assume that PG is right in what he says. Even though knowing about the 911 I can see your argument and know you have a point.
Add: I love the 911 but sometimes I wonder how much of that love is manufactured in my head. Actually I think a large portion of it is but I'm still happy. It's like trying to analyze why breasts are nice to look at. They just are.
Ive owned a 911; it's a brilliant car and one of my favourites that I've owned. :) And I agree with everything you've said.
One of my current cars is an MGF; I love it. It's unreliable, isn't very good at acceleration, can be a bitch to drive... but I still love it :)
Conversely; I have an old Peugot 106 which sits on the drive and never ever fails to start when I need it. It looks ugly as sin and can handle like a bull, but it does the job (getting from A to B) without fail due to superb engineering and subtle simplicity.
But maybe I'm getting carried away with the car metaphors...
One of my current cars is an MGF; I love it. It's unreliable, isn't very good at acceleration, can be a bitch to drive... but I still love it :)
Conversely; I have an old Peugot 106 which sits on the drive and never ever fails to start when I need it. It looks ugly as sin and can handle like a bull, but it does the job (getting from A to B) without fail due to superb engineering and subtle simplicity.
But maybe I'm getting carried away with the car metaphors...
> the country where there are winding roads and limited police presence
These areas usually aren't that far away, just ask your local motorcyclists where the fun roads are if you don't know the local spots.
I happen to live in one of those areas and drive some really fun roads on my weekly trip to and from SF, but I'm not that far from a bunch of people who live in a very different environment and almost don't seem to know our roads exist.
These areas usually aren't that far away, just ask your local motorcyclists where the fun roads are if you don't know the local spots.
I happen to live in one of those areas and drive some really fun roads on my weekly trip to and from SF, but I'm not that far from a bunch of people who live in a very different environment and almost don't seem to know our roads exist.
I agree that the choice of cars for this article is unfortunate. When I saw the two pictures, before reading the article, I thought it was going to be about two timeless designs that took very different approaches.
I think if you're in a certain population you'll see the Porsche as better designed, but you likely would have thought the same thing in 1973. But I think Paul might be surprised at how many people today would choose the '73 Caddy over the '73 911.
I think if you're in a certain population you'll see the Porsche as better designed, but you likely would have thought the same thing in 1973. But I think Paul might be surprised at how many people today would choose the '73 Caddy over the '73 911.
> But I think Paul might be surprised at how many people today would choose the '73 Caddy over the '73 911.
If that were true then why would cadillac let that model/style die out unlike porsche with the 911?
If that were true then why would cadillac let that model/style die out unlike porsche with the 911?
I'd wager to guess that most would chose the Porsche. I know I did. You can see mine, which happens to be a 1973 911E as Paul chose for his article, here: http://www.octanenation.com/custom/1973-porsche-911/254/
OctaneNation is my startup.
Further evidence that the 911 is desirable: http://www.hagerty.com/valuationtools/HVT/VehicleSearch/Repo... Mine sold for around $10.5k in 1973, and Haggerty says the average value now is $54k. Using an inflation calculator says $10.5k is equivalent to $53k today... Interesting.
The same Hagerty valuation tool shows the Cadillac is worth around $8k.
Further evidence that the 911 is desirable: http://www.hagerty.com/valuationtools/HVT/VehicleSearch/Repo... Mine sold for around $10.5k in 1973, and Haggerty says the average value now is $54k. Using an inflation calculator says $10.5k is equivalent to $53k today... Interesting.
The same Hagerty valuation tool shows the Cadillac is worth around $8k.
Considering the Porsche 911 is still made today and looks just as good today as it did 40 years ago, I think it qualifies as "timeless."
Compare a black 911 Carrera:
https://upload.wikimedia.org/wikipedia/commons/thumb/2/24/91...
And today:
https://www.autoweek.com/storyimage/CW/20110125/CARNEWS/1101...
Compare a black 911 Carrera:
https://upload.wikimedia.org/wikipedia/commons/thumb/2/24/91...
And today:
https://www.autoweek.com/storyimage/CW/20110125/CARNEWS/1101...
I'm unclear as to what your point is in response to mine? I thought both are timeless designs, for different reasons. Your response doesn't seem to dispute this at all...
> I think it fails is in recognising (and responding to) the core of the criticism levelled at Arc.
It's important to note that the article is from 2002 ( http://web.archive.org/web/20020210051448/http://www.paulgra... ) and the first public version of Arc is from 2008 ( http://web.archive.org/web/20080131070715/http://arclanguage... ).
In 2002 the main accusation was that Arc was only vaporware, or a mix of or ideas and features in pg head, perhaps with a first secret internal prototype implementation.
It's important to note that the article is from 2002 ( http://web.archive.org/web/20020210051448/http://www.paulgra... ) and the first public version of Arc is from 2008 ( http://web.archive.org/web/20080131070715/http://arclanguage... ).
In 2002 the main accusation was that Arc was only vaporware, or a mix of or ideas and features in pg head, perhaps with a first secret internal prototype implementation.
Making a language that good programmers would freely choose to use is a great design goal.
In my first paid job I wrote loads of Cobol, even though I was already proficient in more expressive languages. I can't think of any scenario where I would freely choose to use it.
Today I sometimes write SAS code. This can be so painful I solve the problem in Python first, at home, in my own time, then port the solution to SAS. Python (and its ecosystem) is so nice to use, and productive, I'd rather use it and not get paid, than get paid to use something else.
Any language that passes that test is doing pretty well.
In my first paid job I wrote loads of Cobol, even though I was already proficient in more expressive languages. I can't think of any scenario where I would freely choose to use it.
Today I sometimes write SAS code. This can be so painful I solve the problem in Python first, at home, in my own time, then port the solution to SAS. Python (and its ecosystem) is so nice to use, and productive, I'd rather use it and not get paid, than get paid to use something else.
Any language that passes that test is doing pretty well.
Sure :) I was picking old languages to match pg's choices a little.
But if we're talking today, I think Python is the Cadillac :)
But if we're talking today, I think Python is the Cadillac :)
>Porsche have spent years keeping the brand and style consistent. It was expensive and exclusive, which made it desirable.
I'm not a car person at all, and immediately I was able to see that the Porsche is (more) timeless than the Cadillac.
I'm not a car person at all, and immediately I was able to see that the Porsche is (more) timeless than the Cadillac.
I wasn't at all. I had to read the next paragraphs to figure out that the Porsche was intended to be the "better design".
I suspect that this might be due to me being European though. Classical American car designs, like that Cadillac, are very rare here and (possibly as a result of that,) considered quite classy. For one, I'd rather have the Cadillac parked on my driveway than the Porsche.
I suspect that this might be due to me being European though. Classical American car designs, like that Cadillac, are very rare here and (possibly as a result of that,) considered quite classy. For one, I'd rather have the Cadillac parked on my driveway than the Porsche.
Please don't make us "Europeans" look bad. The part of Europe I come from those kind of American cars are only considered "classy" by white thrash. Or people own them "ironically".
Then again, it's also been a few decades since owning a Porsche was a sign of good taste...
Then again, it's also been a few decades since owning a Porsche was a sign of good taste...
France here, and the Porsche seems to be a sort of toy, something like a Renault twingo[1], and don't ask me which one I prefer. :)
On the other side, the Cadillac has nice berline curve and make me think of our Citroen C6[2].
So, as we can see, design cars are culture local. Can we say the same thing for UI design ? Maybe the ideal design for an american differs that the ideal design for an european or an asiatic person ?
I have always thought that only the job, the grade, and the period-to-computers-exposure change the way users interact with their machines. Obviously the problem is bigger.
I am convinced that this essay touch right in the hearth something fundamental about cultural differences and their influences in design choices. In the same way that the GP languages for real people are not Lisp and Smalltalk but Java/C#, Python and Ruby. If Lisp is a widely used language, so are Ocaml and Erlang, but the let's face it: they're not.
So in conclusion, I think I will definitely not design the same UI for an US pg than for an EU pg, it need being study in details but there is differences in the mind and in the tastes, so that one have to adapt to the UI of the others.
Any idea/link about that ?
[1] http://upload.wikimedia.org/wikipedia/commons/thumb/8/83/Ren...
[2] http://images.caradisiac.com/logos/6/2/4/9/136249/S5-Citroen...
On the other side, the Cadillac has nice berline curve and make me think of our Citroen C6[2].
So, as we can see, design cars are culture local. Can we say the same thing for UI design ? Maybe the ideal design for an american differs that the ideal design for an european or an asiatic person ?
I have always thought that only the job, the grade, and the period-to-computers-exposure change the way users interact with their machines. Obviously the problem is bigger.
I am convinced that this essay touch right in the hearth something fundamental about cultural differences and their influences in design choices. In the same way that the GP languages for real people are not Lisp and Smalltalk but Java/C#, Python and Ruby. If Lisp is a widely used language, so are Ocaml and Erlang, but the let's face it: they're not.
So in conclusion, I think I will definitely not design the same UI for an US pg than for an EU pg, it need being study in details but there is differences in the mind and in the tastes, so that one have to adapt to the UI of the others.
Any idea/link about that ?
[1] http://upload.wikimedia.org/wikipedia/commons/thumb/8/83/Ren...
[2] http://images.caradisiac.com/logos/6/2/4/9/136249/S5-Citroen...
I am also not a car person, 'the beetle' looks to me as a 'playboy' horse, while the other car looks more luxurious and more expensive.
"and immediately I was able to see that the Porsche"
That also happens with, say, movies. A really good movie about something that you normally wouldn't care about (in my case, say Sports) will be enjoyable by people who typically aren't interested in the subject many times.
That also happens with, say, movies. A really good movie about something that you normally wouldn't care about (in my case, say Sports) will be enjoyable by people who typically aren't interested in the subject many times.
I happen to love 911s in an unhealthy way, but some of the earlier models were very "solid" and engineered very well. Especially some of the earlier engines, they were bullet proof. So for reliability and simplicity, the 911 would be a solid choice even today.
>Conversely a lot of production code still uses Cobol and Pascal.
These arguments have always struck me as subject to the availability heuristic. Is there any scientific data on this?
These arguments have always struck me as subject to the availability heuristic. Is there any scientific data on this?
The cadillac evokes a sailing sloop. The porsche evokes a stallion. Cadillac has long deliberately referenced maritime traditions for style elements. They're just stylistically different and I don't see how one can easily see superiority in either.
I very much disagree with this: “Look what happened with the 911. It's so obviously superior to the Cadillac that a child could tell it's better.”
I performed an experiment when I read this article, comparing the two cars based on just the pictures. I had read the paragraph after the pictures, about telling good design from bad design, but not the paragraph before, saying that what each model of car was designed for. And I tried to compare the design of the cars based on just the pictures, seriously. At first, I thought that the 911 might be better because it is more aerodynamic, a criterion that it is objectively better at. But then I noticed that the Cadillac has more headlights in the front, which possibly might provide better light. And I saw that the Cadillac seemed to be a convertible, which is more a matter of taste and your goals for a car. I concluded that both cars seemed pretty decent in their own way. Thus, I was surprised to read the claim that the 911 has obviously superior design to the Cadillac.
Perhaps Paul Graharm is right about language design, but this failure of his claim to withstand an experiment lessens my confidence that he has examined the evidence before making his conclusion. Though as I am, in my opinion, a “good programmer”, I certainly hope he that is right, and that languages aimed at good programmers are the ones whose ideas will become popular in time.
I performed an experiment when I read this article, comparing the two cars based on just the pictures. I had read the paragraph after the pictures, about telling good design from bad design, but not the paragraph before, saying that what each model of car was designed for. And I tried to compare the design of the cars based on just the pictures, seriously. At first, I thought that the 911 might be better because it is more aerodynamic, a criterion that it is objectively better at. But then I noticed that the Cadillac has more headlights in the front, which possibly might provide better light. And I saw that the Cadillac seemed to be a convertible, which is more a matter of taste and your goals for a car. I concluded that both cars seemed pretty decent in their own way. Thus, I was surprised to read the claim that the 911 has obviously superior design to the Cadillac.
Perhaps Paul Graharm is right about language design, but this failure of his claim to withstand an experiment lessens my confidence that he has examined the evidence before making his conclusion. Though as I am, in my opinion, a “good programmer”, I certainly hope he that is right, and that languages aimed at good programmers are the ones whose ideas will become popular in time.
I think he's referring more to the visual aesthetic. The 911 is literally timeless, because the broad strokes of the shape have been nearly unchanged in the past 40 years, and it's still one of the most beautiful and lusted after cars on the road. The Cadillac looks ugly.
I have always hated the design of the Porsche. As a kid I was so surprised to learn that this was the famous "Porsche" I had heard so much about. I am not a car guy, and thus perhaps my opinion doesn't matter, but I can at least understand the visual appeal of a Lamborghini or a BMW. Or perhaps put a better way, I can at least see what they're going for. With a Porsche, I'm just kind of reminded of a smart car. Its so tiny and stumpy that it looks ridiculous and straight out of the 80s to me. I actually start considering the fact that it only has two seats (as opposed to most sports cars which I usually forget when just looking at it). It neither looks fast nor classy, I just don't get it. Also, to me it doesn't look timeless, it just looks old. When I see a new one I imagine a scene from an 80s wallstreet movie or something.
The 911 was designed in the 1960s, the one displayed is from 1973. The reason the design is iconic is that the car is rear engined which gives it the unique characteristics of driving and style. It also allows for an aerodynamic profile while still having 4 seats. Having a horizontally opposed sir cooled engine also keeps both weight, cost and centre of gravity low, giving better handling, efficiency and mileage.
By the 1980s the design was quite dated but still popular because of the reputation of the car.
The reason pg probably picked the car was because the form followed the functions, it was designed rather than styled.
By the 1980s the design was quite dated but still popular because of the reputation of the car.
The reason pg probably picked the car was because the form followed the functions, it was designed rather than styled.
Same here. 911 to me is an acquired taste. I can appreciate their design now, especially the recent iterations but I remember I said it looked like a squashed frog with bulgy eyes when I first saw one as a kid.
"Mere exposure" effect. "Social proof". Anything long-loved and popular becomes attractive.
Also happens with people's faces. A person who at first might appear ugly I've found gets better looking the more you see them. They don't become good looking or anything but appear less ugly.
And sometimes you fall in love instantly. Happened for me with the 911 and the Countach, without me knowing that they were expensive.
Yes, but it is fair to say the design evolved nicely, to the point of "looking good" rather than "weird-good".
Meh, I've always liked the smooth shape. I also love the look of the much boxier and more aggressive looking Ferarri Testarossa and Lamborghini Countach, but I think they look much more dated than even the 73 911. Design always has some elements of personal preference, of course.
This whole thing is such a logical fallacy I can't pick one name for it. How about fundamentally privileging the survivor hypothesis effect bias?
If the 911 turned out to look shit or be unfashionable, they would have changed the styling/stopped making it completely, like most cars from the 70s.
On the other hand, maybe it is still fashionable because they still make it? After all, generally what expert designers say is fashionable, is fashionable.
On the gripping hand, so? Maybe the turnover of style in a niche (sportscar vs mass-market) is slower (as you would expect given fast fashion and volume of play). That does not mean that niche is any better designed, only that bad design takes longer to be recognised and/or fashion tastes change slower.
If the 911 turned out to look shit or be unfashionable, they would have changed the styling/stopped making it completely, like most cars from the 70s.
On the other hand, maybe it is still fashionable because they still make it? After all, generally what expert designers say is fashionable, is fashionable.
On the gripping hand, so? Maybe the turnover of style in a niche (sportscar vs mass-market) is slower (as you would expect given fast fashion and volume of play). That does not mean that niche is any better designed, only that bad design takes longer to be recognised and/or fashion tastes change slower.
I don't think he's referring to the visual aesthetic. I went through what the parent comment describes and kept re-reading these lines to guess what pg meant: "The Cadillac was carefully designed to appeal to the average driver. The 911 was designed for performance. Which one is better design?". I concluded that he did not mean visual design but instead meant some notion of "overall design" that included both visual appeal and performance, and did not state how he defined the term.
And then I read "It's so obviously superior to the Cadillac that a child could tell it's better" and decided that either he's bullshitting or my design sense is non-existent.
And then I read "It's so obviously superior to the Cadillac that a child could tell it's better" and decided that either he's bullshitting or my design sense is non-existent.
I performed an experiment too.
The 7.5 year old and the 6 year old both claimed the red one is "better".
The 7.5 year old and the 6 year old both claimed the red one is "better".
It isn't actually a convertible. Rather, the soft roof is just a particularly American design affectation.
Heh, the car comparison really does resonate with me: I like the Porsche far more because it is a simple design, aesthetically. Sure, the actual implementation--the weird engine position and all the mechanisms needed to compensate for it--is relatively complicated. But this does not compromise the minimalist aesthetic. Quite a nice feeling, especially for a car from that era. The great performance is just a boost.
The Cadillac, on the other hand, is probably simpler mechanically. It's a much more conservative, reasonable car: after all, who would be mad enough to put an engine at the rear of their sports car? But, wow, is the design busy. Little fiddly bits, fins, wheel-covers, too much chrome...
Perhaps the best way to think about it is that the Porsche is a car with a small surface area (metaphorically) and a large depth. The Cadillac is the opposite: larger surface are but less depth. I much prefer the former.
And this preference carries over into programming languages. I always like a language with nice aesthetics--simple semantics--even if it's harder to implement efficiently. I want a language which is simultaneously simpler and more flexible than the alternatives. And good performance certainly wouldn't hurt!
At a high level, these qualities mirror preferring the Porsche, which is why I like this metaphor. Sure, it's not perfect--but it isn't supposed to be. I don't even think of it as an argument in favor of one aesthetic over another; instead, I think it's just a great way to describe why I like what I like.
The Cadillac, on the other hand, is probably simpler mechanically. It's a much more conservative, reasonable car: after all, who would be mad enough to put an engine at the rear of their sports car? But, wow, is the design busy. Little fiddly bits, fins, wheel-covers, too much chrome...
Perhaps the best way to think about it is that the Porsche is a car with a small surface area (metaphorically) and a large depth. The Cadillac is the opposite: larger surface are but less depth. I much prefer the former.
And this preference carries over into programming languages. I always like a language with nice aesthetics--simple semantics--even if it's harder to implement efficiently. I want a language which is simultaneously simpler and more flexible than the alternatives. And good performance certainly wouldn't hurt!
At a high level, these qualities mirror preferring the Porsche, which is why I like this metaphor. Sure, it's not perfect--but it isn't supposed to be. I don't even think of it as an argument in favor of one aesthetic over another; instead, I think it's just a great way to describe why I like what I like.
This seems to be the only top-level comment that actually gets what pg is driving at: Simplicity.
Ferdinand Alexander Porsche's philosophy was that design should be honest. The car shouldn't pretend to be more than it really is. Reduce the design to the core of the product, eliminate distractions. Don't align the design to current fashion or trends. He believed that it's the other way round, fashion aligns itself to well-designed products.
"Design must be functional and functionality must be translated into visual aesthetics, without any reliance on gimmicks that have to be explained. [...] A product that is coherent in form requires no embellishment. It is enhanced by the purity of its form. Form should be presented in a way that is easily understood and that does not divert attention from the product and its functional purpose. [...] Good design must be honest.”
(Source: http://www.porsche.com/spain/aboutporsche/pressreleases/pag/... )
Ferdinand Alexander Porsche's philosophy was that design should be honest. The car shouldn't pretend to be more than it really is. Reduce the design to the core of the product, eliminate distractions. Don't align the design to current fashion or trends. He believed that it's the other way round, fashion aligns itself to well-designed products.
"Design must be functional and functionality must be translated into visual aesthetics, without any reliance on gimmicks that have to be explained. [...] A product that is coherent in form requires no embellishment. It is enhanced by the purity of its form. Form should be presented in a way that is easily understood and that does not divert attention from the product and its functional purpose. [...] Good design must be honest.”
(Source: http://www.porsche.com/spain/aboutporsche/pressreleases/pag/... )
But the simple rear engine design is more minimalist and aesthetic. Having the engine at the rear improves interior space. It reduces frontal area, which improves aerodynamics. Having an air cooled engine allows the rear placement without a complicated cooling system, having it horizontally opposed allows a lower centre of gravity as well as allowing a slimmer profile while still giving interior space.
The great performance was the goal all along- all the decisions that went into the design were made with performance in mind.
The early 911s (as pictured) didn't have exscessive power so the rear engine wasn't such a big deal. When they started putting in turbochargers the limits of the design were easily found. But Porsche was still able to work around these without ever turning it into a Cadillac.
The great performance was the goal all along- all the decisions that went into the design were made with performance in mind.
The early 911s (as pictured) didn't have exscessive power so the rear engine wasn't such a big deal. When they started putting in turbochargers the limits of the design were easily found. But Porsche was still able to work around these without ever turning it into a Cadillac.
> after all, who would be mad enough to put an
> engine at the rear of their sports car?
Off course a rear-engine is difficult to drive, so there are sports car with a front-engine, but it's far from optimal from a performance stand point.
The conflict between performance and appeal to the masses: that is in my opinion what Paul's essay is about.
Racing cars--and many sports cars--are mid engined. That is, the engine is behind the driver but not behind the rear wheels. The 911, on the other hand, actually has its engine all the way in the back, partially behind the rear axle. It's a very different layout and rather uncommon.
If we're talking about "designed to appeal to the average driver" then why (cherry) pick the Cadillac? I'd choose the Volkswagen Beetle. It was simply known as Volkswagen at first, which literally means "people's car." I cannot think of a more "timeless" car than the VW bug.
https://en.wikipedia.org/wiki/Volkswagen_Beetle
https://www.google.com/search?q=vw+beetle&safe=off&s...
https://en.wikipedia.org/wiki/Volkswagen_Beetle
https://www.google.com/search?q=vw+beetle&safe=off&s...
That is a bit funny, since the beetle was designed by Ferdinand Porsche himself.
The first Volkswagen Beetle was designed by Ferdinand Porsche, apparently. http://en.wikipedia.org/wiki/Porsche#Relationship_with_Volks...
So true. The Beetle is the C of cars: it may not have the amenities that something that is rolling out of the factory today has, but its simple design means you can understand what's going on under the hood, and keep it running with a very reduced toolset.
In fact, its air-cooled engine was so reliable that it remained in production until 2006, and is still widely used for propulsion in dozens of light aircraft designs such as the Sonex or the Formula-V racing class.
the timlessness of the beatle might stem form the coincidence that it had the same designer the porsche had
> "We want thinking in Arc to feel like driving a 911."
A car notorious to be nigh impossible to drive until they started adding so much electronics that it practically drives itself and the driver is only sort of there to enjoy the ride he is being given.
A car notorious to be nigh impossible to drive until they started adding so much electronics that it practically drives itself and the driver is only sort of there to enjoy the ride he is being given.
So, Clojure then?
So in other words, the 911 was amazing design. I dunno about you, but to me a car that practically drives itself sounds awesome.
The 911s pre-1989 were really hard to drive. They didn't start adding electronics into them until a lot of people had died in 911 accidents.
I don't actually think the 911 is a good design at all. There's good engineering to make a bad design work, but it's pretty much inferior to a genuinely well designed car which doesn't require quality engineering.
The AK-47 is a better assault rifle than the AR-15, in that an illiterate dude with a stamping machine can turn out a reliable AK-47 which can be operated by children, whereas the AR-15 requires pretty high tech materials to work well (the right lubricants, the right barrel linings, etc.), and while it's easy to shoot, does require some maintenance which illiterate children aren't going to give it.
Now, the older MX-5 Miata, that's a good design. Simple, cheap, drives well.
I don't actually think the 911 is a good design at all. There's good engineering to make a bad design work, but it's pretty much inferior to a genuinely well designed car which doesn't require quality engineering.
The AK-47 is a better assault rifle than the AR-15, in that an illiterate dude with a stamping machine can turn out a reliable AK-47 which can be operated by children, whereas the AR-15 requires pretty high tech materials to work well (the right lubricants, the right barrel linings, etc.), and while it's easy to shoot, does require some maintenance which illiterate children aren't going to give it.
Now, the older MX-5 Miata, that's a good design. Simple, cheap, drives well.
Whoa, so the Porsche 911 (very appropriate name in the USA!) is Windows.
That's the modern 911's though. The 70's ones had severe problems with understeer because the front is so light, but once you got that under control there was massive oversteer due to the sheer weight of the back.
Turns out putting your engine behind the rear axis is not a very naturally stable design. Needs computers to keep it drivable.
Of course you likely won't notice any of this driving to the supermarket ... but then you're abusing this car and should feel bad.
Turns out putting your engine behind the rear axis is not a very naturally stable design. Needs computers to keep it drivable.
Of course you likely won't notice any of this driving to the supermarket ... but then you're abusing this car and should feel bad.
Have you actually driven one? It isn't as bad as you might think. When you are on the power, having the weight on the rear of the car is an advantage. They aren't nearly as hard to drive as their reputation leads people to believe.
I bet more new drivers struggle with the heaviness of the clutch and lack of power steering before they get anywhere near the limits of the car.
I bet more new drivers struggle with the heaviness of the clutch and lack of power steering before they get anywhere near the limits of the car.
Unfortunately I have not. But I have seen several accelerating from a stoplight and almost not making the corner on a perfectly dry road.
Granted, the car I drive also understeers madly ... but all cheap front-wheel cars do that. (yes, I like having fun with cars even when they're cheap and have no business being driven like that)
As for the car's limits, you don't buy a car like this to not hit the limits. If you do, then you make me sad.
Granted, the car I drive also understeers madly ... but all cheap front-wheel cars do that. (yes, I like having fun with cars even when they're cheap and have no business being driven like that)
As for the car's limits, you don't buy a car like this to not hit the limits. If you do, then you make me sad.
In this article, PG makes the claim that "Even a child would think the Porsche 911 is a better design than the cadillac"
Am I the only one who looks at these cars, and sees two quality cars, both with different design goals? I've driven a TON of cars, too.
Use the right tool for the job.
Am I the only one who looks at these cars, and sees two quality cars, both with different design goals? I've driven a TON of cars, too.
Use the right tool for the job.
As a child I said the 911 looked ugly, like a squashed frog with bulged eyes. For years I didn't understand the hype that surrounded it (I always favoured the 928). I do like them now but it's a result of decades of societal conditioning...
A design becomes "timeless" when the problem is solves spans several generations. The need for paperclips hasn't declined, and this is because of it's simplicity and performance (timeless needs).
I do think, however, that the car metaphor is flawed: technology is changing at such an amazing pace that within a couple of decades this might read this as discussion about what's the best horse-drawn carriage.
The craft of programming is particularly young, I'm not sure that coding of the future will look anything like what's done now. It has certainly changed a lot in the past 40 years. In other words: I'm not sure we will be driving cards in the future.
I do think, however, that the car metaphor is flawed: technology is changing at such an amazing pace that within a couple of decades this might read this as discussion about what's the best horse-drawn carriage.
The craft of programming is particularly young, I'm not sure that coding of the future will look anything like what's done now. It has certainly changed a lot in the past 40 years. In other words: I'm not sure we will be driving cards in the future.
Let's be honest though, when was the last time any if us saw or actually used a paper clip? I know they still exist and are used, but they never make it to my desk.
Programming also has changed very little in the last 20 years. Driving hasn't changed much since at least I was born (~40 years)
Programming also has changed very little in the last 20 years. Driving hasn't changed much since at least I was born (~40 years)
Maybe it's the images you chose, or a sense of nostalgia, or retro kitsch, but to me both those cars look completely awesome now.
On the other hand from a maintenance point of view... probably not so much
On the other hand from a maintenance point of view... probably not so much
Maybe I'm just being contrarian, but the Cadillac looks nicer to me; the 911 is too curved, making it look like a Mini or a Beetle.
I agree.
>[The 911 is] so obviously superior to the Cadillac that a child could tell it's better.
My first thought was that the Cadillac looked better even though the internals of the 911 were certainly higher quality. Does that mean I have worse design sense than a child? :(
>The Cadillac was carefully designed to appeal to the average driver. The 911 was designed for performance. Which one is better design?
It all depends on how you evaluate quality: there are so many ways to determine the "best" that questions like this are almost meaningless.
Regardless of the car metaphor, I think PG's point makes a lot of sense.
>[The 911 is] so obviously superior to the Cadillac that a child could tell it's better.
My first thought was that the Cadillac looked better even though the internals of the 911 were certainly higher quality. Does that mean I have worse design sense than a child? :(
>The Cadillac was carefully designed to appeal to the average driver. The 911 was designed for performance. Which one is better design?
It all depends on how you evaluate quality: there are so many ways to determine the "best" that questions like this are almost meaningless.
Regardless of the car metaphor, I think PG's point makes a lot of sense.
Regardless of the car metaphor, I think PG's point makes a lot of sense.
Does it?
From the article: C, Smalltalk, Lisp. The languages that were consciously designed for "average" programmers (Cobol, Pascal, Ada) have tended to be evolutionary dead ends.
COBOL and Pascal (via Delphi) are probably used more than Smalltalk and Lisp in the real world. Also, Java and C#, designed for the 'average' programmer, are immensely popular outside our little bubble. Java has been around for twenty years and will probably be for at least two more decades.
I like tinkering with new and 'revolutionary' languages - I wrote a fair share of Prolog and Haskell, but I have come to the realisation that that I like to solve interesting problems (mostly in NLP and machine learning) far more. And when you focus on solving an interesting problem it can be good that the language and ecosystem are boring and predictable (Java, C, C++), so that you can focus at the problem at hand. For example, in Java you can easily add a library to a project via Maven and its usage will often be completely predictable, you don't have to deal with the fact that the library writer was in an existential typing, GADT, or arrows phase and fight with its API.
BTW. I still love Prolog and Haskell ;).
Does it?
From the article: C, Smalltalk, Lisp. The languages that were consciously designed for "average" programmers (Cobol, Pascal, Ada) have tended to be evolutionary dead ends.
COBOL and Pascal (via Delphi) are probably used more than Smalltalk and Lisp in the real world. Also, Java and C#, designed for the 'average' programmer, are immensely popular outside our little bubble. Java has been around for twenty years and will probably be for at least two more decades.
I like tinkering with new and 'revolutionary' languages - I wrote a fair share of Prolog and Haskell, but I have come to the realisation that that I like to solve interesting problems (mostly in NLP and machine learning) far more. And when you focus on solving an interesting problem it can be good that the language and ecosystem are boring and predictable (Java, C, C++), so that you can focus at the problem at hand. For example, in Java you can easily add a library to a project via Maven and its usage will often be completely predictable, you don't have to deal with the fact that the library writer was in an existential typing, GADT, or arrows phase and fight with its API.
BTW. I still love Prolog and Haskell ;).
A false dichotomy. Somehow, these always crop up when discussing languages. Sure, in Java you don't have to deal with GADTs. But you do have to deal with the fact that people think functions are dark magic and expect you to extend an abstract class instead. (Yes, Swing, I'm looking at you!)
I've found that the advantages of using a nice high-level language like Haskell far outweigh issues with build systems and libraries and the usual boring stuff Java et al are supposed to excel at. This for very interesting problems--most recently, program synthesis using MCMC. (Following the "Stochastic Superoptimization" paper, but I honestly think that name is a bit silly :P.)
Besides, have you ever tried to use the equivalent of Parsec or QuickCheck in Java? Even boring, practical things like that are better in Haskell!
I've found that the advantages of using a nice high-level language like Haskell far outweigh issues with build systems and libraries and the usual boring stuff Java et al are supposed to excel at. This for very interesting problems--most recently, program synthesis using MCMC. (Following the "Stochastic Superoptimization" paper, but I honestly think that name is a bit silly :P.)
Besides, have you ever tried to use the equivalent of Parsec or QuickCheck in Java? Even boring, practical things like that are better in Haskell!
Every time someone figures out how to solve a small programming problem elegantly in Haskell, it is interesting enough for a 10 page ICFP paper with a 10 page appendix.
Sure, Java is inelegant and dirty, but you don't have to perform the thinking needed to write a dissertation to use it.
Sure, Java is inelegant and dirty, but you don't have to perform the thinking needed to write a dissertation to use it.
Untrue for the things Java makes easy. After all, in the worst case, you can just drop into Haskell's imperative subset.
Besides, it's mostly small programming problems like practical STM, deterministic parallelism, easy randomized testing or DSLs for describing derivatives (alliterative). These are things not even dreamed of in Java--the only reason they're small is because Haskell makes them small.
However, all this is not important. Sure, coming up with abstractions requires research and produces papers. But using the abstractions doesn't!
OOP and Java and the JVM are all based on a ton of CS research themselves, but clearly you don't think that makes them impenetrable. The same applies to Haskell--you don't have to create your own abstractions from scratch; instead, just use the brilliant ones people have created for you.
Besides, it's mostly small programming problems like practical STM, deterministic parallelism, easy randomized testing or DSLs for describing derivatives (alliterative). These are things not even dreamed of in Java--the only reason they're small is because Haskell makes them small.
However, all this is not important. Sure, coming up with abstractions requires research and produces papers. But using the abstractions doesn't!
OOP and Java and the JVM are all based on a ton of CS research themselves, but clearly you don't think that makes them impenetrable. The same applies to Haskell--you don't have to create your own abstractions from scratch; instead, just use the brilliant ones people have created for you.
You still have to know a lot to use those abstractions...like category theory (monads and arrows). You have to at least be able to read the paper even if you aren't capable of writing it.
There is also a kind of compulsion to design elegant abstractions when using Haskell, to think about and understand problems really well before you write a solution. This is not just about the kind of people who are attracted to using Haskell, but the language itself promotes this compulsion. Sure, you can drop into Haskell's imperative subset, but it is frowned on and discouraged.
Java as a language gives you very little, and there is not much pressure to obsess over the design of abstractions. This is both good and bad: good in that you feel less guilt about writing dirty code fairly quickly and with less understanding (to be acquired more gradually via trial and error), and bad in that this code will probably incur more technical debt. Sometimes worse is better [1], ironically (or maybe not) a concept that comes from Gabriel, who is a cornerstone of the common lisp community.
[1] http://www.dreamsongs.com/WorseIsBetter.html
There is also a kind of compulsion to design elegant abstractions when using Haskell, to think about and understand problems really well before you write a solution. This is not just about the kind of people who are attracted to using Haskell, but the language itself promotes this compulsion. Sure, you can drop into Haskell's imperative subset, but it is frowned on and discouraged.
Java as a language gives you very little, and there is not much pressure to obsess over the design of abstractions. This is both good and bad: good in that you feel less guilt about writing dirty code fairly quickly and with less understanding (to be acquired more gradually via trial and error), and bad in that this code will probably incur more technical debt. Sometimes worse is better [1], ironically (or maybe not) a concept that comes from Gabriel, who is a cornerstone of the common lisp community.
[1] http://www.dreamsongs.com/WorseIsBetter.html
It's frowned upon because the imperative subsets tend to code that's less general and harder to reason about. These critiques falls identically on Java, though nobody misses it there because nobody practices the generality and reasonability available in a very simple typed lambda calculus there.
It's remarkable how much more you have to keep alive in your mind to program in Java (or even Clojure) over Haskell. The reason things are more complex is because you're freed from having to think hard about state and execution methodology except at bottlenecks of design and performance.
It's remarkable how much more you have to keep alive in your mind to program in Java (or even Clojure) over Haskell. The reason things are more complex is because you're freed from having to think hard about state and execution methodology except at bottlenecks of design and performance.
Sure, in Java you don't have to deal with GADTs. But you do have to deal with the fact that people think functions are dark magic and expect you to extend an abstract class instead.
The amount of type wizardry that Haskell permits is far larger than Java and C++ teaches us that in practice you have to expect all possible combinations language features that are allowed. A random Java library will have a far more understandable API than a random Haskell package, since there are not so many permutations of language features possible.
If everybody stuck to just Haskell 98, things would be far simpler.
Besides, have you ever tried to use the equivalent of Parsec or QuickCheck in Java?
As a matter of fact, I just committed QuickCheck-like unit tests five minutes ago [1] :):
https://github.com/danieldk/dictomaton/commit/7aaa89aae68524...
I write such tests in Java quite often. Of course, you don't have the nice combinators of QuickCheck :). I am not saying that Haskell isn't more powerful it is. But it comes at a cost: many packages come with an up-front learning cost, Haskell is hard to optimize compared to Java or C, etc. The Java APIs are predictable, run-time performance is predictable (in the sense that it easy to profile and optimize) and the ecosystem is boring and predictable. These are some of reasons that Java is popular (besides having a steward with deep pockets).
([1] Ps. yes, I know there is a very obvious optimization optimization possible that commit, it's a development branch.)
The amount of type wizardry that Haskell permits is far larger than Java and C++ teaches us that in practice you have to expect all possible combinations language features that are allowed. A random Java library will have a far more understandable API than a random Haskell package, since there are not so many permutations of language features possible.
If everybody stuck to just Haskell 98, things would be far simpler.
Besides, have you ever tried to use the equivalent of Parsec or QuickCheck in Java?
As a matter of fact, I just committed QuickCheck-like unit tests five minutes ago [1] :):
https://github.com/danieldk/dictomaton/commit/7aaa89aae68524...
I write such tests in Java quite often. Of course, you don't have the nice combinators of QuickCheck :). I am not saying that Haskell isn't more powerful it is. But it comes at a cost: many packages come with an up-front learning cost, Haskell is hard to optimize compared to Java or C, etc. The Java APIs are predictable, run-time performance is predictable (in the sense that it easy to profile and optimize) and the ecosystem is boring and predictable. These are some of reasons that Java is popular (besides having a steward with deep pockets).
([1] Ps. yes, I know there is a very obvious optimization optimization possible that commit, it's a development branch.)
Yeah, I also prefer the Cadillac visually. (although I'd drop either for a BMW 2002) And for 90% of what you do with the car, the Cadillac was probably more practical. Particularly if you lived in any parts of the US except maybe LA/SF/NY in 1973.
In my opinion, the "best" programming language is the best tool for the job at hand.
Maybe you're writing high-performance backend software, in which speed is everything. Sure, a functional or, hell, low-level language like assembly is the "right" choice. In this case, it is the 'better' language.
Or, maybe, you're trying to write an easy-to-maintain script to manage log files on your server. Who cares if it's costing you some CPU cycles to interpret? Run Python or Ruby, or, hell, just write a shell script. That would be the 'better' language.
I wholeheartedly agree with what I believe to be pg's intent in this writeup: that good design should be timeless. I don't agree, however, that good design, especially for a programming language, always has to be skill- or performance-oriented.
Quick edit for clarity: Although the example I used for backend software did equate "performance" to "speed," it's important to note that pg addressed this by saying:
> Performance doesn't mean speed; that's taking the metaphor too literally. Speed counts, but a programming language is first of all a tool for thinking in.
My point is that clear thinking can be equally applied to easy-to-read code working at a high level as it can be to any functional language designed to induce algorithmic thought.
Maybe you're writing high-performance backend software, in which speed is everything. Sure, a functional or, hell, low-level language like assembly is the "right" choice. In this case, it is the 'better' language.
Or, maybe, you're trying to write an easy-to-maintain script to manage log files on your server. Who cares if it's costing you some CPU cycles to interpret? Run Python or Ruby, or, hell, just write a shell script. That would be the 'better' language.
I wholeheartedly agree with what I believe to be pg's intent in this writeup: that good design should be timeless. I don't agree, however, that good design, especially for a programming language, always has to be skill- or performance-oriented.
Quick edit for clarity: Although the example I used for backend software did equate "performance" to "speed," it's important to note that pg addressed this by saying:
> Performance doesn't mean speed; that's taking the metaphor too literally. Speed counts, but a programming language is first of all a tool for thinking in.
My point is that clear thinking can be equally applied to easy-to-read code working at a high level as it can be to any functional language designed to induce algorithmic thought.
This is so true, but it's more than just cpu speed vs programmer speed. There are philosophies that are built in to the language and you can see them in decisions made about the language, the kinds of patterns baked in, the libraries and the greater community.
Say you need high reliability. Erlang has fault tolerance model & hot code reloading, it was built for telephone systems. Say you need tons of statistical features: R. Infinite Recursion: Stackless Python. Mixins Galore: _why's potion. Run a bunch of commands with little/no logic: Tcl. html generation: php. Manipulate a flash canvas: Actionscript. Manipulate html dom: javascript.
Be honest, your language isn't going to stick around forever. I say make a language for a purpose with a specific problem space in mind, read papers and implement surrounding philosophies that nail down that problem well. Then it will become popular and overused to the point where it's used for things it wasn't meant for.
Say you need high reliability. Erlang has fault tolerance model & hot code reloading, it was built for telephone systems. Say you need tons of statistical features: R. Infinite Recursion: Stackless Python. Mixins Galore: _why's potion. Run a bunch of commands with little/no logic: Tcl. html generation: php. Manipulate a flash canvas: Actionscript. Manipulate html dom: javascript.
Be honest, your language isn't going to stick around forever. I say make a language for a purpose with a specific problem space in mind, read papers and implement surrounding philosophies that nail down that problem well. Then it will become popular and overused to the point where it's used for things it wasn't meant for.
I know which car I would have chosen to live out of on the road as a salesman in 1973. In '76 there were undoubtedly significantly more three year old Caddilacs with 100,000 miles than Porsches.
The Caddillac was designed for high uptime during a three year depreciation cycle. It was designed to handle rutted industrial parking lots. It was designed to handle potholed urban streets.
Four adults could drive to Ohmaha with their luggage - and if the water pump went, a mechanic in Council Bluffs could fix it without the Shim of the Black Forest Gnomes.
In other words, the our first reaction to our thought that a design is bad should be to examine our understanding of design intent. There is a significant portion of the meanings of "designed to be driven" over which the Porsche is poorly designed.
The Caddillac was designed for high uptime during a three year depreciation cycle. It was designed to handle rutted industrial parking lots. It was designed to handle potholed urban streets.
Four adults could drive to Ohmaha with their luggage - and if the water pump went, a mechanic in Council Bluffs could fix it without the Shim of the Black Forest Gnomes.
In other words, the our first reaction to our thought that a design is bad should be to examine our understanding of design intent. There is a significant portion of the meanings of "designed to be driven" over which the Porsche is poorly designed.
Mh, both cars really had totally different philosophies and characteristics, appealed to people with different priorities and tastes and were not in the same price league.
So just saying that the Porsche is obviously better designed doesnt hold much value.
Asethetically ? Probably, but thats more a matter of taste, just like with programming languages.
Asethetically ? Probably, but thats more a matter of taste, just like with programming languages.
PG has a date on each of his essays, this one doesn't have one. Neither can I find it in his list of essays. What is it?
Very good points, but the article a little bit and the comments here in particular remind me of one of my favorite tweets:
> Let's argue about whether Haskell or Clojure is better while somebody else ships products using PHP and duct tape.
https://twitter.com/agentdero/status/174965036928868352
> Let's argue about whether Haskell or Clojure is better while somebody else ships products using PHP and duct tape.
https://twitter.com/agentdero/status/174965036928868352
That's a blatantly false dichotomy.
Often the people doing the arguing are also the most productive: witness Don Stewart. Quantitative finance is more demanding than some PHP-laden startup, and yet he still manages to write a bunch of libraries and surprisingly performant code.
Often the people doing the arguing are also the most productive: witness Don Stewart. Quantitative finance is more demanding than some PHP-laden startup, and yet he still manages to write a bunch of libraries and surprisingly performant code.
A Porsche is not what I'd call a practical car. It's not especially comfortable if you're tall, the visibility is poor, it doesn't hold a family or have much storage space at all, it's not efficient to operate or maintain, and it's not cheap to produce.
So what's the real lesson here?
Maybe it's something about aesthetics, but then the part about designing for expert drivers versus "average" drivers doesn't make sense.
So what's the real lesson here?
Maybe it's something about aesthetics, but then the part about designing for expert drivers versus "average" drivers doesn't make sense.
The comments in this thread reinforce the arguments in the article so strongly that I feel like this is all a joke I'm not in on.
Slightly offtopic, I like that this is about design in general, and not about "css and pretty pictures", which is what the term "design" has unfortunately come to mean on HN.
I often think that software design, API design (of libraries, not just HTTP APIs), and so on, are somewhat underrated skills, contrasted with being an "awesome super-fast programming ninja".
I often think that software design, API design (of libraries, not just HTTP APIs), and so on, are somewhat underrated skills, contrasted with being an "awesome super-fast programming ninja".
Haha. What a poorly reasoned article. Smalltalk and lisp - seriously??? Java was designed for the average programmer, nothing complex, all simple stuff, and it's been very successful. Meanwhile, smalltalk and lisp are minority languages that appeal to very few. Other than emacs can anyone think of any successful app that is written in either?
Good design has nothing to do with users and its easy, as this article does, mix aesthetics for design.
The 911 was expensive, hard to drive with its engine hanging out over the rear end and not even comparable with the caddy.
Even c, who uses that much anymore? Software development (unlike the 911) has evolved, today the level of abstraction is much higher. There is still c development of course, but java, python, ruby, and php are the dominant languages.
Good design has nothing to do with users and its easy, as this article does, mix aesthetics for design.
The 911 was expensive, hard to drive with its engine hanging out over the rear end and not even comparable with the caddy.
Even c, who uses that much anymore? Software development (unlike the 911) has evolved, today the level of abstraction is much higher. There is still c development of course, but java, python, ruby, and php are the dominant languages.
this article is about nothing.
Technically this is not an article, it's a "Design Philosophy" page from the Arc section of pg's site.
Comparing design comming from two different countries with widely different background breaks the analogy upfront.
Lisp and C, Smalltalk, Cobol, Pascal, Ada share the same american background, and were just designed with different audience and purpose.
As diego also points out the Beetle, or even the Golf (though introduced a a year after 1973) didn't change much either in terms of design during decades, though they were targeted and designed for mainstream "average" users.
Even on the language front I'm not convinced. Java for instance is aimed at average users and I don't see it going away anytime soon.
As diego also points out the Beetle, or even the Golf (though introduced a a year after 1973) didn't change much either in terms of design during decades, though they were targeted and designed for mainstream "average" users.
Even on the language front I'm not convinced. Java for instance is aimed at average users and I don't see it going away anytime soon.
i'm willing to accept the downvotes that will come along with saying both are pretty magnificent vehicles.
Whew, glad we're past downvoting based on trivial programming language choices.
There's always a market both for expert users and for the broad mass. Room for both Arc and PHP.
Which one will still be used and developed in 30 years? I wouldn't go with pg's argument that the one designed for experts will prove timeless, there are simply way too many factors involved.
Which one will still be used and developed in 30 years? I wouldn't go with pg's argument that the one designed for experts will prove timeless, there are simply way too many factors involved.
What a shame that even Paul Graham seems to be having his issues with a well-considered use of the word "design".
Degrading "design" to mean nothing but "aesthetics" is a view of the past, that young, savvy companies know well to avoid by integrating design from the very beginning of product planning stages.
(Maybe I'm misinterpreting what PG means. Although why else would he feel the need to use words like "fashion" and "hairstyles from the past" as an analogy?)
I'm especially surprised he uses this example because it doesn't even serve his argument well: The design of a programming language is only marginally related to aesthetics. Why not use an analogy that compares to the more prevalent criteria of a good/bad programming language?
On top of that, he makes an array of mistakes in his car analogy, and his use of "good" and "bad" design.
>The Cadillac was carefully designed to appeal to the average driver. The 911 was designed for performance. Which one is better design?
This is a moot question, since in real markets, the answer to this question depends on who you ask. Of course, the Porsche looks better according to today's standards. It's also better engineered, has better aerodynamics, etc. etc. etc. But the Cadillac was more widely available, had more leg room, more space in the trunk. And it was probably less expensive. So yeah. Neutrally speaking, both of these cars are designed well according to certain criteria.
>It's easier to tell good design from bad when you're not looking at current fashions.
Considering that the 911 aesthetics have not dramatically changed since then, looking at the image of a 1973 model will automatically feel more current, modern and familiar to the viewer. And speaking of fashion: The Cadillac's aesthetics have specifically gone out of fashion ever since car styling has evolved in a more sculpted and organic direction. No matter what field, anything that's recently out of fashion will be perceived as especially unpleasant and outdated. So how is it fair to compare one product that features aesthetics that are still largely regarded as fashionable, and one that's very specifically regarded as "yesterday" and unfashionable?
>Good design is timeless
If this statement was true, the whole fashion industry would be producing only bad design every single season. Timelessness of design is also nothing a designer of a product has any long-term control over. A product might be timeless in its design (=aesthetics? feature set? what does PG actually mean?) at the moment of its conception. But if it unwillingly becomes part of a trend (even if just because other companies imitate it), it won't be regarded as absolutely timeless anymore. It will have become a witness of its time, and the trends of that period. The first iPod could have been regarded as a timeless design when it was launched. But today, it is an unmistakable part of Apple's white plastic period. It is not timeless anymore.
"Design" stands for the planning/execution of all aspects of a product together. That includes aesthetics, feature set, implementation technologies, price point, launch date, market segment and much more. If PG had looked beyond the rather narrow horizon of aesthetics, he could have actually created an analogy that worked for him. Even if it included cars.
Degrading "design" to mean nothing but "aesthetics" is a view of the past, that young, savvy companies know well to avoid by integrating design from the very beginning of product planning stages.
(Maybe I'm misinterpreting what PG means. Although why else would he feel the need to use words like "fashion" and "hairstyles from the past" as an analogy?)
I'm especially surprised he uses this example because it doesn't even serve his argument well: The design of a programming language is only marginally related to aesthetics. Why not use an analogy that compares to the more prevalent criteria of a good/bad programming language?
On top of that, he makes an array of mistakes in his car analogy, and his use of "good" and "bad" design.
>The Cadillac was carefully designed to appeal to the average driver. The 911 was designed for performance. Which one is better design?
This is a moot question, since in real markets, the answer to this question depends on who you ask. Of course, the Porsche looks better according to today's standards. It's also better engineered, has better aerodynamics, etc. etc. etc. But the Cadillac was more widely available, had more leg room, more space in the trunk. And it was probably less expensive. So yeah. Neutrally speaking, both of these cars are designed well according to certain criteria.
>It's easier to tell good design from bad when you're not looking at current fashions.
Considering that the 911 aesthetics have not dramatically changed since then, looking at the image of a 1973 model will automatically feel more current, modern and familiar to the viewer. And speaking of fashion: The Cadillac's aesthetics have specifically gone out of fashion ever since car styling has evolved in a more sculpted and organic direction. No matter what field, anything that's recently out of fashion will be perceived as especially unpleasant and outdated. So how is it fair to compare one product that features aesthetics that are still largely regarded as fashionable, and one that's very specifically regarded as "yesterday" and unfashionable?
>Good design is timeless
If this statement was true, the whole fashion industry would be producing only bad design every single season. Timelessness of design is also nothing a designer of a product has any long-term control over. A product might be timeless in its design (=aesthetics? feature set? what does PG actually mean?) at the moment of its conception. But if it unwillingly becomes part of a trend (even if just because other companies imitate it), it won't be regarded as absolutely timeless anymore. It will have become a witness of its time, and the trends of that period. The first iPod could have been regarded as a timeless design when it was launched. But today, it is an unmistakable part of Apple's white plastic period. It is not timeless anymore.
"Design" stands for the planning/execution of all aspects of a product together. That includes aesthetics, feature set, implementation technologies, price point, launch date, market segment and much more. If PG had looked beyond the rather narrow horizon of aesthetics, he could have actually created an analogy that worked for him. Even if it included cars.
> We've been criticized for designing Arc as a language for good programmers.
That doesn't seem likely. Does anyone know what criticisms PG was responding to?
That doesn't seem likely. Does anyone know what criticisms PG was responding to?
So, according to pg, where do C++ and Java fit? "Average" category or "performance"? I think he has deliberately avoided mentioning these.
pg on Java: http://www.paulgraham.com/javacover.html
Never mind that most of the current big data tools are written in java: hdfs, hbase, kafka, flume, etc, etc, Netflix, LinkedIn and many other recent highly successful companies run their high performance empire entirely on java.
Cadillac was designed for drug dealers? hmm..
TL;DR: One design is better than another because the photo "looks better" to the modern eye.
I guess form doesn't follow function in this case.
The author then generalizes to language design with no supporting evidence, and omits various counter-examples (Visual Basic, JavaScript, PHP) that don't support his thesis.
I guess form doesn't follow function in this case.
The author then generalizes to language design with no supporting evidence, and omits various counter-examples (Visual Basic, JavaScript, PHP) that don't support his thesis.
I would take a convertible Cadillac ElDorado.
[deleted]
I'm going to take this discussion away from cars (which I know next to nothing about) and opine on technology designs.
There are technologies that people decide to use. Then there are technologies that people decide to make other people use. Design quality is much higher in the first category (badly-conceived ones die out) than in the second.
Most of what you encounter in a corporate software setup is in the second category. It's built to sell well to IT managers, not be productive and fun to use, because the people who will actually work with the product don't get a vote. It's not so simple as to apply this to languages (Java is the right tool for some purposes) but you get a feel for it after programming in a variety of environments. There are some tools that leave you thinking, "Wow, the people who set this place up really know what they were doing" and others that have the opposite effect.
I'd start a flamewar if I singled out specific technologies-- and, in the real world, it's not that simple-- but there's definitely an experience of "corporate programming" that is really distasteful and mediocre. Then there's the way people do things when they want to excel. They're different.
There are technologies that people decide to use. Then there are technologies that people decide to make other people use. Design quality is much higher in the first category (badly-conceived ones die out) than in the second.
Most of what you encounter in a corporate software setup is in the second category. It's built to sell well to IT managers, not be productive and fun to use, because the people who will actually work with the product don't get a vote. It's not so simple as to apply this to languages (Java is the right tool for some purposes) but you get a feel for it after programming in a variety of environments. There are some tools that leave you thinking, "Wow, the people who set this place up really know what they were doing" and others that have the opposite effect.
I'd start a flamewar if I singled out specific technologies-- and, in the real world, it's not that simple-- but there's definitely an experience of "corporate programming" that is really distasteful and mediocre. Then there's the way people do things when they want to excel. They're different.
> There are technologies that people decide to use. Then there are technologies that people decide to make other people use. Design quality is much higher in the first category (badly-conceived ones die out) than in the second.
That's it: it's all in the selection process. If you select for the wrong reasons (such as "please the manager"), you'll get sub-par results.
Now, if we could tell for a fact that many technologies are selected for the wrong reasons, it would probably explain a good deal of the huge gap there is between "real world" IT and the state of the art. Think of it for a minute: in the 70s, we had Smaltalk, Scheme, and ML¹. Twenty freaking years later, the best mainstream IT can come up with is Java. Which only makes sense when you remember that Java has the highly familiar C syntax.
Apparently, backward compatibility warts aren't just for processor architectures.
[1]: https://en.wikipedia.org/wiki/History_of_programming_languag...
That's it: it's all in the selection process. If you select for the wrong reasons (such as "please the manager"), you'll get sub-par results.
Now, if we could tell for a fact that many technologies are selected for the wrong reasons, it would probably explain a good deal of the huge gap there is between "real world" IT and the state of the art. Think of it for a minute: in the 70s, we had Smaltalk, Scheme, and ML¹. Twenty freaking years later, the best mainstream IT can come up with is Java. Which only makes sense when you remember that Java has the highly familiar C syntax.
Apparently, backward compatibility warts aren't just for processor architectures.
[1]: https://en.wikipedia.org/wiki/History_of_programming_languag...
>>It's built to sell well to IT managers, not be productive and fun to use, because the people who will actually work with the product don't get a vote.
I work as a Sales Engineer in an enterprise software company, and my experiences have been the exact opposite. We win many deals because our competitors' products are nowhere as user-friendly as ours. When I give demos or do consultation calls, more often than not the audience contains at least one person who will use the software in their day-to-day job. And if that person is a department head, then they will have the ability to veto the sale regardless of how much the IT Manager or even the CIO/CTO loves it.
I've also seen situations where the customer bought a competitor's software, only to replace it with ours a short while later because user adoption with the other software turned out to be so atrocious. Those customers end up learning valuable lessons on why end-users should get votes in software purchasing decisions.
I work as a Sales Engineer in an enterprise software company, and my experiences have been the exact opposite. We win many deals because our competitors' products are nowhere as user-friendly as ours. When I give demos or do consultation calls, more often than not the audience contains at least one person who will use the software in their day-to-day job. And if that person is a department head, then they will have the ability to veto the sale regardless of how much the IT Manager or even the CIO/CTO loves it.
I've also seen situations where the customer bought a competitor's software, only to replace it with ours a short while later because user adoption with the other software turned out to be so atrocious. Those customers end up learning valuable lessons on why end-users should get votes in software purchasing decisions.
> the drug dealers that the Cadillac was designed for
Um.
This article seems more about rich geeks' love of sports cars, and telling themselves that their ostentatious toys are a reflection of refined sense and not of being nouveaux riche.
Porsche seems rather impractical for a family of 4 with luggage in the trunk.
Um.
This article seems more about rich geeks' love of sports cars, and telling themselves that their ostentatious toys are a reflection of refined sense and not of being nouveaux riche.
Porsche seems rather impractical for a family of 4 with luggage in the trunk.
The 911 is timeless for a number of reasons: Porsche have spent years keeping the brand and style consistent. It was expensive and exclusive, which made it desirable.
But that care was very hard to drive. If you don't know what you're doing then you will not get anything like the true performance it can give.
It was also very expensive, so only those with the adequate resources could afford one. These were not always people who could get the true performance out of the car.
The Cad, on the other hand, is a fantastic car in its own right. Widely available, easy to get its maximum performance, perfect for almost any job. OK, so it doesn't look as sexy, and for seriously hardcore tasks it doesn't perform as well as the Porsche. But if I had to pick a car that was most likely to be reliable today then the Cad is an obvious choice.
Even more damning; Caddillac, like Porsche and the 911, were still making that brand of car up till ~2006. You wouldn't recognise it though because the shape and performance has evolved to meet modern needs.
It's sad to see his list of languages; whilst I would agree C is a ridiculously good language, smalltalk and lisp? They've always struck me as pretty specialist. Conversely a lot of production code still uses Cobol and Pascal. And what about Fortran? Or Delphi (wasn't Skype written in Delphi originally?).
I know we're hackers, and so it's hip to drive Prosche's. But it is sometimes sad to see how we forget about a massive section of our industry who also do cool things, but tend not to have blogs...