Live data from Hacker News

Ask PG: Lisp vs Python (2010)

news.ycombinator.com

171–180 of 200 posts

Re: Ask PG: Lisp vs Python (2010)

#171
post #168

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. --------------------------- 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 differe…

Hmmm... it's interesting...

I came to conclusion that it is easier to do external DSL, not embedded. Parse source code on Pascal and then translate it into S-expressions. Am I right?

Btw, if I'm gonna write external DSL, I can do that in any language for example on Python. So, what's the difference?

Re: Ask PG: Lisp vs Python (2010)

#172

Earlier quoted context omitted.

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?

...actually, I don't know. When I started, I was told we don't use it; I don't remember whether I was told a reason. If I was, it was performance; anything else would have been surprising enough to remember.

Re: Ask PG: Lisp vs Python (2010)

#173
post #170

Earlier quoted context omitted.

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

wouldn't this be fixed by simply declaring types of everything?

Yes, but I'm not so sure about the "simply". It's only marginally easier in C++; but at least you know that haven't forgotten to declare anything.

Re: Ask PG: Lisp vs Python (2010)

#174
When I last tried Lisp (SBCL) i was surprised how hard it is to find standard, common sense 'batteries' as you would in python, and how hard it is to get things going if you're not experienced. I think the point where I jumped out of the boat was trying out 'Hunchentoot' or something like that (webserver).

I haven't seen that with Python, Ruby, C++, Java, even Haskell feels 'modern' in that way. Why must it be so hard to get simple stuff going ?

(Note: I like function programming concepts, but I would expect a programming language to be easier to bind into a context of reality.)

Re: Ask PG: Lisp vs Python (2010)

#175
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…

There is also cl-javascript: http://github.com/akapav/js

The advantage of doing a "language X to CL" translator is that it's going to be much simpler than doing it in another language (the number of features offered by CL is a huge superset of that available in any other language; the only exception is continuations), the result will be faster (the example Ruby translator is faster than Ruby, cl-javascript is faster than SpiderMonkey, etc, mostly due to SBCL being a reasonably good compiler), and you will have access to really good debugging tools (Clozure is really good at this - see http://openmcl.clozure.com/ccl-documentation.html#watched-ob... for example).

Re: Ask PG: Lisp vs Python (2010)

#176
Am I missing something, why does it have to be either Python or Lisp? After all I know, Peter Norvig has embraced Python in addition to Lisp, rather than switched completely as in "no more Lisp". Same goes for everyone else -- some tools are more fit for some tasks than others, especially with corprorate restrictions being a constraint.

Re: Ask PG: Lisp vs Python (2010)

#177
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.

Forgive me, but I think you mean in python you miss static typing.

Python is strongly typed.

Also, just to jab at C/C++, pointers to void... really? It all but makes C/C++ a weakly typed language.

http://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%... http://www.artima.com/weblogs/viewpost.jsp?thread=7590 http://en.wikipedia.org/wiki/Duck_typing http://articles.sitepoint.com/article/typing-versus-dynamic-...

Re: Ask PG: Lisp vs Python (2010)

#178
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.

You aren't limited to Lisp-style grammar in Lisp either. You can write reader macros if you have to. The point is, that on a basic level manipulating s-expressions is far easier to think about than manipulating the syntax of whatever the flavor of the day language is. You're essentially trying to invent reasons why macros in other languages are the same as Lisp macros and it's simply not true.

Re: Ask PG: Lisp vs Python (2010)

#179
I used to write a reasonable amount of Lisp at my first job, in an industrial research lab, in addition to a fond exposure to it at my institution of higher learning.

I really, really like Lisp. The syntax, as a result of it having been introduced to me fairly early, never was a hangup of any kind. SLIME is quite wonderful. I always yearn for quasiquotation.

However, I cannot justify using it for a small-scale project that has to ship relatively soon with limited resources. The reason: Python has useful projects with good release culture and documentation that are not seen in the Lisp world, if only for the lack of contributors. (Considering the number of authors, I found common lisp documentation to be quite good, in fact, but I still find them pretty hard pressed to compete with, say, the Django manual, or most of the Python standard library itself)

Software — especially at the small, early stage scale — is still loaded with problems that are not matters of extensive, inspired, and unique programming. Or, they could be, but did you really want to write your own whiz-bang form validation instead of building all the other features of your product?

Clojure I think represents a very interesting escape from this trap, and if I had a lot of Java dependencies (whether bequeathed or because of unique library advantages Java may have. WEKA comes to mind for some things) I would most certainly want to use it. But in a project I control from the beginning, Python wins, hands down, in a number of domains.

I will also expose one heretical opinion of mine about Lisp Macros: they're great, but easy to overuse, and seldom So Necessary if one makes good use of higher order functions. Some code, admittedly, comes out nicer using macros, but I can almost always get the expressive power I need with little contortion using higher order functions.

If I had the time to follow my heart, I'd want to do something to continue to vitalize Lisp. But not while I need to ship.

To round out this post, here are some minor peeves on the Python side though:

* No symbol data type. I don't like using strings for these. I use SymbolType for this, but it's still comparatively clunky compared to CL.

* Hyphens are the best intra-token-delimiter (see what I mean?)

* No macros

* No quasiquotation

* Slow

* Have to avoid stepping on myself because of the mutable environment frames you see a bit more frequently as opposed to say, Scheme or Erlang where tail recursion is the name of the game. I also make use of "labels" in cl.

* Did I mention tail recursion elimination? No? Well...sometimes this would be nice.

Re: Ask PG: Lisp vs Python (2010)

#180
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 ;)

Even if that happened to work correctly (which I don't believe), you would still be missing a bunch of macro-related stuff that makes CL the programmable programming language it is, and Python isn't:

-reader-macros

-symbol-macros

-compiler-macros

-macrolet

-symbol-macrolet

EDIT: Fixed layout

Post reply on HN