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

151–160 of 200 posts

Re: Ask PG: Lisp vs Python (2010)

#151

Post by gruseom »

aidenn0 wrote: post #110
deadwisdom wrote: post #87

Earlier quoted context omitted.

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 ge…

right now my preferred one is that it feels too much like you're hacking the compiler

I think what you implied just before that is a stronger argument: it's way too distant from the base language, and this semantic distance is so costly that it's not worth the trouble.

Re: Ask PG: Lisp vs Python (2010)

#152

Post by vegai »

jules wrote: post #114
edw519 wrote: post #46

Earlier quoted context omitted.

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.

Also, the language choice might lead one to a slippery slide of platform choice which easily slips into trapping you in an architecture you really did not want.

Re: Ask PG: Lisp vs Python (2010)

#153

Post by gruseom »

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 is crack. Personally I love it.

Could you port CL's LOOP to Clojure easily? Or would its internal hyper-imperativeness make that tricky?

Re: Ask PG: Lisp vs Python (2010)

#154

Post by draegtun »

bad_user wrote: post #147
draegtun wrote: post #69

Earlier quoted context omitted.

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?

Yes. The List each above is acting lazily.

Here is a better example of how it works: http://news.ycombinator.com/item?id=1627777

Re: Ask PG: Lisp vs Python (2010)

#155

Post by draegtun »

bad_user wrote: post #132
poet wrote: post #108

Earlier quoted context omitted.

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.

But you are manipulating parse trees: surely you have to add new grammar rules to the parser, but then the macro itself does just that. Furthermore, when adding syntax you are not limited to a Lisp-style grammar.

Furthermore, when adding syntax you are not limited to a Lisp-style grammar

And this is a very good point because you can add things like XML grammar to Perl6: http://github.com/krunen/xml

Re: Ask PG: Lisp vs Python (2010)

#156

Post by jules »

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…

I agree. Language choice is definitely not the most important factor in success, but it's not as unimportant as some think it is.

Some languages make it easier to become familiar with the libraries. Compare the standard libraries of Ruby and Python with PHP. Even though I programmed in PHP for several years I always had to look up argument order, or whether the names of functions contained underscores between words or not.

Re: Ask PG: Lisp vs Python (2010)

#157

Post by mzl »

silentbicycle wrote: post #44
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…

> 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. The Python byte-compiler, specifically, appears to be fairly slow. I hadn't really thought much about this, but while contributing to a benchmark yesterday ( http://news.ycombinator.com/item?id=1800396 ), it wound up staring me in the face. There's actually surprisin…

I quite like the approach taken in MetaLua (http://metalua.luaforge.net/) for allowing more advanced cases of meta-level programming. After some exposure, moving up and down levels using +{} and -{} becomes about as readable as meta-programming can IMHO. The explicit modification of the compiler is not so nice, but I'm guessing it is hard to do anything better in a a programming language with some actual syntax.

Of course, what I really would like to use is MetaLuaJIT, to get the best of all worlds :)

Re: Ask PG: Lisp vs Python (2010)

#158

Post by mzl »

masklinn wrote: post #106
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)

The fun alternative language example is of course Fortran, where at least early versions disregarded whitespace.

Re: Ask PG: Lisp vs Python (2010)

#159

Post by lispm »

masklinn wrote: post #145
lispm wrote: post #136

Earlier quoted context omitted.

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.

Native threads that are locked against each other by a GIL, are still native threads, but less useful native threads. An important purpose/use of native threads is that they are scheduled by the OS and not hindered by a GIL, so that in multicore machines multiple threads can run concurrently.

CCL does that. Python with the GIL not.

Re: Ask PG: Lisp vs Python (2010)

#160

Post by lispm »

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…

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. There maybe other problems.

There is another Iteration facility as a library for Common Lisp called ITERATE. It is very similar to LOOP, but the syntax is a bit more oriented towards Lisp.

Post reply on HN