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

Lisp vs Python

amitp.blogspot.com

Post reply on HN
Print view View original

21–30 of 98 posts

Re: Lisp vs Python

#21

Post by [deleted] »

nostrademons wrote: post #20
stcredzero wrote: post #19

Earlier quoted context omitted.

You realize that this poster is Google employee #7, responsible for "Don't be evil" (along with Paul Buchheit), and wrote the first prototype for Google Instant back in 1999? Why, are you arguing from authority on his behalf? In that case, I say he should know better! (That's a stand worth burning some karma on!) tl;dr - If you are going to criticize language X, first take the time to learn the best practices of lang…

No, I'm arguing against the ad hominem that forms the second half of your original post. The first half of your post was great. It addresses the arguments directly, and I completely agree. In the second half, you then go on to make assumptions about the programmer's experience and aptitude - assumptions that I've shown are quite false. If you want to debate the merits of an argument, debate the merits of an argument,…

[deleted]

Re: Lisp vs Python

#22

Post by Teckla »

j_baker wrote: post #18

> Lisp seems to be optimized for writing code; Python seems to be optimized for reading it. Urgh... A hundred times no. I really do appreciate that the author seems to have given Lisp a try. But this is simply wrong. Why does Lisp provide macros? Because they make code easier to read. I say stop focusing on what language abstraction (f x) represents and focus on figuring out what the code is doing . Oh well, at least…

"Oh well, at least he didn't complain about lisp having too many parenthesis."

Humans are visual creatures. It really is easy to get lost in Lisp's parentheses.

Languages whose blocks are easier to identify at a glance really are easier to read.

The attitude of far too many Lisp developers seems to be that Lisp has failed to dominate after all these many decades because people are just too stupid to realize how great Lisp is.

If Lisp hasn't dominated by now, rather than arrogance and superiority, it would be better to think about why Lisp continues to fail to dominate.

By the way, I'm not suggesting you're one of those people.

Re: Lisp vs Python

#23

Post by euccastro »

nostrademons wrote: post #20
stcredzero wrote: post #19

Earlier quoted context omitted.

You realize that this poster is Google employee #7, responsible for "Don't be evil" (along with Paul Buchheit), and wrote the first prototype for Google Instant back in 1999? Why, are you arguing from authority on his behalf? In that case, I say he should know better! (That's a stand worth burning some karma on!) tl;dr - If you are going to criticize language X, first take the time to learn the best practices of lang…

No, I'm arguing against the ad hominem that forms the second half of your original post. The first half of your post was great. It addresses the arguments directly, and I completely agree. In the second half, you then go on to make assumptions about the programmer's experience and aptitude - assumptions that I've shown are quite false. If you want to debate the merits of an argument, debate the merits of an argument,…

Ad hominem is disqualifying an argument based on attacks to the one making it. The comment you refer to is drawing (perhaps wrong) conclusions about the author of the OP from what he says. Warranted or not, it's not fallacious.

Re: Lisp vs Python

#24

Post by DrJokepu »

I don't know about that. Say what you want about Emacs (personally I'm not a huge fan) it does a pretty good job at syntax highlighting and auto-formatting Lisp source. I never had problems with reading well-written Lisp code in Emacs.

Re: Lisp vs Python

#25

Post by stcredzero »

nostrademons wrote: post #20
stcredzero wrote: post #19

Earlier quoted context omitted.

You realize that this poster is Google employee #7, responsible for "Don't be evil" (along with Paul Buchheit), and wrote the first prototype for Google Instant back in 1999? Why, are you arguing from authority on his behalf? In that case, I say he should know better! (That's a stand worth burning some karma on!) tl;dr - If you are going to criticize language X, first take the time to learn the best practices of lang…

No, I'm arguing against the ad hominem that forms the second half of your original post. The first half of your post was great. It addresses the arguments directly, and I completely agree. In the second half, you then go on to make assumptions about the programmer's experience and aptitude - assumptions that I've shown are quite false. If you want to debate the merits of an argument, debate the merits of an argument,…

"Why did s/he have to write it like that? It's cost us untold thousands of hours in coding around their nasty hacks and poor design decisions." However, I recognize the context they were operating in: they were a tiny startup of about 20 people, trying to organize the world's information.

Yes, but if you're lucky enough to be Google Employee #7, you should now have time to do things like actually do your homework before you post about Lisp.

Just because you're big company coder [single digit] doesn't mean you're necessarily an expert. I actually expect a lot of startup code to be half-baked. Large swathes of the Smalltalk base image code is still egregious, and people have had decades to do something about it and haven't. There were also lots of sophmoric Java API decisions when it first came out.

I don't mistake seniority for expertise, and seniority or friendship with you or anyone in particular doesn't earn anyone a pass with me.

If he knows about but doesn't subscribe to Don't Repeat Yourself then he does a good job of sounding like he just doesn't have a clue and is in the practice of writing lots of boilerplate code. To me, that is a merit of a programming language argument. (In this case demerit.)

Please explain how you can read this post and think the author has a clue about careful name selection? Basically, his major point is predicated on clueless naming in dynamic languages.

Re: Lisp vs Python

#27

Post by comex »

> Python on the other hand has no macros and doesn't give you much to write concise, abstract, elegant code. There's a lot of repetition and many times it's downright verbose. But where Lisp is nice to write and hard to read, Python makes the opposite tradeoff. It's easy to read. You can determine how to interpret something—a string, a list, a function call, a definition—just by looking at the code locally.

This is a great quote. If you replace Python with C and Lisp with C++, it's exactly what I've been trying to articulate (as a C fan) for some time now. In fact, I think it's much more applicable to C than to Python...

Re: Lisp vs Python

#28

Post by euccastro »

mitko wrote: post #11

This is similar to the way I compare Python and Lisp: Common ground: first class functions, a lot of flexibility, closures Lisp: macros, performance? Python: easy to learn by example, readability, batteries included I use Python day-to-day as I don't really need a macro system that much. I also disagree that Lisp is more elegant - beauty is in the eye of the observer. Edit: formatting.

Beauty is subjective; elegance less so. Python is the language I've used and use the most, and I'll easily concede that Scheme is more elegant than almost anything else I've seen, and Python hardly even compares. Metaclasses, decorators, 'for'/'while'/'with' statements, etc. etc. In Python they are all good, practical, powerful ideas. In Scheme they're just unnecessary. Scheme is more elegant because it's been a priority in its design. Python aims to be more practical, beginner-friendly and straightforward.

Re: Lisp vs Python

#29

Post by silentbicycle »

Teckla wrote: post #22
j_baker wrote: post #18

> Lisp seems to be optimized for writing code; Python seems to be optimized for reading it. Urgh... A hundred times no. I really do appreciate that the author seems to have given Lisp a try. But this is simply wrong. Why does Lisp provide macros? Because they make code easier to read. I say stop focusing on what language abstraction (f x) represents and focus on figuring out what the code is doing . Oh well, at least…

"Oh well, at least he didn't complain about lisp having too many parenthesis." Humans are visual creatures. It really is easy to get lost in Lisp's parentheses. Languages whose blocks are easier to identify at a glance really are easier to read. The attitude of far too many Lisp developers seems to be that Lisp has failed to dominate after all these many decades because people are just too stupid to realize how great…

> Languages whose blocks are easier to identify at a glance really are easier to read.

Which is why conventions for indenting Lisp code to show block structure have been established for decades. This problem has been solved for longer than Python has even existed. I don't know why people keep bringing it up. Lisp isn't perfect, sure, but this is a very weak criticism.

Besides, what about mismatched delimiter problems in languages like C that have shift-reduce conflicts? Dangling else problem (http://en.wikipedia.org/wiki/Dangling_else), anyone? It seems disingenuous to complain about mismatched parens in Lisp when those are trivially handled by most decent editors, and the problem is in no way unique to Lisp.

Re: Lisp vs Python

#30

Post by stcredzero »

Teckla wrote: post #22
j_baker wrote: post #18

> Lisp seems to be optimized for writing code; Python seems to be optimized for reading it. Urgh... A hundred times no. I really do appreciate that the author seems to have given Lisp a try. But this is simply wrong. Why does Lisp provide macros? Because they make code easier to read. I say stop focusing on what language abstraction (f x) represents and focus on figuring out what the code is doing . Oh well, at least…

"Oh well, at least he didn't complain about lisp having too many parenthesis." Humans are visual creatures. It really is easy to get lost in Lisp's parentheses. Languages whose blocks are easier to identify at a glance really are easier to read. The attitude of far too many Lisp developers seems to be that Lisp has failed to dominate after all these many decades because people are just too stupid to realize how great…

Languages whose blocks are easier to identify at a glance really are easier to read.

IMO, it's really pointless to toss about theories having to do with readability for this reason or that. Programming languages are also (sub)cultural entities. It doesn't matter how many clever reasons we come up with explaining why people don't like this or that about whatever language. Most of those things are unsubstantiated, so who gives a flying expletive?

What matters is that languages attract audiences of the size they attract. It's a fact of life. It's all we know until some serious psychological/linguistic research happens. Frankly, I'm not sure if enough people care enough about what coders think for it to happen. Maybe they should. In the meantime, we should just shut up and code. (Starting with me. Why did I write so many comments today?)

Post reply on HN