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

241–250 of 264 posts

Re: Python's “disappointing” superpowers

#241

Post by ReflectedImage »

Ferret7446 wrote: post #197
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

Your problem is C++/Java, not static typing. Static typing does not add many extra lines of code. In most cases, it adds no extra lines of code, as declaring variable/param types is done inline. Heck, just look at static typing in Python.

So Generics, Traits, Abstract subclasses, etc... don't exist in static typing?

As soon as the types get complicated, the code bloat begins.

Re: Python's “disappointing” superpowers

#242

Post by Daishiman »

ImprobableTruth wrote: post #50
joshuamorton wrote: post #36

Earlier quoted context omitted.

A lot of the orm style things are not really feasible in static-er languages without clunky approaches like codegen.

What part specifically? Java is (in)famous for its orms after all. Unless you want to count that as clunky codegen? I'd argue that all metaprogramming boils down to that though.

Java's ORMs are infamously clunky and both them and many of its modern frameworks make tremendous efforts to twist the language into an unidiomatic, dynamically typed thingy with a bunch of extra compilation in between.

By comparison using and modifying ORMs in languages like Python and Ruby feels like second nature.

Re: Python's “disappointing” superpowers

#243

Post by HdS84 »

dkarl wrote: post #233
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…

> I had a bug where I changed the return type of a function to be a tuple > If a given programming language community winds up bleeding members who are moving on due to the lack of better static type checking systems, then the people left will invariably be much more likely to be against static type systems. This reminds me of one of the things I hate most about the Python library ecosystem: libraries attempt to camo…

What's missing here is an Ienumerable from c#. That's basically anything that can be iterated like a list. So a function could take this enumerable and convert it to a list but should probably reject everything else.

And yes generally agree that Paramus should be not be too accepting. It gets confusing fast.

Re: Python's “disappointing” superpowers

#244

Post by HdS84 »

jchw wrote: post #110
ReflectedImage wrote: post #102

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…

I often think that may is just bad. It's type system feels bolted on and limiting. Where typescript can do many things and often teases me into a new pattern, mypy is ugly and stifling.

It's a pity. I really like types but mypy is just not great. It's ok, buts that's not enough for python.

Re: Python's “disappointing” superpowers

#245

Post by dunefox »

bayesian_horse wrote: post #223
dunefox wrote: post #218

Earlier quoted context omitted.

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

F# is a highly different language (at least from Python and Typescript) with additional concepts and I don't think you appreciate the problem for most companies to hire developers at all, let alone the kind of people who can hit a new language without a speed bump.

I would think any developer worth his salary can pick up a new language in a couple of months at most.

Re: Python's “disappointing” superpowers

#246

Post by renox »

cageface wrote: post #205
taeric wrote: post #194

Earlier quoted context omitted.

Amusingly, you don't know my actual stance. Which is probably closer to pro static types than to dynamic. My criticisms in this thread is that the static type brigade does not hinge on evidence. It is typically hollow claims and getting angry at dynamic languages for being obviously bad for lack of helping.

Hard evidence is hard to obtain for something as varied and unrigorous as software. After 25 years of working on all kinds of codebases I’ll take even badly engineered statically typed code over dynamic any day of the week including Sunday.

I don't know, I've worked on a C++ project where most of the Ids/Index 'types' are done with typedef/using int :-(

So in theory the language is statically typed but in practice case a large part of the project is 'integer typed' ..

Re: Python's “disappointing” superpowers

#247

Post by za3faran »

DarkNova6 wrote: post #135
jononomo wrote: post #71

Earlier quoted context omitted.

Unless you want to count Java as clunky? Well, I definitely think Java is clunky. This article by Steve Yegge, titled "Execution in the Kingdom of Nouns" sums up Java for me: https://www.eecis.udel.edu/~decker/courses/280f07/paper/King...

... this PDF is from 2006, the same year that Java 6 was released. Java 7 and Java 8 were game-changers at their time. I doubt there is much relevance left, especially in light of Java's excellent functional integration into its type system and JVM. Edit: ``` There's no reason Java couldn't simply add first-class functions and finally enter the grown-up, non-skewed world that allows people to use verbs as part of the…

Don't forget the many additional features since then, such as records, pattern matching, virtual threads, and more.

Re: Python's “disappointing” superpowers

#248

Post by lispm »

progval wrote: post #106
tmtvl wrote: post #69

Earlier quoted context omitted.

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…

Adding/changing/removing slots & methods. But also adding/removing superclasses -> which causes changes in existing objects. Having functions called when an object changes, etc. That's old in CLOS, end 80s. No wonder if some other dynamic languages by now have similar features.

Re: Python's “disappointing” superpowers

#249

Post by danpla »

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.

As I know, SPARK can do this (in particular, thanks to the strong type system).

https://learn.adacore.com/courses/intro-to-spark/chapters/01...

Post reply on HN