Hacker News Reader

Comment by neverartful | Hacker News Reader

I've often found that starting some quick-and-dirty thing in shell scripts is great, but once I get to around 100 lines of shell script code, I'm better off switching to python (or similar). Similarly, once I get to around 1000 lines of python code, I'm better off switching to compiled, statically typed language (e.g., Java, C, C++, etc.).

So my own heuristic has become:

    shell script when < 100 lines of script
    python code when < 1000 lines of code
    else statically typed, compiled language

View on HN

I live by very suspiciously similar rules of thumb although my tolerance in the past for dynamic scripting languages was probably closer to several hundred lines of code.

However, I have to acknowledge that modern IDEs (and even advanced code editors like VSCode) have pretty good support for dynamic scripting languages these days that make working with them in larger code bases not entirely painful.

Yes, PyCharm was an amazing help.

I feel that Python has (among many, many other things) replaced Matlab and the likes.

These were the go-to "prototyping" languages people in science, R&D, etc. used (and still use!), and then you'd port those into more manageable languages for larger scale projects, or actual software products.

These days, Python does all that. Unless you need some extreme performance for your final product, a well-optimized Python program will work just fine.

But still, there's some of that matlab legacy left - instead of one comprehensive application, you have tons of smaller programs floating around, for one-off/single-issue uses.

On a continuing project with a company where everyone speaks Matlab as a second language, I succeeded in switching the guy writing Matlab code for the Matlab REST API to Python/numpy/scipy for the industrial analytics we need, saving us $25k a year in licence fees and VM costs.

This was my heuristic years ago before Python got type annotation support. Now there are linters that take type annotations into account, and LSP servers that can catch type errors as you write Python code.

I've found that using Python for large projects is both fine and productive as long as you utilize type annotations and modules. Ambiguity goes out the window when you do that.

I was really happy when I first learned of type annotations being added to Python. However, much of that excitement evaporated when I read that it was just a 'hint' and not something that's enforced.

This was also my initial reaction. However, if you couple type annotations with an LSP server[1] that takes the annotations into consideration[2], you'll get on-the-fly type checking in your editor or IDE. That way you can catch type errors as you write your typed Python code.

Besides VS Code, these days lightweight editors like Kate, Sublime Text, Vim, etc can all take advantage of type checking LSP servers for Python.

[1] https://github.com/palantir/python-language-server

[2] https://github.com/tomv564/pyls-mypy

It's not enforced by CPython the interpreter. You run mypy to enforce the type hints: http://mypy-lang.org/

It's quite good.

I like it a lot. Use it with --disallow-untyped-defs to make sure more is caught.

I was super hopeful about type hints but they fell short of my expectations, unfortunately. It takes you to a place full of kluges and workarounds and hacks which is all .... really unpythonic.

In the end I feel, if you really want that, use a language that treats types as a first class citizen. There are languages with most of Python's attractive features but actual optional typing (we use Groovy), or static with really good inferred types (eg: Kotlin) etc.

Nice guidelines! Though in my experience, the problem with the python code of < 1000 lines is that it tends to grow when you're not looking, and suddenly you find yourself needing to maintain (or rewrite) a Python monster.

what a really great way to think about it...i've been doing the same and hadn't thought of it that way (for decades)

Reply on news.ycombinator.com