Python vs Common Lisp, workflow and ecosystem (2019)
lisp-journey.gitlab.io
Python vs Common Lisp, workflow and ecosystem (2019)
1–10 of 83 posts
Re: Python vs Common Lisp, workflow and ecosystem (2019)
#2Speaking of Common Lisp - the European Lisp Symposium starts tomorrow (May 3 and May 4, https://european-lisp-symposium.org/2021/index.html). The entire conference will be broadcast on Twitch. Python programmers are invited, too :)
Re: Python vs Common Lisp, workflow and ecosystem (2019)
#3This 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.
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?
Thanks.
see this thread form HN for more about adapting the condition system elsewhere.
Re: Python vs Common Lisp, workflow and ecosystem (2019)
#4I 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.
Re: Python vs Common Lisp, workflow and ecosystem (2019)
#5I 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.
Are people actually doing science with Python or are they talking about doing science?
There's so much buggy low quality stuff in that space that I'd write a serious application in C or C++ from scratch.
It would be a custom application, sure, but not everything needs to be general.
Also, I find Lisp much more natural for mathematical reasoning.
Re: Python vs Common Lisp, workflow and ecosystem (2019)
#6I 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.
Are people actually doing science with Python or are they talking about doing science? There's so much buggy low quality stuff in that space that I'd write a serious application in C or C++ from scratch. It would be a custom application, sure, but not everything needs to be general. Also, I find Lisp much more natural for mathematical reasoning.
> Are people actually doing science with Python or are they talking about doing science?
People are actually doing it. And a lot of it too. Both in terms of data science (as a broad term that can mean a bunch of different things) and in terms of computation for specific scientific fields like physics or biology.
Re: Python vs Common Lisp, workflow and ecosystem (2019)
#7I 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.
Are people actually doing science with Python or are they talking about doing science? There's so much buggy low quality stuff in that space that I'd write a serious application in C or C++ from scratch. It would be a custom application, sure, but not everything needs to be general. Also, I find Lisp much more natural for mathematical reasoning.
Yeah, they're very much doing it.
Pandas is huge, libraries like Spacy, NetworkX, etc exist. It's a massive and good ecosystem. Python is the goto for scientific computing in most of the sciences for newer students I'd hazard a guess over the older R and Julia.
This will be blindingly obvious if you work in that area. Yes, you can do it in another language, but you're missing out on a lot of stuff that is just done and is state of the art and is fast because the speedy parts aren't in Python. The complaints about parens for lisp are superficial, but it's my experience the same same goes for whitespace in Python. They just don't matter.
Re: Python vs Common Lisp, workflow and ecosystem (2019)
#8This 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. Can the common lisp condition system be adapted to Elixir? Is there…
Elixir is based on the BEAM virtal machine developed for Erlang. Restarting crashed (very lightweight) processes to handle errors is the normal way of doing things in that system.
LFE(Lisp-flavored Erlang) is an existing language that combines Lisp syntax with Erlang's backend, though I haven't used it myself yet.
Re: Python vs Common Lisp, workflow and ecosystem (2019)
#9Earlier quoted context omitted.
Are people actually doing science with Python or are they talking about doing science? There's so much buggy low quality stuff in that space that I'd write a serious application in C or C++ from scratch. It would be a custom application, sure, but not everything needs to be general. Also, I find Lisp much more natural for mathematical reasoning.
Yeah, they're very much doing it. Pandas is huge, libraries like Spacy, NetworkX, etc exist. It's a massive and good ecosystem. Python is the goto for scientific computing in most of the sciences for newer students I'd hazard a guess over the older R and Julia. This will be blindingly obvious if you work in that area. Yes, you can do it in another language, but you're missing out on a lot of stuff that is just done a…
> and is fast because the speedy parts aren't in Python.
Having worked months with a slew of senior data scientists, this was a bit painful. Python is so slow and those data scientists were very good at coming up with solutions for the issues of the company, but the implementations (using Spacy, Pandas and other libs) had enough Python in them to make them not practical for the company use case. Nice prototypes which I then had to fix them or even rewrite to C/C++(we worked Rust as well to try it out) to make them usable in the company data pipeline.
I think companies are burning millions (billions in total?) on depressingly slow solutions in this space by throwing massive power at it all to make them complete their computations before the sun dies out.
Example: we needed a specific keyword extraction algorithm for multiple languages; my colleague used Spacy and Python to create it. It took a couple of seconds per page of text; we needed max a few ms on modern hardware. He spent quite a lot of time rewriting and changing it, but never got it under 1s per page on xlarge aws instances. My version takes a few ms on average executing the same algorithm but in optimised c/c++.
Sure we could've spun up a lot more instances, but my rewrite was far cheaper than that, even in the first month.
Re: Python vs Common Lisp, workflow and ecosystem (2019)
#10He forgot: in python you read the code of somebody else and it's familiar.
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.
Also the way the author dismiss the number gap of packages available is ignoring the elephant in the room.