Speaking of Common Lisp - the European Lisp Symposium starts tomorrow (May 3 and May 4, <a href="https://european-lisp-symposium.org/2021/index.html" rel="nofollow">https://european-lisp-symposium.org/2021/index.html</a>). The entire conference will be broadcast on Twitch. Python programmers are invited, too :)
Nice article.<p>One thing, re “In Python we typically restart everything at each code change“: I sometimes run Python in Emacs with a REPL. I evaluate region to pick up edits. Not bad.<p>The big win for the Common Lisp REPL is being able to modify data, do restarts, etc. I usually use Common Lisp, but for right now I am heavily using Clojure to write examples for a new Clojure AI book that I am writing. I miss the Common Lisp REPL!
Not to start a flamewar, every time I see a python talk (pycon or else), with fancy tricks like metaclasses.. all I can think is that, well, CLOS would have been perfectly fit for this too.<p>I know people are tired of the "lisp/smalltalk did it better" but what features of python are not possible (or hard) in CL[OS] ?<p>ps: how many CL shops are out there ? I'd work near free just to try a CL team once.
I like Lisp, and I'm not a fan of e.g. Python's whitespace sensitivity. That said, for niches such as ML and data science, I find you just can't beat the Python ecosystem.
I use hot reloading with an iPython repl. I write my code in such a way that I can interact with any individual part of the system via a REPL. Lisp excels here, but you can have a decent approximation of a real-time evaluation loop going.
This might seem slightly unrelated, but I was reading Elixir in Action and one of the statements is along the lines of a debugger being difficult to use in its naturally concurrent environment. The Elixir strategy is to kill erroring processes, capturing their exit signals with supervisor processes and then possibly recreating a replacement process.<p>Can the common lisp condition system be adapted to Elixir? Is there an advantage to doing so? Is there some obvious tradeoff between the two I'm not expressing?<p>Thanks.<p>see this thread form HN for more about adapting the condition system elsewhere.<p><a href="https://news.ycombinator.com/item?id=26852309" rel="nofollow">https://news.ycombinator.com/item?id=26852309</a>
He forgot: in python you read the code of somebody else and it's familiar.<p>In lisp, you are learning a new language with every lib because each author think they are a god language designer and that their macro rock. Also they don't need a good doc cause they are obvious. Or good error message cause they never break.<p>Also the way the author dismiss the number gap of packages available is ignoring the elephant in the room.
I'm not a particularly experienced or good Lisp programmer, I can customize Emacs, but that's pretty much it.<p>However, I think this article is a bit skewed and not highlighting things Python has.<p>For instance, the standard library means that Python is more usable out of the box.<p>Also when you've got things like iPython or Jupyter it means you can get off the ground easily.<p>So, in the end, they're two different languages, and I do not think either is better of the two. Right tool for the job and all that.
There is popular python environment where you do not restart the environment after an edit: Jupyter notebooks. This comes with its own set of problems, which CL also has, but I still find notebooks a worthwhile mindset for writing applications. There’s no need to equate python with the script mindset.