TIL that #Rust, while amazing, isn't so amazing for quick-and-dirty coding. It's like flying the Concorde for a 1-hour car trip.
@JonYoder There are reasons I often reach for the shell for quick-and-dirty things. But for anything serious, it quickly becomes a problem. In the days of Python 2, it was a good replacement, but with Python 3's inability to correctly handle POSIX filenames, environment variables, and parameters, I wouldn't bother. Rust is actually pretty decent for a lot of quick stuff once you get used to it.
@JonYoder I wrote a series of articles on this subject culminating in https://changelog.complete.org/archives/10063-the-fundamental-problem-in-python-3 . In short, I was so burned by my effort to port #pygopherd to #Python 3 -- and the utter crappiness and inconsistency of handling non-UTF8 in even the library bundled with Python -- that I consider it unsuitable for any purpose involving filenames, command-line parameters, or environment variables. One lovely tidbit is the zipfile.py tries to decode non-UTF8 sequences as cp437 in ALL cases!
@JonYoder If you want a coffee with your reading, after that first link, you can check out https://changelog.complete.org/archives/10053-the-incredible-disaster-of-python-3 and https://changelog.complete.org/archives/9938-the-python-unicode-mess . The upshot of it is, as far as I can tell, it is impossible to write cross-platform #Python code that handles filenames correctly on both POSIX and Windows. #Rust gets this right, and Python's attempt to assume the whole world has used #Unicode since the beginning of time is a real pain.
@JonYoder Avoiding #Python - Besides the absurd inconsistencies in https://changelog.complete.org/archives/10053-the-incredible-disaster-of-python-3 and the extreme difficulty verging on the impossibility of properly handling filenames in POSIX (see https://changelog.complete.org/archives/10063-the-fundamental-problem-in-python-3 and https://changelog.complete.org/archives/9938-the-python-unicode-mess ), there is more that makes me shy away. 2/
@JonYoder It is astonishing to me that #Python still has a Global Interpreter Lock in 2022. https://wiki.python.org/moin/GlobalInterpreterLock Multithreading in Python is mostly a fiction. There are kludges like https://docs.python.org/3/library/multiprocessing.html which use fork, pipes, pickling, and message passing to simulate threads. But there are so many dragons down that path -- performance and platform-specific ones (different things can be pickled on Windows vs. Linux) that it is a poor substitute. 3/
@JonYoder When I started using #Python more than 20 years ago now, it was an attractive alternative to Perl: like Perl, you don't have to worry about memory management as with C, but Python code was more maintainable. By now, though, even writing a Unix-style cat command in Python is extraordinarily complicated https://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ . All the "foo-like objects" are an interesting abstraction until they break horribly, and the lack of strong types makes it hard to scale code size. 5/
@JonYoder The one place I still see #Python being used is situations where the #REPL is valuable. (Note, #Haskell also has this). #Jupyter is an example of this too. People use #Python for rapid testing of things and interactive prototyping. For a time, when I had date arithmetic problems, I'd open up the Python CLI and write stuff there. Nowadays it's simpler to just write a Rust program to do it for me, really. 7/
@JonYoder So that leaves me thinking: We're thinking about #Python wrong these days. Its greatest utility is as a shell, not a language to write large programs in. As a shell, it is decent, especially for scientific work. Like other shells, most of the serious work is farmed out to code not written in Python, but there is utility in having it as a shell anyhow. And like a shell, once your requirements get to a certain point, you reach for something more serious. end/
What an alien thing to say. All you have to do is open up github.com or any job listing website to be proven wrong.
I write this using Qutebrowser on Qtile started from a Xonsh shell - Python is not fit for writing large programs! /s
@Wraptile @JonYoder 1/ I have several responses to that. First of all, popularity does not equal suitability. I would say that, today, C isn't really suitable for writing large programs in. I am perfectly aware that many large programs are written in C; I have worked on them personally and professionally. But factors other than suitability come into play (eg, the high cost of rewriting an existing code base in a new language, institutional inertia, dev team skillset, etc.)
@Wraptile @JonYoder You think that economic activity is the measure of quality? Well then, I guess we should have just given up on Linux in 1995 then, because everything from Windows to AIX had more economic activity than Linux.
I absolutely reject the notion that cash equals quality. That notion excludes the possibility of new and better things, because the new will necessarily have less economic activity - that doesn't make it worse. 1/
I can't help but notice that none of your arguments are technical. I'm sorry, but arguments that boil down to "X makes more money than Y" or "X is more popular than Y" are utterly unconvincing in a technical conversation. I have spent most of my life seeing the less-popular solutions be better than the popular ones in material ways.
@Wraptile @JonYoder I am happy to have a conversation with you about the technical merits of different approaches, but if your arguments are all going to be about popularity, I find that irrelevant, unconvincing, and not worth the time discussing. I'm happy to have a technical conversation but would rather spend my time at a keyboard doing something other than arguing about things that don't matter.
You list couple of edge scenarios like newlines in filenames being allowed as some sort of stink against language when it's not going to be encountered in 99.999% of programs and can be fixed with a single line of code. Your second question is impossible to answer - how do you prove tech merit of a language?
@Wraptile @JonYoder This is the kind of attitude that gave us thousands of security bugs over the years. I *directly* addressed this oft-repeated argument in https://changelog.complete.org/archives/10063-the-fundamental-problem-in-python-3 . It's not just a matter of one or two lines of code; it's an utter inability to, eg, extract a ZIP file correctly. You're also ignoring the very real reality of the GIL, which makes a language unsuitable for a wide range of tasks in today's multi-core-is-standard world.
@Wraptile @JonYoder The fundamental point I was trying to make is not that Python is bad for all tasks. Just that it makes simple things (dealing with filenames and stdin) extremely difficult, has semantics that lead to vastly counterintuitive results with comparisons, and with more modern type inference, the weakly-typed nature of it isn't holding up well. This is why I personally would not reach for Python, given a choice.
@Wraptile @JonYoder I have long since passed having an emotional attachment to languages. I have had books published (by O'Reilly, APress, and others) on C, Python, and Haskell. I've contributed significant libraries to OCaml and Haskell, including a popular database layer for Haskell. And here I am writing code in Rust. Use what makes you happy, I don't care. But don't try to tell me Python's filename handling is correct, because it objectively isn't.
@jgoerzen @JonYoder I'm not saying it's correct I'm saying it's statistically insignificant. Having more people being able to work and solve problems in an elegant, sustainable fashion is more important than handling 1 edge case that will be encountered by one program and that can be patched with a line of code or a community package.
If you want to play this game of edge cases then you can put any language down even Rust - it's an absurdist, pointless, argument.
@Wraptile @JonYoder Except none of your premises are correct. The problem is pervasive in the Python ecosystem. Community packages get it wrong, the standard library gets it wrong, and it has significant real-world consequences (eg, gpodder crashing), and it is not a matter of a one-line fix. Using the wrong data type for a filename is a pretty fundamental problem. And it's not the only problem; the GIL is another fundamental problem; multithreading in Python is a fiction.
@Wraptile @JonYoder That's not to say there are zero cases where Python is a nice fit; I pointed to, eg, rapid prototyping with Jupyter. But what I'm saying is if a modern language is incapable of multithreading and has a community-wide problem around such basics as filenames and comparisons, and better alternatives exist, why reach for the one where it is freaking difficult to open a file properly or parallelize algorithms in the general case?
For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).