JavaScript as a more coherent alternative to python?!?!
Breaking up with Python
61–70 of 179 posts
Re: Breaking up with Python
#62Pretty amazing success for the Python standard library to be labeled as barebones.
Yeah, that caught me off-guard, too. I agree, though, the urllib module that he links to it's not the best thing ever when it comes to Python, and I say that as a guy who has written Python code for a living for 17 years now. But other than that I find the standard library more than ok. The only thing that I can agree on is the slowness, but even that is relative, as we're not all writing speed-critical code. The typ…
> the urllib module that he links to it's not the best thing ever
I think the reason it (and the http modules in general) has never been improved is that even when Python was young, there were better third party packages out there, but no single one of them ever got to the point where the Python devs would consider making it part of the standard library. Particularly when it comes to servers, there have always been multiple third party frameworks with significant market share. For clients, we might be getting to the point where the requests library is common enough to be a candidate for the standard library.
Re: Breaking up with Python
#63Agree with syntax and slow, the others not so much.
But my bigger reason for avoiding Python when I can is I just think the days of dynamic languages are behind us. Which is to say, we are past the tipping point where the ergonomics of adding typing are less costly than the benefits, and that applies even for short scripting use cases (in part because so many short scripts grow their way into real production code that needs to be maintained).
I went down the rabbit hole of adding type hints but at the end of the rabbit hole it was a lot of work and the value realised was still only 50% of that from having a real type system. Vast numbers of type errors still not getting caught in my editor, autocompletion stymied at shallow points where the type system gets lost, and as the weight of the project grows the tools like MyPy getting slower and slower as they have to process massive amounts of the dependency tree just to infer the type of the single line you are typing.
These days even for short scripts I am preferring to write them in languages like Groovy which get me all the benefits of Python from the dynamic language point of view but built on a foundation of a real type system which means I have a pathway to grow the code into full static typing using any of the JVM languages if I want / need to. And it also largely solves the problem with performance.
Re: Breaking up with Python
#64> Python’s documentation sucks I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point. > Python’…
Python's documentation is good, but it's a departure from expectations if you're used to Javadoc-style documentation of APIs. You can get just that by providing good docstrings in your library's code or using documentation generators like Sphinx and whatnot.
Agree with the rest of your points, though, except not liking newer syntax. Newer syntax, in my experience, makes writing code less of a chore and mirrors the developer conveniences in other modern languages.
Re: Breaking up with Python
#65Python is the shittiest option, but the only one for a wide variety of tasks.
Everyone loves to hate it, but you gotta use it.
I disagree about the documentation/syntax/std lib gripes, but everything else is a pretty reasonable issue.
Re: Breaking up with Python
#66Pretty amazing success for the Python standard library to be labeled as barebones.
Was very surprised to see that in the article! My complaint is the Python std lib is bloated. If I could design a Python 4, it would be a subset of Python. Ie get rid of the various struct-like data structures (eg both types of named tuple) other than dataclass that have accumulated over time.
Re: Breaking up with Python
#67> Python’s documentation sucks I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point. > Python’…
>> Python’s standard library sucks
> I have to disagree again, I think it is pretty well designed and minimal on purpose
Oh come on. That’s like saying “this buffet has no food selection but that’s good cause I’m on a diet”. Meaning that you like that it sucks (that’s fine).
Numpy is not the kind of thing you would include in the std lib anyway.
> OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
Fair, but I’ve spent enough time python environment/dependency hell that a lot of those gains (which are mostly cognitive) weren’t worth it for me.
Re: Breaking up with Python
#68> Python’s documentation sucks I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point. > Python’…
Python class syntax sucks. Other syntax is mostly nice. List comprehensions etc are great, I really wish I had those in c++. Plus, I wish I had a similarly useful standard library, repl, and package manager in c++.
you want `self` less class methods ?
Re: Breaking up with Python
#69I tried python in 2010 because looks easy, but Go came on stage, and changed backed tools. Go is the way to better backend, CPU and memory optimized. I read an article that Dropbox save thousands just by change from Python to Go. It's difficult, especially handling shared variables in go routines, but it's worth it.
I'm not sure go should be compared to python as they are designed for very different things. Go is more fairly compared against modern c++ or rust in my mind. Python is not designed to be lightweight or fast (although it has been consistently improving with each release) but favors expressability and run time flexibility instead.
Re: Breaking up with Python
#70I don't disagree with any of his points, actually, and agree with almost all of them. The standard library has some holes - though I think that's true everywhere. I don't know that eg Ruby or java don't have holes either. I do think the packaging Story in python is nuts. Why does gem just work for Ruby but python's story is such a disaster? Though imo my modern advice is "just use poetry and ignore everything else".…
> I do think the packaging Story in python is nuts.
That is one of my three big gripes with Python. The other two are the horrible way the 2 to 3 transition was managed and the GIL.
But none of those has driven me to switch to another language, nor do I expect it to. Go seems to be this author's alternative of choice; perhaps if my one goal in life was to write a production network backend without using any dependencies, I might agree, but it isn't, and having done some work with Go I find it gets in my way much more than Python does. I have the same problem with other languages.