Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python vs Common Lisp, workflow and ecosystem (2019)

lisp-journey.gitlab.io

Post reply on HN
Print view View original

41–50 of 83 posts

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#41

Post by agumonkey »

dasyatidprime wrote: post #38
agumonkey wrote: post #32

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. 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] ? ps: how many CL shops are out there ? I'd work near free just to try a CL team once.

CLOS (as you presumably know) models method application as calls to generic functions, instead of the now-more-mainstream Smalltalk-like message-dispatch approach which Python uses. The latter allows for things like overriding __getattr__ to intercept ‘all’ method calls and property accesses, for which I don't think there's any equivalent in CLOS. The way methods are ‘attached’ to classes gives you a natural form of…

thanks for your points, it's true that python dynamic operator genericity is very handy

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#42

Post by wexq »

I'm not a particularly experienced or good Lisp programmer, I can customize Emacs, but that's pretty much it.

However, I think this article is a bit skewed and not highlighting things Python has.

For instance, the standard library means that Python is more usable out of the box.

Also when you've got things like iPython or Jupyter it means you can get off the ground easily.

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.

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#43

Post by tluyben2 »

odonnellryan wrote: post #33
pydry wrote: post #20

Earlier quoted context omitted.

Python performance is something that I see about 15-20x as much in discussions about python than I do wrestling with real life problems.

Agreed. The only time in practice (working on datasets consisting of millions of rows) that Python has been too slow was when I was taking courses in college and their online code thing timed out on some specific graph problems. I rewrote the algo in C# without any fuss

All analysis we run is over 100s of millions of objects (objects can be a few megabytes large) every time it runs. The slightest increase or decrease for 1 object obviously makes a huge difference overall; either in cost, time or both.

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#44

Post by mplanchard »

wexq wrote: post #42

I'm not a particularly experienced or good Lisp programmer, I can customize Emacs, but that's pretty much it. However, I think this article is a bit skewed and not highlighting things Python has. For instance, the standard library means that Python is more usable out of the box. Also when you've got things like iPython or Jupyter it means you can get off the ground easily. So, in the end, they're two different langua…

This point seems to be addressed in the “State of the Libraries” section[0]

[0]: https://lisp-journey.gitlab.io/pythonvslisp/#state-of-the-li...

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#45

Post by kbutler »

agumonkey wrote: post #32

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. 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] ? ps: how many CL shops are out there ? I'd work near free just to try a CL team once.

Beginner approachability seems to be the key feature. Possibly also integration with external libraries.

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#46

Post by kbutler »

tluyben2 wrote: post #9
gustavo-fring wrote: post #7

Earlier quoted context omitted.

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…

Have you considered how much time the "senior data scientists" saved, and how much better algorithmic solution they were able to develop by being able to iteratively explore the problem space and refine the algorithm in a convenient-to-them environment?

This development process allowed creation of a good solution that you were then able to quickly port to a performant production platform.

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#47

Post by kbutler »

jhgb wrote: post #40
dagw wrote: post #39

Earlier quoted context omitted.

You're missing the point. What makes python 'fast' is that it comes with 'out of the box' support for everything I might need. Reading and writing obscure file formats. Every sparse matrix, image processing and graph algorithm I might need has already been implemented. Do I need to all of sudden solve an optimization problem or a differential equation? Already nicely integrated with the library using. If I need some…

There's quite a few C/C++ libraries for those things, right? Integrating them with proper FFI (of the kind that Chez has, for example - or LuaJIT, for that matter) seems hardly difficult...although differential equations or optimization problems may be better served without any language interfaces whatsoever since they involve functional parameterization. That generally sucks with mixed-language solutions, to the ext…

"seems hardly difficult" and "could probably use" is seldom faster than "out of the box" and "already nicely integrated"

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#48

Post by agumonkey »

kbutler wrote: post #45
agumonkey wrote: post #32

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. 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] ? ps: how many CL shops are out there ? I'd work near free just to try a CL team once.

Beginner approachability seems to be the key feature. Possibly also integration with external libraries.

That's my take on it, but I've ran into people praising it like it was alien theory of everything dropped by gods as a gift.

I like python but I'm a bit fed up with the mobthink (how surprising).

Re: Python vs Common Lisp, workflow and ecosystem (2019)

#50

Post by SatvikBeri »

chalst wrote: post #36
PeterStuer wrote: post #4

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.

> for niches such as ML and data science, I find you just can't beat the Python ecosystem There definitely are many areas where Python is best, but for ML and data science, Julia is (i) very competitive in library coverage, (ii) more performant and flexible, and (iii) has a very good Python bridge if it's needed. I can imagine there are niches within ML and data science where what you need are Python-only libraries,…

After using python for data science for 3 years (since founding the current startup), I mostly switched to Julia about 4 months ago. So far the only Python libraries I've really missed are boto3 and sqlalchemy for sql generation – both of which can easily be called in Julia using PyCall.

I think people often underestimate just how much faster Julia is than numpy, I've consistently seen performance improvements on the order of 10x-30x when porting code.

Post reply on HN