5 ms·

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 swi

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

alyandon 6y ago
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.
- iainctduncan 6y ago
  Yes, PyCharm was an amazing help.
jjtheblunt 6y ago
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)
the_af 6y ago
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.
TrackerFF 6y ago
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.
- fatbird 6y ago
  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.
heavyset_go 6y ago
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.
- neverartful 6y ago
  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.
  - heavyset_go 6y ago
    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 https://github.com/palantir/python-language-server [2] https://github.com/tomv564/pyls-mypy https://github.com/tomv564/pyls-mypy
  - photonios 6y ago
    It's not enforced by CPython the interpreter. You run mypy to enforce the type hints: http://mypy-lang.org/ http://mypy-lang.org/ It's quite good.
    - animatedb 6y ago
      I like it a lot. Use it with --disallow-untyped-defs to make sure more is caught.
- zmmmmm 6y ago
  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.

alyandon 6y ago

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.

iainctduncan 6y ago
Yes, PyCharm was an amazing help.

jjtheblunt 6y ago

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)

the_af 6y ago

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.

TrackerFF 6y ago

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.

fatbird 6y ago
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.

heavyset_go 6y ago

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.

neverartful 6y ago
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.
- heavyset_go 6y ago
  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 https://github.com/palantir/python-language-server [2] https://github.com/tomv564/pyls-mypy https://github.com/tomv564/pyls-mypy
- photonios 6y ago
  It's not enforced by CPython the interpreter. You run mypy to enforce the type hints: http://mypy-lang.org/ http://mypy-lang.org/ It's quite good.
  - animatedb 6y ago
    I like it a lot. Use it with --disallow-untyped-defs to make sure more is caught.
zmmmmm 6y ago
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.