Ask PG: Lisp vs Python (2010) • Hacker News Board

Re: Ask PG: Lisp vs Python (2010)

#111

Post by masklinn » Mon, Oct 18, 2010, 10:06 PM UTC

Goladus wrote: post #24

I've used Python for about 4 years and am just starting to use Clojure, so I'll just add a few comments that others haven't mentioned. I'm not trying to offer a definitive comparison. Clojure's data structures seem a lot like Python's but are a bit more elegant and avoid many of the little python headaches that come up often like d['k'] vs d.k vs d('k'). In clojure it would be (d :k) or (:k d) and both work. If you n…

> and avoid many of the little python headaches that come up often like d['k'] vs d.k vs d('k').

When does that come up? d['k'] is a key access (to a collection), d.k is an attribute access (to an object) and d('k') is a method call. I'm not sure where the headache/confusion would be here, unless you're trying to do very weird things with Python (which you should not)

Re: Ask PG: Lisp vs Python (2010)

#112

Post by metageek » Mon, Oct 18, 2010, 10:07 PM UTC

DanWeinreb wrote: post #93

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.

Hello, my co-worker, whoever you are. Yes, Common Lisp should have dictionary literals. I don't know why there hasn't been a commonly-used reader macro for this. (Emacs Lisp mode and other tools would have to know about it, so it needs to be a widely-accepted convention.) Common Lisp does have strong typing. What it does not have is static typing. I am at the SPLASH conference, and the Dynamic Language Symposium is h…

Hello, my co-worker, whoever you are.

John Stracke. (I've been staying pseudonymous, but today I mentioned Adder, which is tied to my real identity.)

Common Lisp does have strong typing.

True. I need to remember to be more precise; "doesn't have strong typing" just means "doesn't have type feature Blub". Common Lisp has runtime type safety, and type hints for efficiency; what it does not have is the pervasive typing that I'm used to from C++, which has a separate set of benefits. The most obvious is that, in C++, I can change the interface to a class and be certain that the compiler will catch any caller that uses it incorrectly. (Although I suppose it may be possible to do something like that with CLOS. I haven't used much CLOS, since ITA avoids it.)

There is controversy over whether we can find a way to have the benefits of both static and dynamic typing in the same language.

I'd say that type inference already brings us nearly there: the convenience of dynamic typing, with the rigor of static typing.

I may be wrong, though; I've used ML and Haskell, but not enough to really feel where the pain points of type inference are.

Re: Ask PG: Lisp vs Python (2010)

#113

Post by lispm » Mon, Oct 18, 2010, 10:08 PM UTC

ntoshev wrote: post #107

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…

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.

No, why not?

I can parse Lisp quite good.

Re: Ask PG: Lisp vs Python (2010)

#114

Post by jules » Mon, Oct 18, 2010, 10:09 PM UTC

edw519 wrote: post #46

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…

In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your languag…

OTOH, it's not completely irrelevant. If you can launch 10% faster, that's a big advantage.

Re: Ask PG: Lisp vs Python (2010)

#115

Post by jules » Mon, Oct 18, 2010, 10:18 PM UTC

ssp wrote: post #89

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…

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.

If you want local reasoning you will have to reject Turing completeness, otherwise you could implement a language with global variables and eval a bunch of code in that language.

I think we shouldn't be limiting our tools. We should instead limit their use. Global variables can be nasty, but it's nice to have them when your code is best expressed with global variables. Same for macros.

Re: Ask PG: Lisp vs Python (2010)

#116

Post by sedachv » Mon, Oct 18, 2010, 10:21 PM UTC

lispm wrote: post #88

sedachv wrote: post #83

Earlier quoted context omitted.

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.

I'm going by the Hyperspec and what I remember from reading Kaisler's Interlisp. From the former:

"One of the Interlisp ideas that influenced Common Lisp was an iteration construct implemented by Warren Teitelman that inspired the loop macro used both on the Lisp Machines and in MacLisp, and now in Common Lisp."

http://www.lispworks.com/documentation/HyperSpec/Body/01_ab....

Re: Ask PG: Lisp vs Python (2010)

#117

Post by cdavid » Mon, Oct 18, 2010, 10:40 PM UTC

drunkpotato wrote: post #30

cdavid wrote: post #12

Earlier quoted context omitted.

At least P. Norvig things python is an acceptable language, if not LISP. I think the point about being optimized for small teams is a significant one. Also, because LISP appeals mostly to programmers, but it often "repeals" people with expert knowledge (e.g. scientists without a strong programming background). P. Norvig mentioned that when he converted his AI book from Lisp to python code examples, it seemed much mor…

I think you meant "repels", unless you meant "refudiates", though perhaps your finger stumbled in the middle of "repls".

I have at least the excuse of not being a native speaker, contrary to S. Palin :) Thanks for the correction.

Re: Ask PG: Lisp vs Python (2010)

#118

Post by sedachv » Mon, Oct 18, 2010, 10:47 PM UTC

lispm wrote: post #99

sedachv wrote: post #86

Earlier quoted context omitted.

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

I haven't thought about it much, but the character level interface is very primitive. Second, what about things like symbols, numbers, etc.? There is no sane way to specify number syntax or symbol syntax. That might be useful. Currently the reader provides an interface on a character level, but not on the level of s-expressions components.

What I think you're saying is that the reader should be customizable in terms of some DSL for a grammar. It would be nice, but I'm not sure how composable it would be (in the general case, I think it would come down to having the behavior of READ dependent upon a black-box current-parser procedure).

The nice thing about readtables is that it exposes what in essence are transition hooks for each character, so you really don't need to care about the grammar of stuff you're not interested in parsing.

OTOH like you said, extending the syntax for numbers or symbols becomes quite hairy. But even with a DSL grammar approach, you'd need to change major parts of the grammar (which means copying and modifying the normative grammar of CL syntax - not that different from grabbing a portable CL reader implementation today (http://twitter.com/vsedach/status/26484049015)).

The big downside is deciding on which class of grammars that will support, and how they will be represented.

Re: Ask PG: Lisp vs Python (2010)

#119

Post by kung-fu-master » Mon, Oct 18, 2010, 11:18 PM UTC

gigamonkey wrote: post #45

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…

I've had a similar experience, lately while writing and editing pieces for Code Quarterly--I've written the same basic algorithms in Javascript, Python, and Common Lisp to play around with them. I find the Python the best vehicle for conveying the algorithms despite being more fluent in Common Lisp. But I've also been astounded at how slow CPython is compared to SBCL (the Common Lisp implementation I use) when I have…

I'm not a Lisp expert, so I have another question. Is it possible to embed DSL into Lisp which will looks like pseudo-code?

For example:

(pseudo

    a = 0

    b = 100

    s = 0

    for (i from a to b)

        s = s + i

    write(s)

)

If such pseudo code can be embedded into SBCL it would generate fast machine code, also it would be possible to easily modify pseudo code syntax.

Re: Ask PG: Lisp vs Python (2010)

#120

Post by sedachv » Mon, Oct 18, 2010, 11:21 PM UTC

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…

"And as you go up in your levels of abstraction, it gets harder and harder to really understand what's going on."

There is a difference between abstraction and indirection. Just because you've added the latter doesn't mean you've gained any of the former.

"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."

How would you implement SETF in Python? Or how about compile-time link checking for a web application (http://carcaddar.blogspot.com/2008/11/compile-time-inter-app...)?