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

141–150 of 200 posts

Re: Ask PG: Lisp vs Python (2010)

#141

Post by lisper »

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.

> in Lisp and C++ I miss dictionary literals

So roll your own. Or use mine:

http://flownet.com/ron/lisp/dictionary.lisp

Re: Ask PG: Lisp vs Python (2010)

#142

Post by akkartik »

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.

Why do you miss dictionary literals? Syntax similar to arc's seems to do it for me:

  (obj a 1 b 2 c 3)

Re: Ask PG: Lisp vs Python (2010)

#143

Post by lisper »

kung-fu-master wrote: post #119
gigamonkey wrote: post #45

Earlier quoted context omitted.

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.

http://rondam.blogspot.com/2008/02/joy-of-iterators.html

This lets you write things like:

(for var in form do ...

or

(for var in form collect ...

where form can be anything that has an iterator method defined on it.

There's also a macro I use called BINDING-BLOCK (BB for short) which subsumes a bunch of binding forms. So you can write things like:

(bb

  x (...)

  y (...)

  :db (q r s) (...) ; Destructuring-bind

  :mv (p q) (...) ; Multiple-value-bind

  ...
It's extensible so you can add your own clauses. Code is here:

http://www.flownet.com/ron/lisp/rg-utils.lisp

(It's a little out of date. If you want the latest let me know and I'll update it.)

Re: Ask PG: Lisp vs Python (2010)

#144

Post by masklinn »

lisper wrote: post #140
masklinn wrote: post #109

Earlier quoted context omitted.

> 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?

> Uh no it doesn't. Uh, yes it does. > Python uses OS threads. It cripples them with the GIL And CCL doesn't. QED. > using green threads can be an advantage Not if you have multiple cores. > What? http://www.youtube.com/watch?v=snW3cM1KipQ ;-)

> Uh, yes it does.

That makes no sense, having the exact same feature doesn't make CCL superior.

> And CCL doesn't. QED.

QED nothing, not having a gil does something, using OS threads doesn't.

> Not if you have multiple cores.

Yes if you have multiple cores as well. You just have to map your green threads onto OS threads or processes, that's what Erlang does.

> ;-)

Smileys don't give meaning to nonsense.

Re: Ask PG: Lisp vs Python (2010)

#145

Post by masklinn »

lispm wrote: post #136
masklinn wrote: post #109

Earlier quoted context omitted.

> 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?

CCL has no GIL.

Which has absolutely nothing to do with the original claim that:

> it has native threads (that feature alone puts it head-and-shoulders over Python)

As I wrote previously (and both you and lisper apparently decided to ignore), Python uses OS threads as well.

Re: Ask PG: Lisp vs Python (2010)

#146

Post by masklinn »

Goladus wrote: post #122
masklinn wrote: post #111

Earlier quoted context omitted.

> 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)

They are all mapping functions, though. You have a key 'k', which is accepted by d and will return a unique result. Why should I have to care whether d is a collection, object, or method? In fact in many cases it's pretty easy to implement all three. class months(object): def __init__(self): m='jan feb mar apr may jun jul aug sep oct nov dec'.split(' ') n=range(1,13) self.__dict__.update(dict(zip(m,n))) def __getitem…

> 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)

#147

Post by bad_user »

draegtun wrote: post #69
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?

Io ( http://www.iolanguage.com ) is a bit of an exception then. Its homoiconic but its not a Lisp. And it doesn't have macros yet its code is fully inspectable/modifiable at runtime in an very easy & elegant way. For eg. if you wanted to have a line like this: list(1, 2, 3) each foo bar which needs to be transformed into below at runtime: list(1, 2, 3) foreach(foo bar) Then this can be done like so: List each := meth…

Does it have lazy evaluation?

Re: Ask PG: Lisp vs Python (2010)

#148

Post by joordaz »

varikin wrote: post #129
jules wrote: post #114

Earlier quoted context omitted.

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

What makes it possible to launch 10% faster? Is it familiarity with the language, tools, libraries, and frameworks? Is it that the language is more dynamic and requires less to accomplish task X? I would say yes to both questions. Now with the first question, familiarity with the language, lets discuss Python. Python is my language of choice. I know it, I use it, I pay attention to what is happening with the language…

What makes it possible to launch 10% faster? what about a better understanding of the problem you are solving? just my 2 cents :p

Re: Ask PG: Lisp vs Python (2010)

#149

Post by MageSlayer »

kung-fu-master wrote: post #139
lispm wrote: post #134

Earlier quoted context omitted.

sure, that's possible - just see the LOOP macro...

Then, why no one still not made such eDSL? As I understand, the only reason to choose Python for Peter Norvig was the similarity of Python to pseudo-code. I think that such great hacker as Peter Norvig could easily develop pseudo-code eDSL on top of Lisp macro-system. As school teacher on programming I'm limited in choice of programming languages. The only language which I can study is Pascal (a lot of other reasons…

>The problem is that Pascal have not any libraries (GUI, 2D/3D, Game Development Engines, programming micro-controllers, ...).

It's not true. Lazarus (http://www.lazarus.freepascal.org/) gives pretty much everything Delphi has. Currently I develop OpenGL 2D analytical tool. Again GUI is on par with Delphi.

Re: Ask PG: Lisp vs Python (2010)

#150

Post by gruseom »

akkartik wrote: post #142
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.

Why do you miss dictionary literals? Syntax similar to arc's seems to do it for me: (obj a 1 b 2 c 3)

We do the same thing:

  (make :a 1 :b 2 :c 3)
which macroexpands into a plist in CL and {a:1, b:2, c:3} in JS. I've grown to like this idiom a lot. Yeah, you have to type OBJ or MAKE or whatever but in return you get something that integrates completely smoothly with the rest of the language.
Post reply on HN