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

81–90 of 200 posts

Re: Ask PG: Lisp vs Python (2010)

#81

Post by lispm »

sedachv wrote: post #80
lispm wrote: post #63

Earlier quoted context omitted.

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…

"The first stage is implemented by the 'reader' and can be reprogrammed by an ancient API to the reader via read tables." Readtables aren't any more ancient than the rest of ANSI INCITS 226-1994 (R2004) (the language standard formerly known as X3.226-1994 (R1999)), but the interface to them is very low-level and non-modular. The current readtable is specified by a dynamic variable, so the readtable facility can be ma…

Read tables existed before CL. CLOS for example not, it was developed for ANSI CL (based on experience with LOOPS and Flavors). See for example READTABLE in Maclisp:

http://maclisp.info/pitmanual/io.html#16.2.7

Also note that I wrote that the API is ancient. It is. It is old and could be easier to use.

'Named readtables' are related to 'syntaxes' on the Lisp Machine. For example source files have a syntax attribute in the header, which switches between the various Lisp dialects (or other languages), including using different readers. This is for example used by the file compiler and Zmacs.

Re: Ask PG: Lisp vs Python (2010)

#82

Post by swannodette »

metageek wrote: post #66
pg wrote: post #43

This question sounds like it's from 2005 rather than 2010. Lisp seems to have become fashionable again now, thanks to Clojure. I'm sure Python has very good libraries, but I would find it constraining to program in a language without proper macros.

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.

What about Qi? What about Typed Racket?

Re: Ask PG: Lisp vs Python (2010)

#83

Post by sedachv »

pjscott wrote: post #61
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…

It's funny, but the thing I miss most from Common Lisp when I write in other languages is the LOOP macro. It's ugly, and non-lispy, but most loops I have to write can be expressed clearly and concisely using LOOP, and writing the equivalent code in another language is annoying. I'm tempted to create a LOOP clone for Clojure, then laugh villainously as I unleash it upon the world.

Loop, like structured editing (Paredit), is one of those Interlisp things that's very controversial and divisive.

There's tons of really wild ideas in Interlisp that seemed to be the half-baked acid trip ideas of West Coast hippies at the time, that are just starting to become rediscovered in the past couple of years (pervasive undo -> reversible debugging, DWIM-like autosuggestions in more places), and even the implementation techniques used are still innovative (for example the error-trapping implementation of Conversational Lisp (http://docs.google.com/viewer?a=v&q=cache:4GnEnGS2XXkJ:c...) is quite similar to how Geoff Wozniak approached auto-defining functions (http://exploring-lisp.blogspot.com/2008/01/auto-defining-fun...)

Re: Ask PG: Lisp vs Python (2010)

#84

Post by StavrosK »

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…

Hey, we used AIMA (which, oddly, is Greek for "blood") in my undergrad and I loved every page, great book! Thanks for writing it!

Re: Ask PG: Lisp vs Python (2010)

#85

Post by drcode »

poet wrote: post #32
drcode wrote: post #29

Earlier quoted context omitted.

True, but the syntax for all three of these is pretty hairy. Lisps might not be the only languages with macros, but they're the only ones with elegant and easy to use macro systems. You could argue of course this is a moot point, since even Lispers only write macros infrequently. So who cares if it's hard to write one on the rare occasion you need to?

You could argue of course this is a moot point, since even Lispers only write macros infrequently. This simply isn't true. In fact it's so far from the truth it hurts my brain. Well written Lisp applications are in large part (and sometimes mostly) macros. PG once mentioned that the ITA guys said over half of their codebase is (was?) macros.

Can you find the quote? I'd be surprised to learn that.

For my own code, it consists of maybe 10% macros. I would say the same is true for PG's code (for the hacker news app- The arc core libraries have more macros but are a special case.)

Unless, of course, if you mean _calling_ macros- I would agree that Lisp code often has 50% of its calls be macro calls instead of function calls.

Re: Ask PG: Lisp vs Python (2010)

#86

Post by sedachv »

lispm wrote: post #81
sedachv wrote: post #80

Earlier quoted context omitted.

"The first stage is implemented by the 'reader' and can be reprogrammed by an ancient API to the reader via read tables." Readtables aren't any more ancient than the rest of ANSI INCITS 226-1994 (R2004) (the language standard formerly known as X3.226-1994 (R1999)), but the interface to them is very low-level and non-modular. The current readtable is specified by a dynamic variable, so the readtable facility can be ma…

Read tables existed before CL. CLOS for example not, it was developed for ANSI CL (based on experience with LOOPS and Flavors). See for example READTABLE in Maclisp: http://maclisp.info/pitmanual/io.html#16.2.7 Also note that I wrote that the API is ancient. It is. It is old and could be easier to use. 'Named readtables' are related to 'syntaxes' on the Lisp Machine. For example source files have a syntax attribute i…

Cool, I didn't know readtables were in Maclisp, or about LM syntaxes.

"It is old and could be easier to use."

Aside from something like named-readtables, how would you design the lowest-level interface to readtables? Or you wouldn't do that, and just specify something like named-readtables to be the interface? I'm curious because this could be something for http://www.cliki.net/Proposed%20Extensions%20To%20ANSI

Re: Ask PG: Lisp vs Python (2010)

#87

Post by deadwisdom »

aidenn0 wrote: post #71
deadwisdom wrote: post #67

Earlier quoted context omitted.

The Python philosophy is that macros do more harm than good, making it harder for someone to read/understand your code in the long term. These and other "constraints" make the code more accessible to others and even yourself.

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 like Python.

I also don't mean to imply that Lisp is lesser for using macros. I love Lisp and any implementation clearly requires macros. But Lisp is also, undeniably, harder to read for this and other reasons.

Re: Ask PG: Lisp vs Python (2010)

#88

Post by lispm »

sedachv wrote: post #83
pjscott wrote: post #61

Earlier quoted context omitted.

It's funny, but the thing I miss most from Common Lisp when I write in other languages is the LOOP macro. It's ugly, and non-lispy, but most loops I have to write can be expressed clearly and concisely using LOOP, and writing the equivalent code in another language is annoying. I'm tempted to create a LOOP clone for Clojure, then laugh villainously as I unleash it upon the world.

Loop, like structured editing (Paredit), is one of those Interlisp things that's very controversial and divisive. There's tons of really wild ideas in Interlisp that seemed to be the half-baked acid trip ideas of West Coast hippies at the time, that are just starting to become rediscovered in the past couple of years (pervasive undo -> reversible debugging, DWIM-like autosuggestions in more places), and even the impl…

LOOP is not from Interlisp. It comes straight from Maclisp.

'LOOPS' from Interlisp is something entirely different: an object-oriented extension to Interlisp.

Re: Ask PG: Lisp vs Python (2010)

#89

Post by ssp »

aidenn0 wrote: post #71
deadwisdom wrote: post #67

Earlier quoted context omitted.

The Python philosophy is that macros do more harm than good, making it harder for someone to read/understand your code in the long term. These and other "constraints" make the code more accessible to others and even yourself.

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…

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.

Re: Ask PG: Lisp vs Python (2010)

#90

Post by spenrose »

Keyframe wrote: post #65
spenrose wrote: post #36

Earlier quoted context omitted.

Is it possible you're comparing lines of code directly? The "size" of a code base is tricky to define, but many people accept a rough rule of thumb that a project of complexity X that might require, say, 10K LOC in competent/straightforward C would require say 2K LOC in competent/straightforward Python/Ruby/etc. The implication is that an average 10K LOC Python program would in fact be a more complicated program than…

I can't really describe it. It's as if literal size grows, it's harder for me to wrap my head around what is where and why - I suspect it is due to the fact I don't write very pythonic code... more like I'm writing C code with Python syntax, if you know what I mean. I am not particularly familiar with python too, I should educate myself properly, dwell more into it though. I only get by for what I need to do in Maya…

Ah, right, different problem. There's much to be said and disputed about what makes a 10K program Pythonic; my oversimplification would be something like: - between half a dozen and two dozen files in 2-3 directory levels - lots of small classes with short methods - some short functions - lots of dictionaries - no God objects - some comprehensions, generators, and decorators - about 2-4 levels of abstraction between the problem statement and the core routines in inner loops - pivot away from any of the above if the problem calls for it, but many problems don't

Even simpler: if you're writing short callables (functions/methods, mostly) and using them as the values in dictionaries, you're most of the way to writing intermediate Python.

Post reply on HN