Hacker News Reader

Comment by emodendroket | Hacker News Reader

There is part of me that wants to laugh at people independently discovering over and over again that static typing is actually useful after dismissing it, but I'm just glad it's available more places.

View on HN

I won't deny that static typing is great. You're just never going to get rid of Python.

Python is just an incredible language to learn programming in and an extremely productive language for building small-to-medium sized apps. Type hints + making type checking part of the build stage helps, a lot in my opinion. With these + tests in place I almost always experience that I can refactor safely.

I would use a statically typed implementation of Python in a heartbeat, I really hope it gets made.

Have you heard of https://nim-lang.org

I keep hearing about nim and I've normally ignored it because Rust is good enough for me. Recently, I got curious if itd be a good fit for my coworkers, so I started giving it a look.

I'm baffled at all the python comparisons. Yes, it as significant white space, but that felt like it. It felt more like Ada or some other language than python.

The one thing I did appreciate was `(;)` for turning statements into expressions. I've grown to love having complex expressions in Rust and miss them in other contexts. However, Python's scoping reduces the need for them.

Don't be silly, no one is claiming to be "independently discovering" anything. Typing is a tool, just like anything else. When I'm working with Python, I specifically want types during development (thanks PyCharm) but not at runtime. I spend a lot of time in my code, and type hints provide the same structure to Python code that they add to Java except when I don't want to worry about them.

What are you referring to when you say you don't want types at runtime? Every Python object has a type and type-checks will be performed at runtime (e.g., "hello" + 42).

Duck typing. A Python object doesn't have to have a specific type, just the attribute(s) you want. You'll find a lot of "hasattr(obj, x)" throughout any large Python code base. It's nice to not have to worry about creating single-method/single-attribute interfaces and dot them all over the place.

Good point. But how can you know the types statically (at development-time) without defining interfaces?

You could specify that your method takes an object which has method XYZ accepting an int as its parameter and returning another int -- a kind of "anonymous" interface, I guess. Personally I don't like this kind of stuff because there's no guarantee that two objects with a convert method do the same thing when that method is called.

What I mean is, a while ago you were hearing a lot of ra-ra stuff about how great dynamic languages were because static typing was just a waste of time that made you less productive. And then sooner or later all those languages evolve a documentation system with types in it, and then type hints, and so on, as it becomes clear that those earlier claims weren't true for long-lived projects.

You see the same in reverse with many industrially popular statically typed languages gaining dynamic escape hatches, such that optional static typing, from one end or the other, is pretty much the uniform rule for industrially popular languages.

That is true, but as I see it the use of the dynamic features in statically typed languages tends to be much more limited, with most preferring it as an absolute last resort.

Really? I feel like stuff like DI frameworks are super common in Java, and they're essentially dynamic magic.

I'm more familiar with C#, so there may be differences, but while the DI containers do do a lot of dynamic work, it is carefully abstracted so that all code the user writes to interact with the container is type-safe. It's very rare for methods in these languages to return object or dynamic, and slightly less rare but still far from common for these to be arguments.

Isn't enabling this style exactly why generic support was such a big deal?

> I'm more familiar with C#, so there may be differences, but while the DI containers do do a lot of dynamic work, it is carefully abstracted so that all code the user writes to interact with the container is type-safe. It's very rare for methods in these languages to return object or dynamic, and slightly less rare but still far from common for these to be arguments.

Sure, but this is true with (most) weird dynamic code in dynamic languages too. Just look at something like `attrs`. Its letting you dynamically construct classes, but you can do so in a type safe way.

The static typing I care most about is function signatures, because it 1) helps my IDE catch me invoking things in unintended ways 2) lets me figure out how to use a function without reading it. Inside the body of a method, go nuts, I don't care. But whenever I'm dealing with a long-lived project I find signatures are a big help.

The addition of type hints to python is a huge part of what pushed me over the edge. I kind of wish I had tried it earlier, it's pretty awesome for PoC and fairly simple programs.

Reply on news.ycombinator.com