4 ms·

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

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 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        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.
        jletts 6y ago
        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.
- deleted 6y ago
  [deleted]
asadjb 6y ago
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 6y ago
  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 6y ago
  here's my other comment that talks about this: https://news.ycombinator.com/item?id=23008968 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-objects-in-python 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-reference/records https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...) "elixir records" (https://hexdocs.pm/elixir/Record.html https://hexdocs.pm/elixir/Record.html) "clojure records" (https://clojuredocs.org/clojure.core/defrecord https://clojuredocs.org/clojure.core/defrecord) "racket lang records" (https://docs.racket-lang.org/rebellion/Records.html 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#nonlocal 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 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-programming-language/fulltext 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 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 https://fsharp.org/history/hopl-final/hopl-fsharp.pdf) a programmable programming language (https://cacm.acm.org/magazines/2018/3/225475-a-programmable-programming-language/fulltext https://cacm.acm.org/magazines/2018/3/225475-a-programmable-...)
WilliamEdward 6y ago
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.
- pjmlp 6y ago
  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.
- nikofeyn 6y ago
  > 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.
gumby 6y ago
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.

Y_Y 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.
      - jletts 6y ago
        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.
deleted 6y ago
[deleted]

asadjb 6y ago

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 6y ago
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 6y ago
here's my other comment that talks about this: https://news.ycombinator.com/item?id=23008968 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-objects-in-python 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-reference/records https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...) "elixir records" (https://hexdocs.pm/elixir/Record.html https://hexdocs.pm/elixir/Record.html) "clojure records" (https://clojuredocs.org/clojure.core/defrecord https://clojuredocs.org/clojure.core/defrecord) "racket lang records" (https://docs.racket-lang.org/rebellion/Records.html 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#nonlocal 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 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-programming-language/fulltext 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 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 https://fsharp.org/history/hopl-final/hopl-fsharp.pdf) a programmable programming language (https://cacm.acm.org/magazines/2018/3/225475-a-programmable-programming-language/fulltext https://cacm.acm.org/magazines/2018/3/225475-a-programmable-...)

WilliamEdward 6y ago

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.

pjmlp 6y ago
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.
nikofeyn 6y ago
> 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.

gumby 6y ago

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.