Live data from Hacker News

Python's “disappointing” superpowers

lukeplant.me.uk

111–120 of 264 posts

Re: Python's “disappointing” superpowers

#111

Before I read this article I was not aware of exclusive advantages to dynamic typing. At least now I know what is achievable despite its presence.

Which of these do you think require dynamic typing?

that's the point, none of these examples are intrinsically linked to dynamic typing.

Re: Python's “disappointing” superpowers

#112

Earlier quoted context omitted.

Java is actually a very dynamic runtime with a very static language front end.

The thread is about programming semantics though, so what does that have to do with anything?

cough Reflection. This also includes Annotations which can give clear semantics to code generation.

Re: Python's “disappointing” superpowers

#113
post #110

Earlier quoted context omitted.

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

[flagged]

Re: Python's “disappointing” superpowers

#114

I think type hints have mostly changed Python for the better but I still get frustrated by the number of half baked features and inconsistencies in the language. You end up fighting quirks ( like isinstance not working properly with generics ) all the time and it can get pretty tedious.

... what? You're not supposed to use isinstance with generics??? It's a type-hinting only feature afaik

Re: Python's “disappointing” superpowers

#115

Earlier quoted context omitted.

[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

[flagged]

Re: Python's “disappointing” superpowers

#117

Earlier quoted context omitted.

> its datamodel is overally less of a hot mess compared to Javascript for example. I don't understand this, what do you mean? TypeScript is such a success partly because everything is an object in Javascript. There's no need to distinguish between classes and "dicts", as you have to with Python. Another example: Python functions have args and kwargs, which make typing significantly more complex (as the article points…

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.

Re: Python's “disappointing” superpowers

#118

Earlier quoted context omitted.

> 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

[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 do they fare in your imaginary analysis?

> As a matter of principle, I won't provide citations unless you first provide some citation that says I'm wrong first. (You won't find one)

Ok, so you're an idiot. Got it. You can't make such a strong and precise claim and not back it up, and try to turn the tables by saying "No your citation!". You just come off like a petulant child (maybe you are?). Your claim makes no sense, and anyone who has at least 5 years of experience (probably less, actually) would know that.

You've asserted there are empirical studies on the topic to back your numbers. Just provide them.

Re: Python's “disappointing” superpowers

#119
post #26

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…

> Python remains a fantastic prototyping and scripting language I think it sucks for prototyping too if your prototype is constantly evolving. I have a WIP with about 100 files in it that I've been aggressively evolving over the past year, and I already want to rewrite everything in something statically typed, because any kind of change became pain in the ass. Too bad the project requires Python-first libraries.

Large Python projects are done with microservices typically.

Re: Python's “disappointing” superpowers

#120
post #78

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.

Yeah thought so too... in particular the example where you pass a a generator to a db, the generator isn't actually executed, and instead the expression is parsed & transformed to SQL. This is cool if it works. Good luck when it doesn't due to user error, and more luck if it doesn't due to a bug. You need to develop a whole strategy to tell the user what went wrong and how, and why, basically from scratch; admitting…

And C# can do that with static typing via LINQ, which is really nice honestly. It’s a bit different but it would be something like:

  var result = await (from c in Customer where c.orders.sum(o => o.price) > 1000 select c).ToListAsync();
Post reply on HN