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

Python's “disappointing” superpowers

lukeplant.me.uk

Post reply on HN
Print view View original

101–110 of 264 posts

Re: Python's “disappointing” superpowers

#101

Post by arcturus17 »

phlakaton wrote: post #52
lordgroff wrote: post #6

I maintain Python code bases for a living, and feel that the language has simply been pushed too far. Static typing in Python doesn't give you the advantage of actually static typing and even IDE support is -- well it's not terrible, just not great. The thing is, once we go through all this static typing exercise in Python, we get no performance advantages, and the whole thing seems bolted on, with worse semantics th…

I think the mistake is to assume that Python's type hints form a complete static typing system. Of course they fall short if you think that's what they're supposed to be. I think of it instead as a sometimes-useful subset of checks that you might get from a static typing system, and I use it in those places in my projects where I think it will be the most useful. The very fact that I can think of it as an option I ca…

Yea this is exactly how it feels to me. Like “reinforced dynamic”.

Re: Python's “disappointing” superpowers

#102

Post by ReflectedImage »

jchw wrote: post #86
ImprobableTruth wrote: post #32

Metaprogramming does not require dynamic types, but this post seems to equate them. As far as I can see all this could be done in e.g. Java (and probably is). IME this kind of "magic" very quickly loses its appeal when you have to debug it. The author's idea of libraries wrapping this stuff up so users don't have to care about it just doesn't pan out at all in my experience.

I also strongly dislike the idea that static type systems are only being added to Python because spoilsports from other languages are forced to use Python and don't want to. Not true. That's especially strange considering Python is one of the only traditionally dynamic languages that has mostly led it's own static typing system, joined mainly by just PHP in that regard. Why does it not support features like kwargs? D…

You quit Python because you tried to use static typing in a dynamic language and for obvious reasons that doesn't work.

You could have introduced an UAT environment and done basic QA.

Re: Python's “disappointing” superpowers

#103

Post by benreesman »

I kinda hope we can just let Python be Python: it’s in a global-ish maximum for what it’s for, and I suspect any big move away from that will make it worse overall.

Obviously things like UTF-8 support, or maybe getting a clean lexical scope option, or other “fixes” are good. Performance improvements are good.

But there are lots of mainstream languages that have mature static type systems, strong metaprogramming facilities, higher performance, or all of the above.

I’d way rather see effort go into getting the package management thing figured out, or the static analysis stuff improved further than any big movement in the language proper.

Just my 2c.

Re: Python's “disappointing” superpowers

#104

Post by taeric »

vkou wrote: post #84
taeric wrote: post #81

Earlier quoted context omitted.

I mean, you aren't wrong. But most of what they learned was "step debugging is hard in the presence of macros." And step debugging has largely been tossed out of the window in many modern setups. Just look at Java's "stream" apis. I swear they did what they could to replicate the LOOP macro.

I am very rarely concerned about debugging my usage of Java streams, and step debugging works fine in the context surrounding them.

That is also the case for macros in lisp, at large.

Similarly, any heavy use of lambdas in java will make step debugging confusing. As will any annotations you may use. Which is largely why many people grow to hate annotations.

Which is all a fancy way of saying we learn the same lessons again and again. Used smartly, all of these are great tools. Defining what is "smartly" is a place of dragons.

Re: Python's “disappointing” superpowers

#105

Post by ReflectedImage »

9dev wrote: post #46
wheelerof4te wrote: post #22

Either embrace dynamic typing and provide good error guards...or try to use type hints and still make good error guards. We had an entire history of Python 2 without type hints. Why use them now?

How come everyone realised the benefits of typing by now, except the Python community?

[flagged]

Re: Python's “disappointing” superpowers

#106

Post by progval »

tmtvl wrote: post #69
fallingfrog wrote: post #5

Don't fool yourself- if your programming language has an eval() function, you are writing in Lisp and you are a Lisp programmer now. Embrace it! All joking aside, I do think Python is pretty handy.

Oh no, Lisp is so much more powerful. For example you can update the definition of a class in a running system and update all existing instances of that class. When an error occurs you can inspect local variables in any of the stack frames and execute commands in them. And that is only the tip of the iceberg, Lisp is, as far as I know, without equal in terms of power.

> you can update the definition of a class in a running system and update all existing instances of that class

Like this?

    >>> class MyClass:
    ...   attr = 0
    ... 
    >>> my_object = MyClass()
    >>> MyClass.attr = 42
    >>> my_object.attr
    42
    >>> MyClass.method = lambda self: self.attr
    >>> my_object.method()
    42
> When an error occurs you can inspect local variables in any of the stack frames and execute commands in them

What is the difference with https://lukeplant.me.uk/blog/posts/pythons-disappointing-sup... ?

Re: Python's “disappointing” superpowers

#107

Post by Jtsummers »

ReflectedImage wrote: post #105
9dev wrote: post #46

Earlier quoted context omitted.

How come everyone realised the benefits of typing by now, except the Python community?

[flagged]

> Developing with static typing reduces development speed by 2.5x and increases bugs by 2.5x per the emperical studies on the topic.

I hate "Citation needed" comments, but this is a very strong claim and so deserves it:

Citation needed

Re: Python's “disappointing” superpowers

#108

Post by ReflectedImage »

zerodensity wrote: post #82
lordgroff wrote: post #6

I maintain Python code bases for a living, and feel that the language has simply been pushed too far. Static typing in Python doesn't give you the advantage of actually static typing and even IDE support is -- well it's not terrible, just not great. The thing is, once we go through all this static typing exercise in Python, we get no performance advantages, and the whole thing seems bolted on, with worse semantics th…

I also maintain a large python codebase at work, typing makes things simpler. For example using pydantic 90% of serialization code just goes away. Mypy eliminates a large number of bugs. Also when working with multiple people in the same codebase typing makes intent so much clearer. The type system itself is not perfect but it's a clear improvement of not having it at all.

I disagree, it makes things more complicated by bringing in concepts such as generics.

Using MyPy will on average double your bug count per software feature. You might not think it does that. But if you actually go and measure it, the bugs go through the roof. There are studies on this. It's for subtle reasons revolving around where bugs come from in code.

Re: Python's “disappointing” superpowers

#110

Post by jchw »

ReflectedImage wrote: post #102
jchw wrote: post #86

Earlier quoted context omitted.

I also strongly dislike the idea that static type systems are only being added to Python because spoilsports from other languages are forced to use Python and don't want to. Not true. That's especially strange considering Python is one of the only traditionally dynamic languages that has mostly led it's own static typing system, joined mainly by just PHP in that regard. Why does it not support features like kwargs? D…

You quit Python because you tried to use static typing in a dynamic language and for obvious reasons that doesn't work. You could have introduced an UAT environment and done basic QA.

We had dedicated QA testing. QA testing failed to create the requisite conditions.

Type checking is not a replacement for QA testing. However, it is much cheaper and also finds bugs that might be incredibly hard to find through random chance or through structured smoke testing, because it does not depend on how common a given code path is. QA testing is even less likely to find issues than automated test suites, since at least you can qualify branch coverage with test suites (which still will not enumerate all of the possible code paths, and thus... Type checking is incredibly useful.)

So while type checking really is not a replacement for QA, QA is also not a replacement for type checking.

I ultimately quit Python for many reasons, but the desire to write more correct code was the big one. Not just me, but my entire team was burned out on Python. Investing so much into unit testing and increasing coverage, upgrading Python versions, and adding type checking as much as possible was still not yielding the benefits we'd hoped for despite how much effort it took. We eventually found much better success with the then-still-new Go programming language, which we used on most new projects going forward. There was still the occasional head scratcher in production, but deployments were as quiet as a church mouse. YMMV of course; there's plenty of success and failure stories with any programming language. I think we were all ready and willing to put a lot of investment into improving our robustness situation and just felt that we got more out of that effort with Go than Python for our programs. Python still has plenty of advantages too, so we didn't completely quit it; we wound up using Django and SQLalchemy here and there, but definitely most stuff moved to Go over time. (And personally, I stopped using Python for those things too, since moving on.)

Post reply on HN