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

161–170 of 200 posts

Re: Ask PG: Lisp vs Python (2010)

#161

Post by Goladus »

masklinn wrote: post #146
Goladus wrote: post #122

Earlier quoted context omitted.

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)

I never said there was confusion. The headache comes when you're trying decide whether to present an interface to a mapping function as a collection, an object, or a function.

Re: Ask PG: Lisp vs Python (2010)

#162

Post by tome »

pg wrote: post #72
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 did mention in the original essay that it was only a partial order, in footnote [4].

Ah, but metageek's point is that it's not an order at all. It contains cycles.

Re: Ask PG: Lisp vs Python (2010)

#163

Post by apgwoz »

illumen wrote: post #100
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.

Macros can be used in python. There are a few libraries that help make it easier(so you do not need to manipulate the ast yourself). For example: @macro def macroname(arg1, arg2): ... macro contents ... There's some current information for you old time lispers, so next time you don't sound so dated in your Battles with Trolls in the great never ending language war flames ;)

Link? The only "macro" library I've seen for python has been "MetaPython" (http://metapython.org/), which is more of a let down than it is useful, unfortunately.

Re: Ask PG: Lisp vs Python (2010)

#164

Post by metageek »

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)

Y'know, I'm not sure. Next time I need to use a hash, I'll create something like that and see how it feels.

Re: Ask PG: Lisp vs Python (2010)

#165

Post by kung-fu-master »

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

Earlier quoted context omitted.

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…

There are such DSLs on top of Common Lisp. But usually not on the scope of a full programming language like Pascal. It is not that typical anymore, but there are examples in that direction. LOOP shows some of the practical problem. For example for LOOP one needs a custom highlighter in the IDE, because it has its own complex syntax, which does not follow the basic Lisp model. Same for indentation / code formatting. T…

There are such DSLs on top of Common Lisp. But usually not on the scope of a full programming language like Pascal. It is not that typical anymore, but there are examples in that direction.

---------------------------

I have found two examples:

1. Python in Lisp: http://github.com/franzinc/cl-python

2. Ruby on Lisp: http://jng.imagine27.com/articles/2010-10-07-084756_ruby_sub...

I will try to write little subset of Pascal as eDSL on Lisp.

Re: Ask PG: Lisp vs Python (2010)

#166

Post by metageek »

the_paul wrote: post #98
metageek wrote: post #39

Earlier quoted context omitted.

9. INSERT MACRO RANT HERE Macros are the main reason I decided to create Adder, a Lisp-on-Python with minimal impedance mismatch. Unfortunately, the first macro-heavy program I wrote turned out to be really slow, because macros engage the compiler, which, of course, is in Python. When I first tried it, it took something like 50s at 2.4GHz, virtually all of which was the compiler. (The compiler runs at load time; obvi…

Macros were also the reason I wrote Noodle, which was a similar effort (Lisp compiling to Python bytecode) back around 2004. The project died when I couldn't figure out sane, easy-to-learn rules about how to make macros live with modules and imports, and I found I didn't like the syntax concessions I had to allow to make attribute access less of a terrible pain. I still think something like this would be worthwhile,…

and I wish you the best of luck! I particularly like your (.bar.baz foo) syntax.

Thanks!

And good on you for moving away from bytecode generation; I also found that to be a dead end.

Glad to hear I'm not the only one. :-)

So what are your plans for macros+namespaces? Will macros from imports live in the same namespace?

Actually, I hadn't thought about it--I haven't gotten to the point of being able to write modules in Adder. I think I see what you mean, though: any module has to be a Python module, so macros would have to be expressed as functions.

Strawman: the module could contain a variable listing the macros. When compiling an (import) form, the Adder compiler would check the imported module for that list, and update its internal structures accordingly.

And what did you mean by "Python supports only two levels of lexical scope"

That was a mistake; I've removed it. I think maybe I just didn't figure out how to generate bytecode for a triply nested function.

Of course, there is the remaining problem that Python can't define a scope without defining a function. I didn't want to use the standard tactic for turning (let) into a nested function (I don't trust Python functions to be fast enough), so the current compiler uses name mangling, tagging each variable with the scope depth. (Global variables are untagged, so that they can be accessed cleanly by Python modules.)

Re: Ask PG: Lisp vs Python (2010)

#167

Post by draegtun »

For the macro side of things you may find these two old HN posts of interest:

* Why Lisp macros are cool, a Perl perspective (2005) http://news.ycombinator.com/item?id=795344

* Can a language have Lisp's powerful macros without the parentheses? http://news.ycombinator.com/item?id=9172

Re: Ask PG: Lisp vs Python (2010)

#168

Post by lispm »

kung-fu-master wrote: post #165
lispm wrote: post #160

Earlier quoted context omitted.

There are such DSLs on top of Common Lisp. But usually not on the scope of a full programming language like Pascal. It is not that typical anymore, but there are examples in that direction. LOOP shows some of the practical problem. For example for LOOP one needs a custom highlighter in the IDE, because it has its own complex syntax, which does not follow the basic Lisp model. Same for indentation / code formatting. T…

There are such DSLs on top of Common Lisp. But usually not on the scope of a full programming language like Pascal. It is not that typical anymore, but there are examples in that direction. --------------------------- I have found two examples: 1. Python in Lisp: http://github.com/franzinc/cl-python 2. Ruby on Lisp: http://jng.imagine27.com/articles/2010-10-07-084756_ruby_sub... I will try to write little subset of P…

Usually these languages like Python are implemented on top of Lisp using a special parser. Of that there are many, from C, Python to special research languages. Then there are a lot of languages with lispy syntax. Typical examples were Prolog dialects with Lisp syntax (and optional Prolog syntax). The example that languages are embedded into a single s-expression (like in the LOOP macro) is also possible, but different. It would not make sense to use Python that way, since the low level syntax of Python is different from what Lisp s-expressions provide. For example s-expressions are not preserving any textual layout (indentation) when read - something that a language that uses indentation in its syntax would need, but would not get from being embedded in a single s-expression.

Re: Ask PG: Lisp vs Python (2010)

#169

Post by chaitanya »

metageek wrote: post #112
DanWeinreb wrote: post #93

Earlier quoted context omitted.

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…

> I haven't used much CLOS, since ITA avoids it.

Interesting. Is it for performance reasons?

Re: Ask PG: Lisp vs Python (2010)

#170

Post by ohyes »

metageek wrote: post #112
DanWeinreb wrote: post #93

Earlier quoted context omitted.

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…

'True. I need to remember to be more precise; "doesn't have strong typing" just means "doesn't have type feature Blub". '

That might be less precise, but more correct :-P.

"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 type declarations aren't just for efficiency (although they are frequently (ab)used for it).

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

I'm not sure what common lisp version you use, but wouldn't this be fixed by simply declaring types of everything? You can declare the types of on the slots of a struct, you can declare the types of arguments to functions, results of functions, variables, slots of objects, contents of sequences... (having trouble thinking of something you can't declare types on, maybe a hashtable? Although you could wrap the accessors in a function).

Then SBCL (at least) yells at you when you go to recompile the project.

Post reply on HN