Hacker News Reader

Comment by tus88 | Hacker News Reader

Do people who complain that Python doesn't have typing are effectively arguing against the very existence of every scripting language and Lisp in the world?

View on HN

I'm getting sick of hearing people complain so much about Python's type system. I'm actually in favor of strong typing, but some people grossley oversell its value - especially on HN.

The overwhelming majority of code I work with is in Python and I can't remember the last time I encountered an issue caused by invalid types. Static analysis tools, good documentation, and peer reviews (things that should be part of any critical code development) almost always prevent those sorts of issues.

Strong typing is great. Just don't exaggerate its effectiveness.

Strong typing has hidden value that goes far beyond bug avoidance. It is tremendously important for performance. The only way to get performance out of Python is to cheat: use a not-quite-Python that violates normal Python behavior, use a hack that lets you insert C code into your Python, or simply call a few heavy-duty library functions to do all the real work.

> simply call a few heavy-duty library functions to do all the real work

Which is the main advantage of python. Since there are heavily optimised libraries for everything from optimisation to numerical analysis to ML, 99% of people don't need to attempt to be a Real Programmer and write the hand-optimised Fortran/C/assembly code themselves.

The type system is only one of many issues responsible for Python's lack of performance.

I understand the benefits of static typing. I'm just tired of it often being so overstated.

None of my projects in python suffer from performance issues, because it's fast enough. Albeit I just work in the automation space. I do use C for embedded but only because we just don't have the memory capacity for python to run multiple daemons on my IoT projects, it's not because of performance.

You probably meant statically typed, python already is strongly typed.

I can. A project I've been involved with a bit lately has several of bugs of the form "I expected X but got None" where None was a rare case. Or using `if not foo` instead of `if foo is not None`, where the actual error can occur very far away from the if statement.

A type system is a good way to get static analysis and documentation :)

To be fair, many languages that have static typing (Java) allow for a null value regardless of type. Systems like that wouldn't help in yout case.

Scripting languages are for writing scripts. Production code is much better served by typed languages.

Use a Ferrari on a racetrack, use a fortified tank on the battlefield.

I'd go one step further, I would accept the existence of both typed and non-typed "runtime" versions of Python (i.e. a run-time flag or program argument). Writing a quick script? Reach for the non-typed version. Writing production software? We ought to make sure we're type checking. Default to non-typed to stop beginners breaking their code.

The same with something like JIT vs compiling, I don't want to find out that some edge case a quadrillion loops in has some simple error a compiler could have found.

mypy can be used to achieve the same effect, but I would also like the ability to enforce types at run-time, and it would be great if more tools made use of PEP 484.

I’m not sure what your analogy is getting at. Many typed languages are compiled. A lot of them are faster than interpreted languages—also, because they are typed, they could be referred to as fortified.

I think the speed of the Ferrari in this case is referring to the speed of development in a scripting language (not the speed of programs written in the language), and the protection of a tank is referring to the protection from certain classes of errors that static typing gives.

Ah I see. Though that in itself seems to be a matter of opinion/comfort with a language.

I’m a much faster developer in languages that are able to produce decent documentation about their typed interfaces, than I am in languages that are much more loosely defined.

There’s an amount of uncertainty in interpreted languages that always leaves me questioning the code—uncertain that it handles the cases I think it does.

Yup! I think you may be referring to a more production like usecase here. If you had to parse a csv to convert a column from Fahrenheit to Celsius and output that with the first column in a separate csv (dummy example) - python is so much faster to develop.

If you had to write this as a feature in a maintainable way, that's when python would start to suck

No.

All languages are typed in one way or another. Unless you write a generic function, you cannot evaluate (+ 2 "a") in scheme. Here is racket's error message:

    > (+ 2 "a")
    ; +: contract violation
    ;   expected: number?
    ;   given: "a"
    ;   argument position: 2nd
    ; [,bt for context]
    >

The function absolutely expects its arguments to have a certain shape (type). The difference with C is that variables don't have types set in stone, they can... vary. The compiler/interpreter just takes care of them for you.

But you cannot tell ahead of time that you cannot evaluate (+ 2 "a").

If the code wasn't so obvious as the above example, you'd have a hard time mentally working out the correctness. E.g., given both (shoot camera person) and (shoot gun dummy), you'd not want to accidentally pass in the wrong arguments like (shoot gun person).

Python is strongly typed just with Late Binding.

https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...

Types are very important for writing large scale software. Proceeds using `int` for most of the things in the program

Some scripting languages having types, like TypeScript for instance.

The term we’re probably reaching for is interpreted vs. compiled. Typescript is a compiled language, it compiles to JavaScript, with a variant now targeting WASM.

Python has typing now and you can check your program against these types by using mypy

Reply on news.ycombinator.com