[nikofeyn]

in the software world, one can avoid the monster that is c++ rather successfully, but it's gotten to the point that no matter what, python is thrust upon you to deal with. "hey here's this thing that is barely working" (in large part because it's written in python) "and we'd like you to maintain it but not switch from python" (because anything besides python makes us uncomfortable). meanwhile, python makes me uncomfortable and is such an unprincipled language, it feels like it fights you every step of the way to write error-free code.

[Y_Y]

I have my misgivings about Python and C++ too, but when writing them for my job I think how much worse things could be. I could have a job that didn't involve coding, or no job, or even something involving Java.

[nikofeyn]

i personally can't get past it. i've hated every second of developing in python in my jobs, and i just sit there wondering how nice it would be if i could move off of it, especially when debugging and finding yet another inane design decision in python or something that doesn't work. there's never been a reason to use it other than that's what someone unfamiliar with better choices chose for the project, and there's typically a very objective multiplier in risk and time in the development by sticking with python. moving to clojure, racket, f#, elixir, etc. would almost always be a better choice aside from certain uses of python-specific libraries (like for machine learning).

[randomsearch]

The vast ecosystem of python libraries is an incredibly powerful argument for using it. One major library could dramatically cut the development time of your project.

You’ve not spelt out actual reasons why Python is so bad, could you give your top three?

[billfruit]

One thing I have felt is that python doesn't embrace the functional way of thinking, even to the extent that JavaScript does. I personally find that once I have been exposed to a modern functional approach like in Clojure, etc, I find python lacking. Not just syntactically, but conceptually. For example, IIRC, many list methods in python modify the list they are working on, instead of returning a new list.

[jakear]

In line with this, list comprehensions are one area of python I find particularly clunky. They work fairly well for a single map or filter operation, alright for both mapping and filtering, and are absolutely unreadable for anything more complicated. A big part of this in my opinion is how they scramble the flow. Instead of taking a piece of data and performing successive operations on it, both in logic and in syntax, you have their 'literate' mess that requires you to start reading in the middle of the line and alternate moving your cursor back and forth.

Consider:

getNumbers() .map(x => x×2) .filter(x => x % 6 == 0) .map(x => x^2)

get numbers. double them. filter for divisibility by 6. square them.

versus

[x^2 for x in x×2 for x in getNumbers() if x % 6 == 0]

get the square of the doubles version of getNumbers values, but only if those doubles are dividable by 6. But wait are the doubles dividable by 6 or the squares?

Maybe some people are fine with looking at what operations are being performed on the data before even knowing what the data itself is, but that for me seems incredibly backwards. Plus it also gives rise to order of operations ambiguities. Nobody could mistake the ordering in JS, but I honestly have no clue how that python would evaluate.

(using carats because hn cant format code)

Edit- This came to mind because of a flattening list comprehension I encountered earlier today:

#flatten the lists

flattened_list = [y for x in list_of_lists for y in x]

I've spent quite some time staring at this and I still have no clue what it's actually doing. I've never had that with JS operator chains.

[pansa2]

Python’s list comprehension syntax is based on the set-builder notation from mathematics. However, I think it would have been better to break with tradition and use a different order, one which matches the order of the equivalent nested loops:

    flattened_list = [for x in list_of_lists: for y in x: y]

This is essentially the same re-arrangement that was made in C#‘s LINQ: it uses from-where-select instead of SQL’s select-from-where.

[jletts]

map(lambda x:x^2, filter(lambda x:x%6==0, map(lambda x: x*2, getNumbers())))

Would probably be a more pythonic way to do that, avoiding list comprehensions. Easier to read with added lines and indentation.

But tbf I do appreciate the ability to chain operations in JS without subclassing objects like list.

[heyoni]

Quick example off the top of my head is the built-in sorted function. That returns a new list if I'm not mistaken.

[billfruit]

What I had in mind was the append function, it modifies the list instead of creating a new list.

[nikofeyn]

> The vast ecosystem of python libraries is an incredibly powerful argument for using it.

vast ecosystems exist in other languages as well. python is not magically the only language that has libraries. in my experience, python libraries exist but aren't great and lead to issues. also in my experience, .net libraries often exist alongside the python libraries, and in many cases companies often provide C/C++ DLLs or .NET assemblies more often than Python APIs.

> One major library could dramatically cut the development time of your project.

in my experience, the half-baked nature of python libraries actually increased development time.

> You’ve not spelt out actual reasons why Python is so bad, could you give your top three?

thanks for asking this rather than indiscriminately downvoting. my reasons are:

* the module system is a mess and can hardly be called a system. anything greater than a few scripts and modules becomes a mess, whereas other languages have much better module and project systems (the latter of which python doesn't even have). the module system in python is little more than a hack just barely exceeding file path linking.

* pip is a mess.

* the python 2 vs 3 issue is trivialized by people, but it is anything but trivial in practice. the first python codebase i worked against was using an internal tool at a large company. they were actually using python 2.6, and it was me, a new user, who pushed them to use 2.7 (which didn't happen before i left). the next system i worked on was also using 2.6 at another company, and i upgraded them to 2.7. the installation procedure for the python packages was a mess (see the module system and pip being a mess). upgrading them to python 3 was a non-starter and on further projects, they ignored my suggestions to them (i wasn't working on the system) to upgrade to python 3 because they didn't see the reason to. next system was also in python 2.7, and due to package obsolescence and deprecation and version jumps, the entire codebase basically required being rewritten in python 3 and newer packages.

* the ecosystem isn't as complete or robust as people imply. even python's built-in XML parsing library has many issues and lack of features, and i have even seen differing behavior between linux and windows.

* python the language is most simply described as unprincipled. there are surprises and gotchas everywhere. for example, the following generates a run-time error:

  def now():
    return "now"

  def usage():
    now = now()
    return now + "!"

the error is "UnboundLocalError: local variable 'now' referenced before assignment". now do the same in f# or racket or any other sane language in which expressions return values which are then bound sanely to identifiers. python is full of stuff like this. if you've used more sanely defined languages, coming to python is actually quite complicated because it is so unprincipled. it does not have a small core base layer that allows for predictable code.

* python has no consistent way to write asynchronous or concurrent code and has major limitations on whether the code you write is actually concurrent. i've done a lot of concurrent code. when i learned elixir/erlang, it was so easy to understand (many python people probably consider elixir/erlang to be more complicated than python), but when i tried to learn asyncio in python, it felt very complicated. there are tons of caveats right off the bat, and it is completely different than other ways of writing concurrent programs in python.

[asadjb]

As a Python programmer, it would be interesting to hear why you thing Python in unprincipled? I haven't felt that myself so curious to see what your thoughts are.

[greenshackle2]

Not the person you replied to, I don't hate Python, it's not my favorite but it's my most used language.

Python is unprincipled in its design. It's a kitchen sink language. It has principles (PEP 20) but they explicitly eschew purity of design in favor of practicality, readability, and simplicity of implementation.

Python's type system is very flexible. You may see that as a plus, to me it feels all over the place. It has classes which you can turn into half-baked nominal typing with type annotations. You can mix-and-match interface inheritance and implementation inheritance with multiple inheritance.

You can do unholy things to the class system with metaclasses and the issubclass hook. I have seen it, in a half-million LOC project.

It has protocols, which are duck typing, which you can turn into half-baked structural typing with type annotations.

It is multi-paradigm and it's acceptable at all but not the best at any. If you want strictly OOP or functional you're better served elsewhere.

You can mix-and-match type systems and paradigms in a single codebase, which can be useful, but it's up to dev discipline to not turn the codebase into a horrible mishmash.

In comparison, I don't like writing Java, but I have to admit it limits the amount of damage undisciplined devs can do to a project.

[nikofeyn]

here's my other comment that talks about this: https://news.ycombinator.com/item?id=23008968

even among dynamically typed languages, python is terrible. it has no real way to build up new types in a principled way, and you have to result to using (and abusing) the class system, which is hack after hack.

python also ignored and continued to ignore things that already existed in languages and advances. it also doesn't really like using data-type driven development. go ahead and search for "python records". you'll get nothing, and the best reference is a blog post (https://dbader.org/blog/records-structs-and-data-transfer-ob...) that leads you to a wide variety of solutions, all inconsistent with each other and not conventionally used. now search google and literally the top result for each query is the following:

"f# records" (https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...)

"elixir records" (https://hexdocs.pm/elixir/Record.html)

"clojure records" (https://clojuredocs.org/clojure.core/defrecord)

"racket lang records" (https://docs.racket-lang.org/rebellion/Records.html)

another area that python doesn't take seriously is scoping. the scoping rules and exceptions are complex, and this makes the language very dangerous. i mentioned one in the other comment i linked. python has weird scoping stuff with lambdas. python even has a keyword that makes a locally bound variable available in the calling scope (https://docs.python.org/3/reference/simple_stmts.html#nonloc...). no thank you. this is absolutely terrible design, and yes, i have seen it in production code (not written by me). just search "python scoping" or "python nonlocal", and you'll come across people confused by a plethora of edge cases.

python is just complicated. it has no simple core. it is a huge lump of stuff. both f# and racket are definitely more complicated than python in that they have behavior and features far exceeding python. however, they are principled. in one way, they have very simple core languages such that if you ignore all the fancy stuff, you can still write beautiful, reliable code with the simply designed core language. as you move to the more complicated stuff, you utilized this simple core over and over to build software that is still understandable. it allows you to build predictable software.

another area of principles i look for in a language are why it was created and what are the motivations of its creator(s). f# was created to bring a functional language to .net to utilize .net's vast functionality and test .net's language making and support capability. the development originally started with haskell but transitioned to ocaml since the model matched better with .net. don syme is a very practical language designer and an actual computer scientist. here is a draft of a paper by him about the history of f# (https://fsharp.org/history/hopl-final/hopl-fsharp.pdf). it's a useful read. racket was created to extend scheme into a new language that fully adopted language-oriented programming (lop) and had supporting libraries for normal development. this means taking an extremely principled language and extending it to support a new paradigm of software development in a principled, controlled way. see the paper a programmable programming language (https://cacm.acm.org/magazines/2018/3/225475-a-programmable-...). the authors of racket are also computer scientists and care about robust software development. python was created by someone interested in esoteric languages (ABC) and in creating a systems scripting language as a hobby project. the creator resisted and continued to resist many already existing language designs and features (found in scheme and ML-dialects such as SML). for example, lambda, map, filter, and reduce only exist in python because he begrudgingly accepted patches that someone else did. another example of unprincipled-ness is the creator's seemingly proud declaration to use multi-line string literals as multi-line comments since python did not have and still does not have multi-line comment support (https://twitter.com/gvanrossum/status/112670605505077248).

these things alone make me wholly not interested in python. i want to use a language that was created for a reason and in a principled way that solves a problem that i am facing. i also feel i need to agree with the reasons and also the philosophy of the language designers. none of this exists for me in python.

the early history of f# (https://fsharp.org/history/hopl-final/hopl-fsharp.pdf)

a programmable programming language (https://cacm.acm.org/magazines/2018/3/225475-a-programmable-...)

[WilliamEdward]

I see we've reached the point in python's popularity where it is cool to hate it. Happened with C++, Java, Javascript, PHP, and now... Python, of all things. Maybe the least bad of all of those. Like it or not it's here to stay.

If Scheme (or whatever language you use) was as popular as python you would think it is bad too since most code out there would be made by amateurs, and its flaws (which all languages have) would be unavoidable.

[nikofeyn]

> I see we've reached the point in python's popularity where it is cool to hate it. Happened with C++, Java, Javascript, PHP, and now... Python, of all things. Maybe the least bad of all of those.

first of all, this is a non-argument and has nothing to do with what i said. i don't hate python because it's cool. i hate python because i am concerned with building robust and reliable software and python makes that difficult. period. i am wholly unconcerned with what's cool or not and am concerned with developing software that can be relied on, maintained, and extended to help save money, save lives, save time, and makes the technology get out of the way.

those languages you listed are not a useful comparison. they're also terrible.

> Like it or not it's here to stay.

maybe true, but it doesn't mean i should just sit back and accept writing bad code.

> If Scheme (or whatever language you use) was as popular as python you would think it is bad too since most code out there would be made by amateurs, and its flaws (which all languages have) would be unavoidable.

it is true that bad code is bad code, and code written by people who don't take it seriously will not be magically good no matter what language they use. however, some languages make it easier if you do take it seriously. i take it seriously and python fights me.

[pjmlp]

There is only one thing I dislike about Python, not having JIT support of the box, or in another words PyPy doesn't seem to get the love it deserves.

However after watching several GTC 2020 talks, it seems that at least in what concerns GPGPU programming there are several efforts going on alongside CUDA integration.

[gumby]

Since I need performance, multithreading etc my code is in C++ and has a Python interface.

The languages and their power are so different that in the end it wasn't worth trying to use any of the quasi-automated linkage tools and instead the Python interface is built by hand. NumPy and such had to take this tack as well.