Python's lambda sums up everything that sucks in Python. It's a crippled, half-assed implementation of something which is considered a basic requirement for any programming language aiming for mainstream adoption. Even Java 8 did a better job after realising it wasn't too late in the day. Python's virtualenv requirement is also another admission of failure, IMHO.
Breaking up with Python
151–160 of 179 posts
Re: Breaking up with Python
#152This is garbage. It typifies a kind a drive-by rant disguised as a rational opinion that is basically insulting to the intelligence of everyone, regardless of language preference. The level of narcissism and pettiness is high, and the level of rational discourse is low. Entitled spewing of garbage.
> Python’s documentation sucks
Dead giveaway. Well, it doesn't suck. It's pretty great, pretty comprehensive. OH... Wait, ot isn't formatted with a index pane. that's why it sucks. The author probably has problems with the font-kerning too.
> Every project seems to use a different tool and it’s a massive headache
Um, no. Everything really uses pip. I don't even really like pip, but everyone uses it so I use it. You know why? Because it's never, ever a pain in anything at all. It just works.
> Python’s standard library sucks
What? is this satire?
> Python is huge
This has got to be satire. Author prefers "go". Nothing wrong with go, but nothing wrong with Python either.
> Python syntax sucks.
Nuts! this guys is legit insane. The only really controversial thing is the whitespace-indent vs. delimited thing. Guess what? I really dislike the indentation scheme. You could have a reasonable debate over that relatively unique syntax scheme. But the entire syntax as a whole is cleverly regular, predictable and tidy.
> Python is slow
Well, as the author said, "Python has been my go-to language for a quick bit of scripting". Slow is a perfectly acceptable trade-off there. And you could certainly come up with a different set of trades that also make sense. To say "SUCKS" implies it's just stupid and sub-optimal everywhere; a lose-lose-lose-lose. Which it isn't.
> It’s like everything under the kitchen sink has been jammed in.
I though you said that the standard library "sucked"; is there too much sink or too little? "let that sink in"
The author seems to be infatuated with javascript and go (at the moment), but neither is really in the same niche as python. That doesn't make any of those other choices "suck".
Larry Ellison and his company and products suck. Software patent trolls suck. Python does not "suck" because you like other things at the moment.
Re: Breaking up with Python
#153Earlier quoted context omitted.
Node is an interpreter just like Python, gives access to OS features like sockets, file systems and processes, so yes, you can. However I’d rather not if you value your sanity and want to use typescript, because then you introduce packages and compilers and the whole npm ecosystem which makes building C++ look easy and sane.
It is the first time I see gyp being called easy and sane.
To build what I’m currently working on it is required to use docker, pnpm, npm, nx, tsc, corepack and nvm. I think. Not sure at all. I haven’t built some parts of the project. There’s more involved to run most tests.
Something went off the rails at some point.
Re: Breaking up with Python
#154Earlier quoted context omitted.
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 type annotations never took off I don’t think that’s true; I think that type annotations have been seeing significant gains in usage in Python in recent years.
Have they? Genuinely asking. The recent code samples I did see on SO don’t yet include them and the one big Python project (Django) that I use hasn’t started making use of then just yet, or at least not to my knowledge.
Re: Breaking up with Python
#155Earlier quoted context omitted.
Python doc peaked for me with the 1.x “library index to keep under your pillow” https://docs.python.org/release/1.5.2/lib/lib.html
> Python doc peaked for me with the 1.x “library index to keep under your pillow” I can see why that’s nice, but I find it odd to be described as a peak. While the details of the standard library it documents have evolved, I don’t see how the current version (linked from the main docs site with the same “keep this under your pillow” line) of the same portion of the docs is any worse: https://docs.python.org/3/library…
Because it’s so much more readable without being littered with numerous examples and footnotes all over the place.
It just gave you exactly what you needed to know and otherwise stayed out of the way. Remember l, this was from an age when online doc didn’t really exist… I certainly never used the html version.
When you’re on dialup a local, quickly searchable version was very valuable.
Re: Breaking up with Python
#156Earlier quoted context omitted.
I appreciate the response; as I say, YMMV. I did feel a little misunderstood at the end of that response, though, so I'll clarify. > explicitly stating things you don't kno2 or understand I've done Windows development since 3.1 (and .Net since 2001) so in that time I've written a lot of PowerShell. I'm not offering uninformed second-hand opinions. For (a) I'd argue that the lack of adoption outside Windows makes it d…
> lack of adoption outside Windows makes it de-facto not really a transferrable skill If you want to only write/use PS - then probably , but... if this is yours environment - you chose the tools, if it's not - the overall concepts and workflow doesn't differs too much, especially for Python. I had an unpleasant experience of rewriting a Python 2 script to Python 3. At some point I just said "fuck it" and rewrote it,…
Some good points (though I remain unconvinced about PS personally).
The only thing I'd note is that unfortunately by not mentioning it in my earlier reply I left you thinking I was suggesting Python over PowerShell, which makes sense given the way others were discussing the topic.
On this, however, I agree with you in that I too would not automatically suggest Python as the best learning language. I'd actually plump for Go scripting or C# (single file), but on the understanding that it's for learning business domain or web programming. For the true beginner I don't really have a strong opinion so maybe PS could work.
Anyway, thanks for the detailed response :)
Re: Breaking up with Python
#157Earlier quoted context omitted.
I'd like to see the receipts on your statement. Easy examples I use every day: ML and Quantum Computing libraries. There is a depth to the Python ecosystem that can't be matched anywhere else. Honestly, I'm sure I will get a ton of flack for this, but I really dislike Python. I use it every day and have for years and not only has it failed to grow on me (like most languages do), I've learned to dislike it more with e…
Those are really exceptions because researchers love Python. Outside of those areas, there's really nothing special that Python's ecosystem brings to the table. I'd really like to see machine learning stuff in languages other than Python so that there's less friction in experimenting. I know that would require prying it from researchers' cold dead hands though.
Those aren't exceptions, those are the norm. Yeah Go has really slick libraries to support your favorite protocol, but that's the easy part of programming. If I want to hack together something using computer vision, do some amature data science, or use cutting edge scripts written by security researchers, that's gonna be Python. Pretty much all code that I would wanna steal for my project is written in Python, or has Python bindings as its main way of using it.
Re: Breaking up with Python
#158Earlier quoted context omitted.
You are quite right it is not just compilation that sets Python apart from C++, that was a bit of a simplification on my part. There is also tools such as Cython and numba (JIT) which use various techniques to compile Python code btw. But I am generally in favour of switching to a high performance language or writing in C++ and then importing in Python at that point, personal preference again... Interesting to read a…
> You are quite right it is not just compilation that sets Python apart from C++, that was a bit of a simplification on my part. That's how I understood your post. Sorry if my post came off as a correction - it was not meant as such, but as a question (not specifically about Python or C++): How does a language benefit from not having the option to compile it? What restrictions does the requirement to be able to produ…
> How does a language benefit from not having the option to compile it? What restrictions does the requirement to be able to produce a machine-code executable place on it?
“Compiled” is being used as a short-hand for “compiled with optimisations”, so yes, an unoptimised build wouldn’t count here.
The design decision is around when (between the code being written and being run) is the final decision made about what exact code will run. If that is known really early (static types, no dynamic dispatch) then optimisations can be made early too. If it is really late (polymorphic methods, support for redefining types etc) then optimisation needs to run very quickly (“just in time”) or not at all.
If you want to go deeper on this, look at performance optimisation in Julia. It has the same LLVM backend as C/Rust, so can use all the same optimisations, but it is arguably a more dynamic and easier to use language than Python, so when and how optimisations apply really depends on how the code itself is written. As a bonus, it has some great tooling to see how changes to the code impact performance.
Re: Breaking up with Python
#159Earlier quoted context omitted.
> The type annotations never took off I don’t think that’s true; I think that type annotations have been seeing significant gains in usage in Python in recent years.
Have they? Genuinely asking. The recent code samples I did see on SO don’t yet include them and the one big Python project (Django) that I use hasn’t started making use of then just yet, or at least not to my knowledge.
IME they are increasingly used by application developers but a lot of libraries and even Python's own documentation have not really embraced them yet. That makes using them a lot harder - and sometimes less useful - than in comparable languages like TypeScript. Every client we've worked with recently who uses Python was at least trying to use type annotations but not necessarily with the same level of commitment or expected ROI.
Re: Breaking up with Python
#160Earlier quoted context omitted.
> 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 dependenc…
> write a production network backend without using any dependencies In this regard, I find it interesting that the following is currently on the HN front page: https://news.ycombinator.com/item?id=34179426 TL/DR: Go's network sockets set TCP_NODELAY by default, which is, the article argues, a very bad idea.
The article is wrong and doesn't even address the primary reason why git-lfs is slow in his case.