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

Ask PG: Lisp vs Python (2010)

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 200 posts

Re: Ask PG: Lisp vs Python (2010)

#101

Post by beza1e1 »

francoisdevlin wrote: post #7

I'm a Clojure guy that just wrote my first Pylons app. Here's my impression: 1. Python doesn't suck. I was able to mix FP & OOP approaches to get to my goal fairly quickly. 2. iPython was fun to use, helped out a lot, but it's not SLIME. 3. Guido has an excellent goal with making code readable, and significant white space is not a bad choice. However, I find being able to analyze active data structures in a Clojure n…

  6. I would like to see more FP constructs natively available in Python.
FP constructs such as? Map is there. Reduce is one import away. There is nice syntax for list comprehensions. What do you miss?

Re: Ask PG: Lisp vs Python (2010)

#102

Post by masklinn »

DanWeinreb wrote: post #96
norvig wrote: post #23

Peter Norvig here. I came to Python not because I thought it was a better/acceptable/pragmatic Lisp, but because it was better pseudocode. Several students claimed that they had a hard time mapping from the pseudocode in my AI textbook to the Lisp code that Russell and I had online. So I looked for the language that was most like our pseudocode, and found that Python was the best match. Then I had to teach myself eno…

Peter, you imply that Python is better for, or more like, pseudo-code, but why is it better? In my opinion, it is better for most people because they were taught syntaxes more like that of Python than that of Lisp. An important factor in easy-of-understanding is to be similar to something you are already familiar with. To the extent that this is the reason, it's not implicit in Lisp vs. Python, but rather more a ques…

> Peter, you imply that Python is better for, or more like, pseudo-code, but why is it better?

Well from what he writes, he seems to say Python looks much closer to their actual pseudo-code, and it's therefore easier for students to translate pseudocode to Python than to Lisp.

> In my opinion, it is better for most people because they were taught syntaxes

Such as english. One of the original goals of Python (inherited from ABC[0]) was to be a good teaching language. I'd expect that when Peter talks about his students, he's mostly talking about students with low-to-no knowledge in programming. Those who are already knowledgeable probably don't have a hard time adapting.

[0] http://en.wikipedia.org/wiki/ABC_(programming_language)

Re: Ask PG: Lisp vs Python (2010)

#103

Post by masklinn »

metageek wrote: post #78
jcromartie wrote: post #75

Earlier quoted context omitted.

I can't help you with strong typing, but I'm pretty sure a macro would go a long way towards implementing RAII in a Lisp.

That's true; we've already got special cases like WITH-OPEN-FILE.

Actually, you already have something better than RAII in unwind-protect. Just create whatever macro you need on top of that (I'm pretty sure with-open-file is just a macro on top of unwind-protect, Siebel seems to agree in his chapter on files) and you're done.

Re: Ask PG: Lisp vs Python (2010)

#104

Post by masklinn »

jcromartie wrote: post #75
metageek wrote: post #66

Earlier quoted context omitted.

The problem with the Blub paradox is that there's no total ordering. I do Common Lisp and C++ at my day job (ITA), and I do much of my personal hacking in Python. In Python and C++ I miss macros; in Lisp and Python I miss RAII and strong typing; in Lisp and C++ I miss dictionary literals. And, in all of them, I miss algebraic datatypes.

I can't help you with strong typing, but I'm pretty sure a macro would go a long way towards implementing RAII in a Lisp.

> I'm pretty sure a macro would go a long way towards implementing RAII in a Lisp.

Well yeah, just build the macro you need on top of unwind-protect, that's pretty standard common lisp fare.

Re: Ask PG: Lisp vs Python (2010)

#105

Post by ssp »

DanWeinreb wrote: post #95
ssp wrote: post #89

Earlier quoted context omitted.

The argument is that macros have non-local effects; they interact with the code in which they are applied. This means that the macro definition and the code surrounding the macro invocation can't necessarily be understood in isolation. This is also essentially the argument against global variables.

A function definition is, in general, far away from the function call. If you think this problem is more severe for macros than for functions, then you should articulate why. You may well have a very valid point in your mind but I think it needs to be expressed somewhat more specifically.

For non-hygienic macros, it's essentially the variable capture problem.

For hygienic macros, I don't know of a good argument that they are inherently more difficult to understand separately from their invocation than a function.

(I'm not personally arguing against macros - or global variables for that matter - just trying to state the argument).

Re: Ask PG: Lisp vs Python (2010)

#106

Post by masklinn »

francoisdevlin wrote: post #7

I'm a Clojure guy that just wrote my first Pylons app. Here's my impression: 1. Python doesn't suck. I was able to mix FP & OOP approaches to get to my goal fairly quickly. 2. iPython was fun to use, helped out a lot, but it's not SLIME. 3. Guido has an excellent goal with making code readable, and significant white space is not a bad choice. However, I find being able to analyze active data structures in a Clojure n…

> significant white space

Nit: significant indentation. Mostlanguageshavesignificantwhitespace, somemorethanothers (for instance, at least in 1.8, Ruby seems to have more whitespace issues than Python)

Re: Ask PG: Lisp vs Python (2010)

#107

Post by ntoshev »

lispm wrote: post #63
ntoshev wrote: post #55

There is a language and there is an ecosystem surrounding it (libraries, community, etc). Ignoring the ecosystem, the question "to lisp or not to lisp" pretty much boils down to "syntax or macros" - if you want macros, you go with a lisp, if you want syntax, you go with Python or another modern language. I used to think macros matter more than syntax, because you can freely define your own micro-languages. I didn't r…

Lisp has a lot syntax. It is just a bit different and it looks different externally. Lisp has a 2-stage syntax. The first stage is the syntax of s-expressions , which is surprisingly complex. S-Expressions provide a textual syntax for data: symbols, lists, pairs, strings, various number formats, arrays, characters, pathnames, ... The first stage is implemented by the 'reader' and can be reprogrammed by an ancient API…

You are right of course, but this kind of syntax doesn't help the programmer to cognitively parse the code, which is what I am talking about.

Re: Ask PG: Lisp vs Python (2010)

#108

Post by poet »

chromatic wrote: post #57
poet wrote: post #26

Earlier quoted context omitted.

If your language doesn't have Lisp syntax (or more precisely, a lack of syntax entirely) writing macros will be very unpleasant. How are you going to logically think about manipulating the structure of a program that looks like C# or Perl? Macros are already difficult enough to get right as is, without introducing the problem of syntax. Those languages don't have macros any more than Python has a lambda.

How are you going to logically think about manipulating the structure of a program that looks like C# or Perl? In Perl 6, you extend the active grammar within a delimited scope.

My point still holds, just replace manipulating the structure of a program with manipulating the structure of a grammar. In no way is that comparable to manipulating raw parse trees.

Re: Ask PG: Lisp vs Python (2010)

#109

Post by masklinn »

lisper wrote: post #58
zatara wrote: post #41

Earlier quoted context omitted.

Could you elaborate a little more on CCL? I thought it was mainly used to access Cocoa frameworks, but maybe things have changed since the last time I checked it. Are there any chances it can now work with Cocoa touch?

CCL has very good ObjC/Cocoa integration, and a well integrated IDE. But it also runs on Linux and Windows, it has native threads (that feature alone puts it head-and-shoulders over Python), and it has a wicked fast compiler. So it makes a kick-ass webapp development platform. I don't know about Cocoa touch, but the CCL compiler was recently ported to run on ARM processors.

> that feature alone puts it head-and-shoulders over Python

Uh no it doesn't. Python uses OS threads. It cripples them with the GIL (hence multiprocessing), but it never used green threads.

And of course, using green threads can be an advantage if you're not dumb about it (see Erlang).

> it has a wicked fast compiler. So it makes a kick-ass webapp development platform.

What?

Re: Ask PG: Lisp vs Python (2010)

#110

Post by aidenn0 »

deadwisdom wrote: post #87
aidenn0 wrote: post #71

Earlier quoted context omitted.

Macros are just another abstraction tool. If you poorly use an abstraction tool, it makes the code harder to read, if you properly use an abstraction tool, it makes the code easier to read. Here's a function that makes code harder to read: def sumAList(aList): return 7 This doesn't mean that functions are bad. Now there is an argument that macros make code harder to read in that I've yet to see a really good macro sy…

Yes, but any given function is usually extremely easy to understand, because it's only, say one level of abstraction, then a macro is a few levels higher than that. And as you go up in your levels of abstraction, it gets harder and harder to really understand what's going on. Sure, some macros are intuitive and easy to follow, but those are usually easily replicated with other things, especially in a dynamic language…

Hmmm. I think your argument is roughly that there is a "sweet-spot" for abstraction when it comes to readability?

That is a point at which less abstraction makes the code harder to read, and more abstraction makes the code harder to read?

I will agree with this in specific cases (i.e. for any given solution, there is a point at which adding abstraction can't improve readability), but I'm not certain I agree in the general case (i.e. that using macros cannot improve readability).

I guess it also depends on what you mean by "really understand what's going on." I started out programming in C. Now in C, if you know your compiler well, you can predict fairly accurately what binary code will be generated when you compile with optimizations off. Moving to higher level-languages you lose this ability, and no longer "really understand what's going on."

For systems programming, I may still use C to get this advantage. For other problem domains, I sacrifice this knowledge because representing my problem more tersely in a higher level language makes the code more readable and easier to understand. Now I will never know exactly which instructions will be executed when I write in Python.

Similarly, with sufficiently fancy macros, I may not know what LISP code is generated, but if the macros do what they say they do, it can make my code less verbose, more understandable, and easier to maintain. There are times when really understanding what is going on trumps the terseness, and those times I don't use macros.

Also, I love Python. It embeds well in C (which is where my original background is), and it has very good portability, and a good set of libraries.

I also implied, but didn't say straight out that Python has a good reason for not having macros: Part of its design is to look like pseudo-code. See also Norvig's comment to the OP. Macros that operate on text rather than trees (C preprocessor, m4, etc) are far more error prone, and probably a Bad Idea. Therefore if you want your language to look like something other than a tree, you have to forsake macros that operate on code as it is written. I have seen for several languages (Python among them I believe) Lisp-like macros that operate on the AST of the language. They have not caught on. I have several theories why this is so, but right now my preferred one is that it feels too much like you're hacking the compiler, and Compilers Are Scary.

Post reply on HN