←back to thread

312 points chmaynard | 1 comments | | HN request time: 0.203s | source
Show context
umvi ◴[] No.45058768[source]
I used to love Python, back when it was basically just an alternative to perl for scripting. Now it strikes fear into my heart when I encounter something largish written in Python because it usually means "super slow bloated researchy untyped ai/math code that's a nightmare to work with"
replies(13): >>45059009 #>>45059022 #>>45059024 #>>45059052 #>>45059135 #>>45059210 #>>45059388 #>>45059545 #>>45059897 #>>45060324 #>>45060738 #>>45060792 #>>45060836 #
cherrycherry98 ◴[] No.45059210[source]
Agreed, as an OO scripting language it's lovely, especially compared to Perl where the OO features never meshed quite right. Going back 10 years ago it had a number of things that were novel compared to other languages: literals for common data structures, context managers ("with" statement), first class functions, comprehensions, generators.

On the other hand duck typing is largely a joke. Letting functions take anything as an argument and then just assuming it's a duck with the methods you want is no way to write a robust system. Performance wise you're boxed into a corner. The slow runtime will have you writing native code in another language, complicating your project. The GIL will have you jumping through hoops to work around.

As an offline data exploration and research tool limited to an individual or a small team, or for writing small utilities, I totally get it. For anything mission critical I'd much rather be in something like Java or C# where the typing situation is stronger, the performance is going to be much better, I have better access to threads if I need them, the reasons for dropping into native code are fewer, and the cross platform support works more seamlessly without additional layers like Docker.

replies(2): >>45059998 #>>45060416 #
ActorNightly ◴[] No.45060416[source]
> Letting functions take anything as an argument and then just assuming it's a duck with the methods you want is no way to write a robust system

Everyone keeps harping on type safety, but it just doesn't play out in reality. Linux Kernel is incredibly robust, has never been a broken mess, and has basically no type enforcement, as you can cast pointers into other stuff.

In general, all typing does is move error checking into the compiler/preprocessor instead of testing. And time spent on designing and writing type safe code is almost equivalent to time spent writing tests that serve as an end-to-end contract.

There is a reason why NodeJS was the most used language before all the AI stuff came with Python.

>Performance wise you're boxed into a corner. The slow runtime will have you writing native code in another language, complicating your project.

Most of these performance arguments are similar to arguging that your commuter car needs to be a track spec Ferrari in terms of performance, by people that have very little experience with cars.

Plenty of fast/performant stuff runs on Python. PyPy is a thing also. So is launching small compiled executables like a process, that takes literally one line of code in Python.

>The GIL will have you jumping through hoops to work around.

This is just laughable. Clearly you have extremely little experience with Python.

replies(3): >>45061536 #>>45062095 #>>45062988 #
1. jibal ◴[] No.45062988[source]
> Everyone keeps harping on type safety, but it just doesn't play out in reality.

If you ignore the vast number of cases where it does, and cherry pick an extraordinarily non-representative example like the Linux kernel.

> This is just laughable. Clearly you have extremely little experience with Python.

Or you have extremely little experience with the use cases where it applies, extremely little knowledge of the ongoing effort by the Python developers to address it, and think that ignorant mocking is an argument.