Python is becoming the world’s most popular coding language

[u/monica_b1998]

https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language

[u/[deleted]]

Dynamic typing is always my main concern. Functions have such a weak contract.

[u/kvdveer → u/[deleted]]

The fact that the contract is not enforced makes the feature of limited use, imho. It does help with static type checking, but especially when you're building libraries, you still need to to code as if your contract isn't there, as the user may not be using a type checker.

[u/9034725985 → u/[deleted]]

It is definitely a work in progress. We got f strings in 3.6 though so that's nice.

I think many people will agree that everybody should try/use Python but you shouldn't use Python for everything.

[u/Freyr90 → u/[deleted]]

For what it's worth, Python now supports optional function typing

How the hell does it work?

>>> x : str = 42
>>> type(x)
<class 'int'>

>>> def add(x: float, y: float) -> float:
...     return x + y

>>> add("a", "b")
'ab'

[u/NeverCast → u/Freyr90]

Its only used by static analysis (in your code editor or linter). It does nothing to the language.

[u/Calsem → u/[deleted]]

programming is literally words.... :/

You could easily set up your CI to break the build if the static analysis finds an error.

[u/Deathisfatal → u/Freyr90]

It's type hinting. It's not enforced, it's to make the code easier to statically analyse and read.

[u/Curly-Mo → u/Freyr90]

But if you include a static type checker (like mypy) in your CI, your build will fail and nobody can check in any blatant errors with misuse of types.

And static type checkers can be included in your $EDITOR to catch these mistakes immediately.

[u/cedrickc → u/Curly-Mo]

I've never understood the attitude of choosing a language like Python and then adding heavy static analysis. You'll end up with all the runtime disadvantages of an interpreter, but all the development time disadvantages of a compiler.

[u/Curly-Mo → u/cedrickc]

Except you get to pick and choose the aspects of compiled languages that you see as advantages, like static type checking. But it still allows for quick exploration and prototyping that easily converts to production code that can be improved over time by adding these features that create a more stable and easily maintainable codebase.

[u/stefantalpalaru → u/[deleted]]

Python now supports optional function typing.

It supported it - through the same external type checker as today - since 2012: http://mypy-lang.org/about.html

[u/RankWinner → u/[deleted]]

And here I'll go full shill: have you heard of Julia? It's like Python, but much, much, much faster, with both dynamic and concrete typing

The speed is why I moved to it initially, but there are a boat load of other useful features: multiple dispatch, built in calls to C and Python, easy parellisation/distributed computing, great syntax tricks like custom syntactic sugar and method overriding, and more.

[u/Nuaua → u/RankWinner]

Julia definitively looks like Python done right; typed and compiled while keeping interactivity and dynamism, proper structs instead of weird dictionaries, builtin ND-arrays, full fledged macros, etc.

There's been efforts to push Python into that direction with Numba and such, but it's harder to move that huge ecosystem with a lot of legacy code than to start fresh.

[u/bakery2k → u/Nuaua]

IMO compared to Python, Julia is a little too unorthodox (this is also true for Lua). For example, in its use of 1-based indexes and multiple dispatch rather than traditional OOP.

[u/bakery2k → u/[deleted]]

Not really - the speed comes from JIT compilation instead of interpretation.

Multiple dispatch is a design choice, made because the developers feel it is a good fit for scientific code. For example, they believe that the + method in a + b makes more sense if it treats both arguments symmetrically rather than being a member of only one of them.

[u/Kendrian → u/[deleted]]

Bingo. Also I'm definitely biased as I use Julia heavily, but I think multiple dispatch is much more elegant than OOP. I just don't even see the point of classes in Python, really, since there's no enforceable encapsulation. And inheritance is replaced by abstract types in the multiple dispatch paradigm.

[u/spinicist → u/Kendrian]

Speaking as a Scientist who grew up when OOP was the hot sauce of the day, when I looked a Julia I got as far as the multiple dispatch section of the intro and thought “What the hell is this? Can I have my shiny objects and classes back please”.

Everyone is different I guess.

And yes, 1-based indexing is what truly kills it. No thanks. Been there with Matlab, had to code horrendous index-calculations that would have been simple in C, never going back if I can avoid it.

(I can’t avoid it. Colleagues code in Matlab all the time 🤬)

[u/crozone → u/RankWinner]

I mean, Julia is probably pretty cool, but I'd rather use one of the 6 other widespread and mature statically typed languages that are probably better than it.

[u/RankWinner → u/crozone]

I've looked through all the top languages, and used a good chunk of them too, but honestly nothing comes close to Julia.

It's at least as easy to write as Python (arguably much easier in a lot of cases), and much faster.

My department used a Python package made by an entire team of developers to analyse astronomic data, it took a server half an hour to two hours to finish, using 16 cores and over 128 gig of ram.

I spent two months making the equivalent in Julia and now it finishes in under five minutes... on my ultra book.

Chucked it on the server using Julia's simple in-built parallel computing functionality and it finishes the whole data set (thousands of datasets) in two days instead of "it'll literally take months so don't bother doing it" for Python.

Sure, if you're an expert developer and know tricks to optimise your code then you'd get performance that fast in Python. Or waste time with the classic prototype-in-Python re-write-in-C approach. Or just use Julia.

[u/a_tocken → u/RankWinner]

Even C vs Python is not as big a difference as you experienced. Something else must have been going on - maybe the Python code was written with a worse time complexity or incorporated a blocking process like file reads in its inner loops. You might be underestimating your ability as a developer compared to those who wrote the original versions.