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

Problems I Have with Python

darkf.github.io

Post reply on HN
Print view View original

111–120 of 239 posts

Re: Problems I Have with Python

#111

Post by sabauma »

pinjo wrote: post #96
xapata wrote: post #72

Earlier quoted context omitted.

The lack of tail-call optimization to make the CPython interpreter simpler and debugging easier by preserving the call stack. It was a choice, not an oversight.

From a debugging viewpoint, this does not make sense, there is usually no interesting information in the in between frames. TCE can also make debugging easier, how useful is a stack trace of 1000 lines consisting of ... File "bla.py", line 4, in fib return fib(n - 1) + fib(n - 2) File "bla.py", line 4, in fib return fib(n - 1) + fib(n - 2) File "bla.py", line 4, in fib return fib(n - 1) + fib(n - 2) ... Not so much I…

The notion that not having proper tail calls aids debugging always seemed like a post-hoc justification. The stack trace of an iterative function will lack exactly the same intermediate evaluation frames as a tail-recursive implementation.

Re: Problems I Have with Python

#112

Post by jknoepfler »

I don't understand the desire to turn python into a high performance language. It's 2017, if you want performance just write some go/cpp/rust. If you want to leverage an old and very mature concurrency framework, use elixir/erlang. If you need a giant data integration framework, use java. If you want a stellar bash replacement, use python. Know your tools, don't bloat them with unnecessary crap. (The list was not intended to be exhaustive or pick the best, just to illustrate that we have tools for each type of job).

The idea of single-language buy-in has always perplexed me.

Re: Problems I Have with Python

#113

Post by sabauma »

KingMob wrote: post #88
xapata wrote: post #72

Earlier quoted context omitted.

The lack of tail-call optimization to make the CPython interpreter simpler and debugging easier by preserving the call stack. It was a choice, not an oversight.

Why not just make it a dev/production flag, then?

Probably because many tail-recursive functions _rely_ on tail-call elimination working reliably. Without also having an unbounded call stack, disabling tail-call elimination will likely just cause your programs to crash.

Re: Problems I Have with Python

#114

Post by Siecje »

The biggest problems with Python are packaging and distribution.

It would be nice to create a single file and be able to send it to someone, like golang which even has cross compilation.

Mobile support, you can't easily write a mobile application in Python.

Re: Problems I Have with Python

#115

Post by darkf »

BlackFingolfin wrote: post #75
darkf wrote: post #17

Earlier quoted context omitted.

Cool, I think you completely dodged the point. I never said it was slow because they were incompetent.

Your post quite strongly alludes to it being either due to incompetence, or politics, or both. So I think grandparent has a very valid point, and you might want to change the tone of your post a bit; then it'll produce fewer knee-jerk reactions, and might be taken more seriously.

Nah, just people connecting that sentiment with other statements. It should be cleared up since it's causing some mass confusion.

It's funny because I preface it by saying "Remember that it's a matter of opinion" (and, well, the title alone) and people come out of the woodwork completely disregarding this, or outright misinterpreting sections of it.

I maintain that a large reader base here does not actually... read.

Re: Problems I Have with Python

#116

Post by darkf »

Siecje wrote: post #114

The biggest problems with Python are packaging and distribution. It would be nice to create a single file and be able to send it to someone, like golang which even has cross compilation. Mobile support, you can't easily write a mobile application in Python.

>Mobile support, you can't easily write a mobile application in Python.

Depends on your needs, but there is at least Kivy.

Re: Problems I Have with Python

#117

Post by darkf »

xapata wrote: post #76
darkf wrote: post #17

Earlier quoted context omitted.

Cool, I think you completely dodged the point. I never said it was slow because they were incompetent.

Python has made some trade-offs that you dislike. You complain about the negative consequences without comparing those against the benefits. One of the major factors in speed is efficient memory layout. Contrast a Python list with a NumPy array. To achieve speedier loops and vectorized arithmetic [0], the array gives up dynamic typing and dynamic sizing. In most applications, I would gladly give up some compute speed…

>Contrast a Python list with a NumPy array. To achieve speedier loops and vectorized arithmetic [0], the array gives up dynamic typing and dynamic sizing. In most applications, I would gladly give up some compute speed to gain some programming productivity.

Except numpy arrays have a much richer interface and can still store dynamic objects (dtype=object). So what's your point?

>I love duck-typing

So do I. Where does this come from? I don't believe I ever considered it a contra.

Re: Problems I Have with Python

#118

Post by darkf »

dev360 wrote: post #46
darkf wrote: post #6

Earlier quoted context omitted.

>However, many are subjective preferences Certainly, it is titled "Problems I Have" for a reason. :-) I do not expect everyone to agree with me, but it is what I feel I personally lack when using it quite a lot. > I imagine this statement could offend some of the smart and hard-working people who are working on improving the python language. That was certainly not my intention -- as stated, I do love the language and…

I was taken back by this rather harsh treatment of Python. Is it really realistic to 'have it all'? I'm fully aware that I'd have to go to crazier languages if I want parallelism or speed. For what Python is, it offers me reasonable tradeoffs (mostly slanted towards productivity).. Regarding the FP comments, since it lacks TCO, my take away has always been that Python can only ever become a quasi-functional language.…

I never considered it harsh. If anything, it should be a testament to how nice Python is -- if I /didn't/ like it, I would have a much, much longer list of complaints!

People seem to be missing that sentiment -- I do love Python and use it almost daily. This is merely a list of thorns I run into frequently.

>Regarding the FP comments, since it lacks TCO, my take away has always been that Python can only ever become a quasi-functional language. Its hard to be more than that in its current state.

I mean, it could always encourage playing with functions more -- and importantly, providing an stdlib that encourages that.

>These questions made me want to ask you - what languages do you think are better in comparison?

That is a somewhat loaded question: my counter question would be, "In what regards?"

I cannot say a certain language is better than Python in every or most circumstances, but I can in regards to specific points/features, if you'd like to elaborate.

Re: Problems I Have with Python

#119

Post by darkf »

pcattori wrote: post #90

The point about "Inadequate data modelling facilities" is why I wrote Maps: https://github.com/pcattori/maps . Specifically, the "Named Maps" variants provide the same interface as `namedtuple` but for different levels of immutability/mutability. Feedback/suggestions welcome!

This is really cool. NamedDict is a useful thing indeed!

Re: Problems I Have with Python

#120

Post by codygman »

amyjess wrote: post #80
darkf wrote: post #21

Earlier quoted context omitted.

>lambda is fine, if you're writing in functional style you're using expressions for everything anyway. No, I /really would/ like to be able to write: foo.on_click(lambda: x += 1) The language not supporting this (when most others do) is just silly.

> foo.on_click(lambda: x += 1) Mutation in lambdas is not compatible with your complaint about "inadequate support for high-level functional programming", as it goes against the principles of FP. You can't do that in Haskell either, and any FP purist would blanch at a statement like that.

> You can't do that in Haskell either, and any FP purist

What about us FP pragmatists? Also in some domains I'd argue being a FP purist is the most pragmatic option.

Post reply on HN