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/
@trevdev @JonYoder I used CL some back in college, and dabble in elisp from time to time, but I'm not expert in either. I found Haskell particularly fascinating as I think it takes the FP paradigm further than even those do (via laziness and segmented side-effects). But Lisps could also serve the REPL need. Maybe someone else would know more (#Scheme is in this universe too, but I'm not fluent in it)
I'm into it mostly to train my brain on something that is not inspired by C. I discovered the Lambda Calculus and that made the exercise even more interesting.
I really like the syntax, it's so simple that other languages seem complicated to read for me now haha
Can feel weird at first but you get used to it : everything is expression (no statement), parentheses is the single expression delimiter, …
I don't leverage the REPL very far but I do use it pretty often.
Imagine a Python program running a Python REPL you can use to load new code to modify/extend the behavior of the Python program while it's running (more powerful than hot reload, https://www.gnu.org/software/guile/manual/html_node/Cooperative-REPL-Servers.html 👋 @dthompson )
@jeko @trevdev @jgoerzen @JonYoder @dthompson If you want to see how short solutions look in #wisp, have a look at the advent of wisp code 2021: https://www.draketo.de/software/advent-of-wisp-code-2021 — I solved the first 12 tasks of the advent of code there, with code from elegant to "I will replace the pilot by a simple bash script" :-)
The code is always doubled—look at the required change.
If you want to have a list of awesome things about Guile, have a look at the 10 ways GNU Guile is 10x better: https://www.draketo.de/software/guile-10x
@jeko @jgoerzen @JonYoder I am not a stranger to the parens and am in no hurry to get rid of them myself :) I am also trying to expand my mind a bit here. If that expansion can be practical, all the better.
This is part of why I am looking at Clojure(Script?) closer that Scheme or CL, but I would rather get lower level if I can.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!