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

191–200 of 264 posts

Re: Python's “disappointing” superpowers

#191

Post by taeric »

kumarvvr wrote: post #190
taeric wrote: post #158

Earlier quoted context omitted.

This is almost always framed in a way that shows large systems need the extra rigidity of some static systems. And that dynamic systems are only about rapid prototyping. I think that is a bit of a false framing. To wit, any system of 100k LOC will be hard to get into. Even harder to make changes in. There is no getting around that. None. Even worse if you have many entities flying about these 100k LOC. Each change to…

> any system of 100k LOC will be hard to get into To get a gut feeling of the system, i.e., to understand the 10000 foot view of a 100k LOC system, is orders of magnitude easier with statically typed languages than dynamic languages. And that is mostly because those 100k LOC are done by probably dozens of developers and that leads to different styles, approaches, conventions, etc. A statically typed language would re…

I call bs in this. To get a 10000 foot view of a codebase, you lean on diagrams and other lies of documentation. Note that I don't mean malicious lies. I mean simplifications and other happy path discussions of how things work.

This is no different from any system. Want to know how your car works? Start with a simplified diagram and gradually add more details.

Cars and other equipment are an amusing case study. What is the strongly typed version of a car schematics? Why does it look so different from what we think the idealized software should look like?

Re: Python's “disappointing” superpowers

#192

Post by taeric »

random314 wrote: post #188
taeric wrote: post #185

Earlier quoted context omitted.

Then do said survey? Find empirical evidence and share it. My experience, sadly, is the louder a dev on the team is about either dynamic or static typing, the more likely that dev's code is something nobody else in the team wants to work with.

Here is one sample point for your survey. Static is better than dynamic for large projects, in my experience.

You should have more than one point of data. How many software systems? How old were they? How many contributors? How many bugs in each? Were any of them green field?

Re: Python's “disappointing” superpowers

#193

Post by random314 »

taeric wrote: post #192
random314 wrote: post #188

Earlier quoted context omitted.

Here is one sample point for your survey. Static is better than dynamic for large projects, in my experience.

You should have more than one point of data. How many software systems? How old were they? How many contributors? How many bugs in each? Were any of them green field?

Dude, you have already made up your mind, so I am not going to do any homework for you that you yourself aren't performing. You are not my boss, or anyone's boss here

Re: Python's “disappointing” superpowers

#194

Post by taeric »

random314 wrote: post #193
taeric wrote: post #192

Earlier quoted context omitted.

You should have more than one point of data. How many software systems? How old were they? How many contributors? How many bugs in each? Were any of them green field?

Dude, you have already made up your mind, so I am not going to do any homework for you that you yourself aren't performing. You are not my boss, or anyone's boss here

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.

Re: Python's “disappointing” superpowers

#195

Post by deshpand »

spoils19 wrote: post #149

I used to be a huge dynamic languages fan, with python being my favorite language over the majority of my career. Then I worked on a large python project of ~100k LOC with a team of ten. That's when I realized that writing code faster isn't the problem. Reading it is, making changes to code someone else wrote is, and refactoring across dozens of modules is a problem. Static languages help a lot with all three. I stil…

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

Re: Python's “disappointing” superpowers

#196

Post by phailhaus »

pdonis wrote: post #187
phailhaus wrote: post #178

Earlier quoted context omitted.

There is no difference between `object["hello"]` and `object.hello`. So in Typescript, all you need is `interface`, that's it. Everything (except primitives) is just an `interface` with keys or index signatures. > Of course. With dataclasses that's what Python itself does; that's a pure Python module: Sorry, I meant that you can't create an equivalent class that typechecks the same way. For example, when you define a…

> There is no difference between `object["hello"]` and `object.hello`. Ah, ok. Technically I suppose one could unify these in Python; attribute accesses on objects are really dict lookups under the hood, and one could implement a list as a dict whose keys were restricted to be integers. But yes, Python chose not to go that route. > I meant that you can't create an equivalent class that typechecks the same way. Well,…

> You mean you lose some functionality with third party type checking tools

No, I mean that Python cannot express this relationship with type annotations. That's why plugins are necessary, because the language doesn't support it. I think the same is true for `TypedDict`, which is why the community had to wait for official support before it could be used.

These fundamental limitations of the language prevent the community from effectively building new tools with similar behaviors. You have to either write your own plugin for the n different 3rd party type checking tools, or hope it gets pulled into an official Python version (at which point the n different type checking tools will implement support for you).

Anyways. This started off because of the claim that Python doesn't need typechecking as much because it has a simpler data model than JavaScript (at most, you can claim they are equivalent), but it's turned into gripes about how half-baked the type annotation syntax is. All of this to say: it could have been a contender! It could have been like TypeScript!!

Re: Python's “disappointing” superpowers

#197

Post by Ferret7446 »

deshpand wrote: post #195
spoils19 wrote: post #149

I used to be a huge dynamic languages fan, with python being my favorite language over the majority of my career. Then I worked on a large python project of ~100k LOC with a team of ten. That's when I realized that writing code faster isn't the problem. Reading it is, making changes to code someone else wrote is, and refactoring across dozens of modules is a problem. Static languages help a lot with all three. I stil…

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.

Re: Python's “disappointing” superpowers

#198

Post by Ferret7446 »

RobotToaster wrote: post #87
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.

Isn't the C preprocessor a type of metaprogramming?

Strictly speaking, yes. Generally speaking, not really. Metaprogramming implies first class support (i.e., using the language to generate itself)

Re: Python's “disappointing” superpowers

#199

Post by joshuamorton »

abdullahkhalids wrote: post #47
joshuamorton wrote: post #35

Earlier quoted context omitted.

Right, in langs with c-style scoping, this is an issue, but in python if foo: x = a else: x = b Works, so there's no need to predeclare.

A very common pattern in python is to declare all instance variables of a class in the __init__ method by setting them to None. This is done for * code readability; all relevant variables are in one place * Python is a prototyping language, and a very common usage pattern is doing dir(object) to determine the names of all variables that could be set to something.

This is no longer needed with modern python, you can use

    class Foo:
        my_int: int
To handle this. That said, for the second case, a variable that may be set to something but may not be is optional! That's correct behavior!

Re: Python's “disappointing” superpowers

#200

Post by sa46 »

deshpand wrote: post #195
spoils19 wrote: post #149

I used to be a huge dynamic languages fan, with python being my favorite language over the majority of my career. Then I worked on a large python project of ~100k LOC with a team of ten. That's when I realized that writing code faster isn't the problem. Reading it is, making changes to code someone else wrote is, and refactoring across dozens of modules is a problem. Static languages help a lot with all three. I stil…

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
Post reply on HN