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

121–130 of 264 posts

Re: Python's “disappointing” superpowers

#121

Post by kayodelycaon »

ReflectedImage wrote: post #100
TeeWEE wrote: post #75

All these features are nice and stuff... But they are often runtime features... At compile time Python doesnt tell you wether a program is correct. Which is fine for small programs or small services. But any big system is written in python is really hard to maintain without LOTS of unit tests... Static typing, compile time checks just win in the long run. And with languages like kotlin you still have all the advantag…

No programming language tells you if a program is correct at compile time. Type errors aren't a very common type of bug either.

The most common type error I see are unexpected null values. Which, surprise, is still a problem in many typed languages. :)

Re: Python's “disappointing” superpowers

#122

Post by ReflectedImage »

phailhaus wrote: post #117
KyeRussell wrote: post #77

Earlier quoted context omitted.

OP is not saying that type checking is useful. They’re saying that it’s not as useful.

What about Python's data model makes typechecking less useful? You still need to know how data flows through your application. You can either document it in your types, or require your engineers to hold all that information in their heads/recapitulate it every time they want to refactor code. That has nothing to do with the language's data model.

[flagged]

Re: Python's “disappointing” superpowers

#123

Post by ReflectedImage »

Jtsummers wrote: post #118
ReflectedImage wrote: post #115

Earlier quoted context omitted.

[flagged]

> It's not a very strong claim, it's due to dynamic typing enabling the writing of more concise programs. The number #1 bug elimination tool is to simply write less code. It is a strong claim, it's also a very precise claim. Where do your numbers come from? Haskell and the ML family of languages also permit you to write much more concise programs than many other languages and they're definitely statically typed. How…

[flagged]

Re: Python's “disappointing” superpowers

#124

Post by [deleted] »

thereisnospork wrote: post #48

While this might be about my most unpopular opinion, it feels like it is time to start putting together a Python 4.0. I don't particularly have skin in the game but there is(?) enough meat on the bone around things like improving the GIL status quo, JIT compiling, static typing, and presumably etc. to be worth a breaking change.

[deleted]

Re: Python's “disappointing” superpowers

#125

Post by spoils19 »

ReflectedImage wrote: post #123
Jtsummers wrote: post #118

Earlier quoted context omitted.

> It's not a very strong claim, it's due to dynamic typing enabling the writing of more concise programs. The number #1 bug elimination tool is to simply write less code. It is a strong claim, it's also a very precise claim. Where do your numbers come from? Haskell and the ML family of languages also permit you to write much more concise programs than many other languages and they're definitely statically typed. How…

[flagged]

I support you ReflectedImage - seems like these people just don't know how great dynamic languages can be! My team has actually seen a 30x decrease in bugs, and a 50x increase in productivity ever since switching to Python.

Re: Python's “disappointing” superpowers

#126

Post by llanowarelves »

simplicio wrote: post #44
paganel wrote: post #4

> I’m worried that a de-facto move away from dynamic stuff in the Python ecosystem, possibly motivated by those who use Python only because they have to, and just want to make it more like the C# or Java they are comfortable with, could leave us with the very worst of all worlds. It is certainly happening, and I'm not sure Python the language is all the better for it. I say that as a guy who explicitly mentioned this…

My theory is that Python and C++ are slowly evolving towards eachother, and in 20 years will merge into the same (very confusing) language.

C# and typescript towards each other for sure,

And everything taking from lisp/other functional languages: lambda, map, filter etc. Which I really like

Re: Python's “disappointing” superpowers

#127

Post by Toniglandyl »

ReflectedImage wrote: post #113
jchw wrote: post #110

Earlier quoted context omitted.

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, sinc…

[flagged]

Do you have a reference to as study that support your point ?

Re: Python's “disappointing” superpowers

#130

Post by phailhaus »

ReflectedImage wrote: post #122
phailhaus wrote: post #117

Earlier quoted context omitted.

What about Python's data model makes typechecking less useful? You still need to know how data flows through your application. You can either document it in your types, or require your engineers to hold all that information in their heads/recapitulate it every time they want to refactor code. That has nothing to do with the language's data model.

[flagged]

Citation heavily, heavily needed. Dynamic typing means that none of your code can be statically checked, which means that correctness relies on the exhaustiveness on your tests. It should be obvious that this would allow you to introduce more bugs, not fewer.

Every program involves passing around data. When you need to change that data in a dynamic untyped language, you have no option but to manually test your whole system to make sure that you nailed all the spots.

Compare that to a language like TypeScript. If I need to refactor my code, I update the type and the static typechecker immediately tells me all the spots I need to fix. I don't have to hunt for them, I don't have to run it 100x trying to hit every edge case. And JavaScript is still dynamic, it doesn't stop me from writing concise code.

This isn't theoretical. I literally just worked on changing something from a dict to an object in Python, and it was a pain. Thankfully most spots were documented with type hints, but even then I ran into many runtime errors that could have been caught statically.

Post reply on HN