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

211–220 of 264 posts

Re: Python's “disappointing” superpowers

#211

Post by ajuc »

taeric wrote: post #81
ajuc wrote: post #73

Earlier quoted context omitted.

LISPs are the quintessential metaprogramming languages, and they learnt the lesson of "use macros sparingly and only as the last resort" very early on.

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.

My main problem with metaprogramming in Java is that it breaks automatic IDE refactors and static code analysis. At least the metaprogramming we did with java back in the day (using reflections). If you use common java libraries made with metaprogramming - IDEs usually have plugins to work with that.

Re: Python's “disappointing” superpowers

#212

Post by IshKebab »

wefarrell wrote: post #21
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…

That's also true of Typescript, which has been wildly successful and taken over the javascript ecosystem. The main advantage of types is that it makes your code more maintainable by adding guardrails. You'll still possible run into issues at runtime and they're not perfect, but they're better than not having types at all.

Yeah the difference is that Typescript has a single good implementation (Python has two and the worst one is the most popular), and people actually use Typescript, so your dependencies have types.

I've also found that Python developers tend to write highly dynamic code that is difficult to statically type, whereas JavaScript developers - even ones that don't use Typescript - have mostly realised that that is a bad idea (with some exceptions cough Vue).

Re: Python's “disappointing” superpowers

#213

Post by ReflectedImage »

super_flanker wrote: post #209
ReflectedImage wrote: post #163

Earlier quoted context omitted.

[flagged]

You have clearly made up your mind and no matter what someone says you won't change it. Good luck learning new skills.

Well I'm showing evidence for my position and no one else is. My mind could be changed with evidence. But there isn't any as I'm correct.

Re: Python's “disappointing” superpowers

#214

Post by ReflectedImage »

lostmsu wrote: post #189
ReflectedImage wrote: post #177

Earlier quoted context omitted.

That not even an error, it's an usability improvement.

Firstly, usability bugs like this are still bugs. Secondly, think how that issue surfaced in the first place. Somebody used TensorFlow in their Python code, and their Python code produced unexpected result and/or crashed. Judging by the fix, it is highly unlikely to have produced one of the errors from the above list. As a ML practitioner I can also tell you it likely means somebody had to spend a significant amount…

That not a bug that static typing would catch as it is not a type bug.

Re: Python's “disappointing” superpowers

#215

Post by d21d3q »

sa46 wrote: post #200
deshpand wrote: post #195

Earlier quoted context omitted.

A ~100k LOC project in a statically typed system with type hierarchies, interfaces, contracts and boiler plate will boil down to ~10k LOC in a dynamically typed language like Python. A 10k LOC project will be more readable than a 100k LOC project. Source: I have spent years coding in C++/Java, then Python. I have migrated Java projects into Python

10x seems extreme. ESR went from 14k lines in Python to 21k in Go. http://www.catb.org/~esr/reposurgeon/GoNotes.html

I'm wondering how many of the extra lines are those containing only closing bracket

Re: Python's “disappointing” superpowers

#216

Post by ReflectedImage »

jchw wrote: post #186
ReflectedImage wrote: post #160

Earlier quoted context omitted.

[flagged]

> Yeah but typing related bugs which is what static type checkers catch only account for 3% of bugs. You're stating this as if it's fact and also universal, but I strongly doubt it. Even defining "type-related bug" is hard, because there's a ton of bugs that are not type-related but are much easier to avoid if you're using a good static type checker. For example, stringly-typed values, or switch statement exhaustiven…

3% is the right order of magnitude and if it is +10% more than that that wouldn't make any difference. Static typing would still be twice as bad as dynamic typing when it comes to code correctness.

"What if you already know the majority of your bugs, as logged today, could be prevented by a type checker?"

You would be a very bad programmer, since the vast majority of bugs are logic bugs.

"why does C do static typing" Code performance. It needs them to effective map types to registers avaliable on the machine it's been compiled for.

Rust lifetimes are about getting C like performance without the bugs introduced by using the techniques required for C like performance. You could remove Rust lifetimes and get all the same safety, it's just the programs would run slower due to garbage collection.

"So then TypeScript. Let's assume " TypeScript is an obvious bad example since JavaScript is a very bad language since it was hacked together by browser makers over several decades. You could make a dynamic typed equivalent of TypeScript and it would have the same advantages.

"The argument for static type checking is strong" It's incredibily weak it prevents a class of bugs that only occur very rarely in dynamically typed languages (3%). By both increasing your development time by 2.5x and increasing the total number of bugs in your program by 2.5x.

You wanting to believe in static typing doesn't stop it sucking in the context of scripting languages.

Re: Python's “disappointing” superpowers

#217

Post by bayesian_horse »

dunefox wrote: post #20
bayesian_horse wrote: post #10

Earlier quoted context omitted.

Coconut, F# (Fable)... https://github.com/vindarel/languages-that-compile-to-python

F# is a great language... I wish I could use it at work.

One of the selling problems is that it can be hard to bring coworkers up to speed on it. Management don't like that kind of thing.

What management like very much is that using F# attracts better talent, but they no can believe.

Re: Python's “disappointing” superpowers

#218

Post by dunefox »

bayesian_horse wrote: post #217
dunefox wrote: post #20

Earlier quoted context omitted.

F# is a great language... I wish I could use it at work.

One of the selling problems is that it can be hard to bring coworkers up to speed on it. Management don't like that kind of thing. What management like very much is that using F# attracts better talent, but they no can believe.

It's actually very easy. If developers can't learn a slightly different language then they're getting paid too much.

Re: Python's “disappointing” superpowers

#219

Post by aragilar »

phailhaus wrote: post #130
ReflectedImage wrote: post #122

Earlier quoted context omitted.

[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…

There are numerous static analysis tools for Python that predate type annotations, the biggest of which are pylint and pyflakes.

Re: Python's “disappointing” superpowers

#220

Post by ReflectedImage »

lostmsu wrote: post #170
ReflectedImage wrote: post #145

Earlier quoted context omitted.

https://games.greggman.com/game/dynamic-typing-static-typing...

> has on average 2.5x the number of bugs This claim is not supported by the linked article. In fact, the main claim (only 2% of bugs are type errors) of the linked article also does not make any sense. It is based on the assumption, that typing errors only ever cause TypeError, AttributeError, or NameError in Python, which is, ironically, false, because Python is a dynamic language. To give a concrete example, I went…

The article says that dynamically typed code and statically typed code has a similar number of bugs per line.

It also says that a software feature only needs 1/2.5 lines if you are using dynamic typing.

That means dynamic typing reduces bugs by 2.5x compared to static typing per software feature.

Post reply on HN