search

vindarel / lisp-journey

Discovering the Common Lisp ecosystem. https://lisp-journey.gitlab.io/
2 stars 0 forks source link

pythonvslisp/ #8

Open utterances-bot opened 4 years ago

utterances-bot commented 4 years ago

Python VS Common Lisp, workflow and ecosystem - Lisp journey

I learned Java and C at school, I learned Python by myself and it was a relief. After 8 years working and doing side projects in Python and JavaScript (mostly web dev, Django/Flask/AngularJS/Vuejs), I am not satisfied anymore by the overall experience so I’m making Common Lisp my language of choice.I am not here to compare languages themselves, but their inherent workflow and their ecosystem. This is the article I wish I had read earlier, when I was interested in Lisp but was a bit puzzled, because the Lisp way always seemed different, and I couldn’t find many voices to explain it.

https://lisp-journey.gitlab.io/pythonvslisp/

vindarel commented 4 years ago

Find comments there:

Zulu-Inuoe commented 3 years ago

Hi. It looks like the section ToC links to each of the appendices are broken. Eg:

and so on. I'm assuming it's because of the character ? being used in these

vseloved commented 3 years ago

Hi, thanks for a good writeup. I think it addresses a number of common question so I'll be sending it to people occasionally :)

I have a question: can you point to an implementation of triple-quoted strings in CL? I was thinking about it and also looking for it, but so far the only thing I could come up with for literal strings is this: https://github.com/vseloved/rutils/blob/master/core/readtable.lisp#L117

vindarel commented 3 years ago

Hello, thanks, please do, it answers a ton of questions I had as a newcomer!

Yes: I use pythonic-string-reader. So far so good.

vindarel commented 8 months ago

We can find debates on HN on whether Python can blend to CL's REPL development style. Here's a thread: https://news.ycombinator.com/item?id=37842632 (and parent)

You simply can't [live in the Python repl the same way that lispers do], not only due to unwind-first exception handling, but also because one module is represented by multiple objects in memory: one object for each other module that imports it. That makes it impossible to redefine anything (you'll always miss some of the copies of whatever you tried to redefine). Importing things from modules piecemeal makes it even harder to find them.

The importlib.reload function only applies to one copy of a module. A comprehensive solution would be incredibly complicated and would still have limitations.

In contrast, a Lisp package exists in exactly one place. No matter where you get it from, two references to the same package are always eq (having "is" equality in Python terms). Therefore, if you redefine something in a package, you redefine it for everything that uses the package. It also helps that imports in Lisp apply to the symbols, not the things they refer to. So importing something doesn't hide a copy of it anywhere. The most naive redefinition technique will always work, with no edge cases.

The inability for class redefinition to affect already existing objects in Python is another severe limitation. Even if you could redefine anything reliably in Python, you'd still have this problem.

or:

Python doesn't work well for repl development. You cannot set the current module in Python as you can do in Lisp. So you're restricted to make changes to the current module. Also, debugging in the repl is not as powerful in Python.

vindarel commented 1 month ago

A little follow-up: https://dev.to/vindarel/python-vs-common-lisp-applied-print-log-and-icecream-2h12

Context: I tried a somewhat popular Python library, with features very not unlike what I now use in Lisp land. In theory, it looked great. In practice however…

I thought it was a good case study on Python VS CL. Mostly meant to change the eyes you put on CL: CL might not lack features despite less trendy libraries, Python might not exactly ingest Lisp features…