Hacker News Reader

Comment by maxaf | Hacker News Reader

> But Python is not designed to be fast, and it is not designed to be safe.

When decisions made by an algorithm can result in real monetary costs, one must always err on the side of caution. Only an irresponsible person would choose Python or other unsafe, dynamically typed language when implementing a crucial piece of business logic.

View on HN

Python is a fine, accessible language for small programs. ML applications need to be written by data scientists, who are often trained in statistics or math, not software development. For this reason Python is suitable. ML applications built using tensorflow and other ML libs tend to be small -- hundreds of lines, not tens of thousands.

Python 3.6+ does have type annotations and multiple static analysis tools for type checking. Only an ignorant or biased person would yell at Python for flaws it doesn't have. For crucial business logic, one also writes unit tests.

Unit tests are not an adequate replacement for compile-time checks performed by a compiler. The former is lax and expensive, the latter is thorough and inexpensive.

Language flamewars are silly.

Sometimes python is appropriate for production code, weak type system or no. Sometimes it isn't. As a project gets larger, more complex, and more interconnected with other things, static type systems become more useful.

End of story, surely? Didn't we all know that already?

But you loose so much flexibility. When you start working on a problem, you want your language should give you as little headache as it can with minimum rules and constraints. Then on iteration you can improve like having type annotation, unit tests etc.

You can write perfectly fine production level code in Python. It like lego block. Start with simple and then add on.

Adding compile type checks comes with its own demerits. I guess here Swift is trying to offer more tool chain on compiler level for model building rather than just being type safe.

From the link:

> recent versions of Python have added type annotations that optionally allow the programmer to specify the types used in a program. However, Python’s type system is not capable of expressing many types and type relationships, does not do any automated typing, and can not reliably check all types at compile time. Therefore, using types in Python requires a lot of extra code, but falls far short of the level of type safety that other languages can provide.

I’ve used mypy and pyre on large Python 3.6 codebases and they aren’t even close to type systems in conventional imperative languages (C++, Java, etc) let alone the type systems in the ML family of languages where type system innovations are usually born. I’m sure they’ll get better with time, to an extent.

Currently, programmers are forced to pepper the code with lots of ignore annotation comments and redundant union types, just because the type checkers aren’t smart enough.

When you start seeing comments like these, you know the whole static typing thing has gone peak cargo cult.

I am curious what do you think when you see some JavaScript developers moving to Typescript or talks about Ruby 3 having types?

Types errors represent such a small class of errors. It’s just puzzling to see what all the hype is about.

Nope, all computation is representable in terms of types.

https://en.wikipedia.org/wiki/Curry–Howard_correspondence

Which is neither here nor there, as a contrived case.

In actual languages people us e(e.g. that have more than 2% of the job market), type errors caught by the compiler don't catch "all computation" errors.

Not even in Haskell...

In large sized projects, one of the most frequent activities you do is refactoring. For every refactoring, type errors often constitutes the largest class of errors by volume during initial development phases.

Then again, a language like Python keeps projects smaller, by not taking 100 lines to do what you can do in 10.

Have you written significant sized code base with dynamic languages (at least > 50K LOC)? If so how do you manage quickly and effortlessly finding errors like bad typo, passing around bad types etc? How do you refactor your code efficiently? My experience is that dynamic languages are great for small size projects but as the size grows the tax of maintaining things grows much faster than for statistically typed languages. People who have worked on large size projects in dynamic languages have to pay very careful attention to unit testing, for example. Little bit of lax attitude and you are looking at dreaded issues that will be uncovered only at runtime.

So genuinely wish to know what best practices you follow that makes developing large projects in dynamic languages make as inexpensive as typed languages to backup your comments.

>Have you written significant sized code base with dynamic languages (at least > 50K LOC)? If so how do you manage quickly and effortlessly finding errors like bad typo, passing around bad types etc?

Have you written 50K LOC C/C++? How do you manage finding errors like buffer overflows, use after free, and so on? And did the program have the same functionality as 50K Python, or had 1/10th the features?

(Also: you can run a linter and find typos, and you can have tests and know about bad types. And that's assuming those are actual errors people have and matter in the first place...)

From my perspective, I don't need to write a 50k LOC monolith codebase in clojure, which has just a few core types. I have become a fan of its `clojure.spec` data validation system if I do ever end up in such a world.

I've written those huge codebases in java, where our weekly github commits pushed like 5-10k lines of code per user. It would have been worse if it weren't for Lombok, and totally untenable if it weren't for IDE-assisted refactoring. I've since worked on much larger and more impactful problems with smaller clojure teams and seen work consistently get done in 1/10th of the LOCs.

I used to be a fan of static types -- I still am in limited contexts, but I've come to realize that statically-typed languages (especially object-oriented ones) usually lead to projects that _require_ static typing to even be maintainable. In contrast, a philosophy common to functional languages (which don't always have to be dynamic) is:

> "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." —Alan Perlis

I think discussions focused around type systems often miss the context of what languages' type systems we're actually talking about, and that context is way more important than making sweeping judgments about types.

I can count _on one hand_ the number of times I've defined a custom type in clojure in the 3 years I've been writing it professionally. Yes, sometimes I've called a hash map function on some kind of a list, but that cost has felt really small (and caught early) compared to the cognitive cost of keeping track of class hierarchies, interfaces, access rules, and annotations. And for what win? I still get NPEs, ClassCastExceptions, and RuntimeExceptions in Java, but now I have a whole class of errors and processes introduced around playing well with its inheritance model.

So, great, it's stopping me from directly instantiating an abstract ApiClient class, and quickly catching that I tried to get an HttpApiClient from an HttpsApiClientBuilder.build() call -- but that pattern would not have existed to present an issue were it a different language

Reply on news.ycombinator.com