Hacker News Reader

Comment by rxhernandez | Hacker News Reader

> I really have no clue why people love this language so much.

You get used to it somehow. I did C and Java for about 10 years before Python. My first exposure to Python was a Computational Physics class and it was maddening not knowing what types went where. Eventually you realize it doesn't really matter as long as you're disciplined and rely on others who are disciplined enough to document their code well. I haven't had the chance to use mypy in the 7 years I've been using Python (across 3 industries; medical devices, scientific devices, and web) but I would be surprised if it significantly reduced the number of bugs I've seen in practice.

View on HN

It’s certainly possible to write out types in English and cross your fingers and hope they’re correct and stay correct as the file gets edited by more and more people, but why do that when you can do it in a language that an intelligent type checker can understand and validate, and further use to provide smart editor tab-completions/etc?

This is especially big for any refactoring work - just yesterday I had to change the format of a config file that gets read by both TS and Python scripts. For ts, I updated the typedef and I instantly got every error in the codebase annotated. For python, I had to manually go through each line, using my own brain as the type checker. My brain is much faster and better at being a “squiggly red line spotter” than a type checker, so I finished my TS work in a few minutes and took probably an hour going through the python, despite the projects being similar in size.

This.

My experience with Python goes like this:

"I have to write a really small script... ok, not so small that I can do it with bash. I know, I'll use Python! This is going to be a small, throwaway utility anyway"

(Some weeks later, it's turned into a large monstrosity and I need to refactor something, and everything breaks because refactoring anything nontrivial written in Python is a dangerous proposition)

"Ouch! Python: never again!"

(Repeat a few weeks later)

I mean, you need to write tests before you refactor, but that's true in all languages.

I do agree (and have the scars to prove it) that this isn't a panacaea but it does help, a lot.

That being said, one of the worst bugs I had in python was in passing in the wrong types to a constructor function, and my tests didn't catch that. To be fair, Mypy would have, but I hadn't annotated that part. At the end of that debugging situation, I would have gladly killed somone for enforced static types in Python.

That being said, the data model is a work of art, and a core reason why I enjoy coding in Python. It's just a shame that pandas kinda sucks.

I find the problem with writing tests for Python is twofold:

- Most Python programs I write start their life as tiny scripts, always with the certainty they'll never grow (Narrator: they always grow). I don't know many people who write tests for their scripts...

- Testing in Python means too much effort in the wrong places. Consider that most refactoring problems would have been caught for free by a language with static typing. I've experienced runtime errors because I changed the return type of a function from a single value to a list (or viceversa). A statically typed language would have let me know of my mistake for free, so that I could focus on tests that really matter.

You can try Turtle next time, if you prefer fully type-checked shell scripts

https://hackage.haskell.org/package/turtle-1.5.19/docs/Turtl...

That's awesome. I love Haskell. Will definitely try Turtle next time!

Are types a free lunch or are there trade offs, what are you getting and what are you losing by adopting types?

How do the benefits you get, relate to the difficulty of problems you’re solving when programming?

Eg if the cost of types is increased coupling of code but the trade off benefit is it makes fixing typos easy then that’s a bad trade. You’ve made a hard problem more brittle in exchange for making a trivial problem even easier.

Could you give an example of how code could be coupled at the type level, but not logically coupled? It seems impossible to me.

> trivial problem

Type checking is quite non-trivial, especially as the logic and types get more advanced (conditional types, index types, mapped types, etc etc). Not just “typos”.

>> coupled at the type level, but not logically coupled?

    float multiply(float a, float b) { return a * b; }

You can’t add doubles with this code because it’s coupled to the float type. Summing a for b times has no logical coupling to floats or doubles just as floats or doubles have no logical coupling to either implementation of addition - both types are added by the same operations. You can swap the types or the algorithm.

Before you reach for the polymorphism or further pollute the universe of types consider that it costs less lines of code to erase types here.

What errors would preserving types help with here? What has more utility, less lines of code spent for the same outcomes or an implementation that exists further along the spectrum of typing in the “at compile time” direction? - I don’t believe that question can be answered but in practice i find less lines of code correlates more strongly with outcomes i care about than the degree of typing applied.

> What errors would preserving types help with here?

Pretty simple, it helps when you do a refactoring that changes the type of the value passed somewhere from number to number[] and the compiler instantly tells you that that’s illegal.

I did something similar just the other day when I had a shared config file read by both TS scripts and Python scripts and I needed to change the format to support a new feature. On the ts side I updated the typedef and the compiler pointed out to me every area that needed updating, on the Python side I had to spend a good chunk of time manually going through the script to figure out what needed updating.

>> it helps when you do a refactoring that changes the type of the value passed somewhere from number to number[]

Typing isn't a strong enough tool to combat that class of problem; you can fix the type signatures while introducing a semantic break. You need tests and if you have tests, what does typing bring? Keep your tests fast, measure and maintain a speed of >250 tests per second and remember to test behaviour not implementation - you won't go far wrong.

IDEs have been performing refactoring changes on our behalf in dynamic languages for years at this point. Don't manually edit when we've never had such powerful tooling available to us

  * https://www.jetbrains.com/help/pycharm/product-refactoring-tutorial.html
  * https://www.jetbrains.com/help/pycharm/structural-search-and-replace.html

Even concepts that i'd say are strictly the domain of static typying, like automatically pruning dead code behind retired feature flags, make headway today: https://github.com/jendrikseipp/vulture

Typing has a time and a place, that is without a doubt but the world is better viewed without the static typing lens permanently affixed in place, your efficacy will increase.

I don’t have tests for these small utility scripts and they work perfectly well. Tests also don’t pinpoint the error.

I’d never choose to have myself do more work if it’s not needed and the computer can do it.

Those automated refactorings would Not have helped in the situation I mentioned above.

Testing isn’t solely about whether code works today - you’re unlikely to checkin something completely broken. In fact i advocate NO tests for throwaway code, move fast.

It’s whether it continues to work tomorrow after you’ve added or removed a behaviour. Tests are the secret sauce that keep the cost of change low.

Refactoring (a commit with zero changes to test code) is the other key pillar of long term codebase health.

Are you counting null pointer exceptions? Because I think Mypy is pretty effective at combatting those.

Reply on news.ycombinator.com