Live data from Hacker News

Breaking up with Python

cedwards.xyz

91–100 of 179 posts

Re: Breaking up with Python

#91
post #53

Earlier quoted context omitted.

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 ?

Yeah. And I don’t want confusing initialisers or constructors or whatchamacallit, and weird calls to super, and underscore methods. Maybe the language should just be minimally aware of classes and how they work, and build that into the semantics of the language using keywords, rather than giving me building blocks that make it feel like I’m rebuilding class semantics from scratch. It’s like when it comes to classes, Java is cleaner and simpler than python. Which is weird, cuz python is simpler and more fun to work with on all other fronts (well, almost, concurrency and threading is also kind of easier in Java).

…I really like python, but man it’s warts are annoying.

Re: Breaking up with Python

#92
post #18

> 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 conc…

yeah python is alright, it's not a masterpiece, but it's well rounded

I ported a golang (non concurrent) program that was 3 files and lots of intermediate procedures over custom types (synchronized maps)

it thing fit beautifully in a one page python script, very readable. bonus: concurrency (threadpool over queues). the only libs were click and rich but not relevant to the design

and the fact that it's repl-able you can quickly navigate in the stdlib.

ps: python docs are not amazing but they have a low signal/noise/confusion ratio. if one wants to suffer go "read" the javadoc, with it's empty package descriptions, extreme redudancy of autogenerated get/set * polymorphic methods. Or to stay in the python world, django docs. They're abysmally non technical.. it's full on guess fest to infer the relationships between classes and dataflow. Superb.

Re: Breaking up with Python

#93
If you chose JavaScript over Python for backend scripting, sounds like you want to hurt yourself.

If JavaScript is your goto language, then ok. But, otherwise, Python is the most used language for writing backend scripts, so it's pretty good at this, but also there's a lot of material online.

Re: Breaking up with Python

#94
post #91

Earlier quoted context omitted.

you want `self` less class methods ?

Yeah. And I don’t want confusing initialisers or constructors or whatchamacallit, and weird calls to super, and underscore methods. Maybe the language should just be minimally aware of classes and how they work, and build that into the semantics of the language using keywords, rather than giving me building blocks that make it feel like I’m rebuilding class semantics from scratch. It’s like when it comes to classes,…

When I first started using python (somewhere before the 2to3 migration) I was extremely pissed at the object layer.

I hate redundancy and the dunder and explicit self parameters completely stupid. With time I just got used to them .. (thanks partly to editor templates). The private field shenaningans weren't sexy either..

Other than that I agree.. it would be worth a python4

   class Foo(Bar):

      new(*a, **kw):
         "keyword: new"
         super(*a, **kw)
         print('v4')
      
      bar(a,b,adjust=1):
         "no self, shorthand super.parent_method()"
         return super.bar(a, b) + adjust
come on guido ;)

Re: Breaking up with Python

#95

Oh yeah, "every language has issues", or "if you just invest a little effort you'll get it", sure. But those languages that I use don't prevent me from installing a CLI tool and have me fighting with its half-witted package manager to do so. And they don't (or they very rarely do) mandate me to learn idiosyncrasies so I can do basic activities. The only thing that keeps Python alive and well is the fact that many peo…

The argument is that it can be … but isn’t. It hits a sweet spot. It isn’t your sweet spot, but it is for a lot of folks.

Re: Breaking up with Python

#96
post #18

> 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’…

> 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.

Does not being compiled really help with readability? How? After all, one can compile python to machine code, and there are C++ interpreters [1] (I have not heard any claims that using it makes C++ more readable). Then there are very readable/usable languages such as Haskell that come out of the box with both a compiler and interpreter.

To be more specific: which features does the absence of the possibility of compilation [2] enable?

[1] https://root.cern/cling/

[2] Since interpretation and compilation are not mutually-exclusive for a language.

Re: Breaking up with Python

#97

I've been recommending Python to the occasional aspirational young programmer. Is it already passé? What would you recommend instead for a starter language? Looking for beginner-friendliness, widespread use, and longevity. edit: to be clear, I hope this won't devolve into a language flamewar. I'm sincerely interested in other devs' opinions, and hoping that either Python is still a good recommendation (which seems to…

In my experience PowerShell fits well as a toe-dipping language. It allows to solve the menial tasks someone with no programmng experience usually needs to solve, can interact with HTTP/REST-like APIs, sometimes has the modules for a popular solutions, is object oriented, lax on the indentation *smirk*.

> In my experience PowerShell fits well as a toe-dipping language.

Ugh. Sorry, I've not really got anything constructive (destructive?) to say in support of that other than (a) in practical terms it isn't a transferrable skill beyond Windows, (b) the Naming-Conventions-OfThings is both awful and verbose, and (c) I've never had a use case where more than a handful (at most) of my fellow devs would be happy to work with it in the future.

YMMV and I appreciate this is very much a personal opinion.

Re: Breaking up with Python

#98
post #37

Last time I argued, like the TFA does, that Python's typing system is both too complex for casual users and useless for power users ("it doesn't do anything" is about right), and that this makes it hard to evangelize its use to other devs who aren't sold on type systems ("but this doesn't do anything!"), I got into a 30-level nesting flame war with some HN regular who just wouldn't let go . So that's still my line of…

Yeah, I think I agree with you. I still find it curious that the python language server is quite capable of inferring types from unannotated code yet most of the type checking tools for python seem to explode as soon as they encounter an very popular yet untyped library. I guess typing is more of an afterthought than a priority for most dynamic language developers so it doesn't get much love.

Re: Breaking up with Python

#99
post #18

> 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’…

I have always had a very good experience with python documentation.

While I generally do like the python documentation, I often find that it likes to explain exactly how and why a library works in detail. This is great if you want to really learn the library and often I miss this level of detail in for example JavaScript, but if you just quickly want to find the most obvious way to do the most common thing, it can be quite annoying.

Re: Breaking up with Python

#100
post #18

> 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’…

I, a python dev with a decade of experience sometimes still need half a day to figure out some weird dependency venv import-path issue. This happens often.

It takes me half a day to figure out a reliable way to cross compile rust binaries for Raspberry Pis, withput ever having done this before.

There are a lot of good things about python but the dev environment sucks a lot and it is so engrained in the very substance of the language/tooling that I don't really see a path out of that other than going all Python 4.0 on it and repeating the python2/python3 schism all over again.

Python is still my goto language but it is my goto language despite the tooling, not because of it.

Post reply on HN