5 ms·

> Python ... is not strict enough to be a good static language Yes, but Python was never meant to be a static language. The static type annotation feature was

> Python ... is not strict enough to be a good static language Yes, but Python was never meant to be a static language. The static type annotation feature was borrowed from static languages to reduce bugs, not to make Python a static language. > Python ... not powerful enough to be a good dynamic language. I strongly disagree with this. Python is a very powerful dynamic language. It lets you code with any paradigm that suits the problem you’re trying to solve. Functional, OOP, procedural, or whatever. CPython has hidden features that allow for low level customization of how it works (when it is appropriate). > Sadly, the most popular dynamic languages today are Python and JS and PHP There is a big difference between Python and those other languages. JavaScript and PHP became popular because they had to be used to write frontend code and backend code respectively for websites on affordable web hosts. Python became popular because programmers chose to use it; because it’s really good. Perhaps you think Lisp is better; that’s fine, but notion that Python is not good or not powerful is just wrong.

verttii 7y ago
As someone mostly writing functional languages I'm always having a hard time writing decent functional code in Python. There's almost no facilities to support modern functional programming so it just doesn't feel idiomatic in Python.
- y4mi 7y ago
  And unanimous functions are basically non-existent. Yes, lambda works but only allows a single line, which forces you to name the function anyway.
  - zo1 7y ago
    I find that a good thing rather than as a shortcoming. JS/TS looks horrendous with the amount of function nesting. Luckily, it looks like futures and await are resolving some of that mess. In my mind, the following is better than the JS equivalent using closures: response = await AsyncHTTPClient().fetch("http://www.google.com") self.result = json.loads(response.payload) You see exactly what is going on, no additional nesting, and no need for semi-inner state that potentially complicates state reasoning. I.e. people get tempted to put code afterwards thinking it'll run after the previous line. I may get some flack for this or my language, but I have absolutely no idea why anyone bothers so much with the closure garbage outside of select places where they make sense. It's non-intuitive and looks bad. Heck, I have a bad enough time explaining to seasoned devs the difference between threads and async concepts. Then you throw that sort of stuff at a junior JS dev and chaos will most certainly ensure with a buggy FE where no one can reason about state and there are null checks all over the place, just because. I've seen it in static FE languages like C#, too. State becomes too difficult to reason about, so null-checks are required everywhere. Edit. Formatting.
- BiteCode_dev 7y ago
  The functional paradigm is a matter of taste. Python is willingly limited in its functional capabilities. You may not like it, but it's not an error, it's a design decision.
  - garethrowlands 7y ago
    It's perfectly possible to be both a design decision and an error. False dichotomy, as they say :-)
    - BiteCode_dev 7y ago
      Again, a programming paradigm is like code formatting rules or ide choice. It's a matter of taste. Saying one is an error is just reenacting vim vs emacs. It goes nowhere.
  - Eugeleo 7y ago
    I think it wasn’t the OP’s point to question the design process behind Python — he was mostly just reacting to the commenter above who claimed that: > Python is a very powerful dynamic language. It lets you code with any paradigm that suits the problem you’re trying to solve. Functional, OOP, procedural, or whatever. Which simply isn’t true (as is proven by you as well) — Python was never designed to “let you code with any paradigm that suits the problem”. It has severely limited functional and (nonexistent?) metaprogramming capabilities, so the claim might be better phrased as follows: > Python is a very powerful dynamic language. It lets you code with any paradigm that suits the problem you’re trying to solve, as long as it’s OOP. (Please excuse the sarcasm: I work with Python and I like it for its simplicity, good tooling and a myriad of other things, but “flexibility”, for a lack of a better word — especially compared with LISP — is not one of them.)
- danenania 7y ago
  Agreed. Javascript certainly has more sharp edges, but if you stick to the good parts (or better, use Typescript) and throw in an fp library like Ramda, it's a lot more nimble for working with complex data structures than Python imho. And leveraging concurrency is of course much easier in Node-land too, especially since async/await have become standard fare. That said, Python has some great features (list comprehensions are awesome) and tons of great libraries, so it's still a solid choice for many use cases in spite of its data-wrangling limitations.
- goatinaboat 7y ago
  This is by design; GvR was opposed to functional programming. Example: https://www.artima.com/weblogs/viewpost.jsp?thread=98196 https://www.artima.com/weblogs/viewpost.jsp?thread=98196

verttii 7y ago

As someone mostly writing functional languages I'm always having a hard time writing decent functional code in Python. There's almost no facilities to support modern functional programming so it just doesn't feel idiomatic in Python.

y4mi 7y ago
And unanimous functions are basically non-existent. Yes, lambda works but only allows a single line, which forces you to name the function anyway.
- zo1 7y ago
  I find that a good thing rather than as a shortcoming. JS/TS looks horrendous with the amount of function nesting. Luckily, it looks like futures and await are resolving some of that mess. In my mind, the following is better than the JS equivalent using closures: response = await AsyncHTTPClient().fetch("http://www.google.com") self.result = json.loads(response.payload) You see exactly what is going on, no additional nesting, and no need for semi-inner state that potentially complicates state reasoning. I.e. people get tempted to put code afterwards thinking it'll run after the previous line. I may get some flack for this or my language, but I have absolutely no idea why anyone bothers so much with the closure garbage outside of select places where they make sense. It's non-intuitive and looks bad. Heck, I have a bad enough time explaining to seasoned devs the difference between threads and async concepts. Then you throw that sort of stuff at a junior JS dev and chaos will most certainly ensure with a buggy FE where no one can reason about state and there are null checks all over the place, just because. I've seen it in static FE languages like C#, too. State becomes too difficult to reason about, so null-checks are required everywhere. Edit. Formatting.
BiteCode_dev 7y ago
The functional paradigm is a matter of taste. Python is willingly limited in its functional capabilities. You may not like it, but it's not an error, it's a design decision.
- garethrowlands 7y ago
  It's perfectly possible to be both a design decision and an error. False dichotomy, as they say :-)
  - BiteCode_dev 7y ago
    Again, a programming paradigm is like code formatting rules or ide choice. It's a matter of taste. Saying one is an error is just reenacting vim vs emacs. It goes nowhere.
- Eugeleo 7y ago
  I think it wasn’t the OP’s point to question the design process behind Python — he was mostly just reacting to the commenter above who claimed that: > Python is a very powerful dynamic language. It lets you code with any paradigm that suits the problem you’re trying to solve. Functional, OOP, procedural, or whatever. Which simply isn’t true (as is proven by you as well) — Python was never designed to “let you code with any paradigm that suits the problem”. It has severely limited functional and (nonexistent?) metaprogramming capabilities, so the claim might be better phrased as follows: > Python is a very powerful dynamic language. It lets you code with any paradigm that suits the problem you’re trying to solve, as long as it’s OOP. (Please excuse the sarcasm: I work with Python and I like it for its simplicity, good tooling and a myriad of other things, but “flexibility”, for a lack of a better word — especially compared with LISP — is not one of them.)
danenania 7y ago
Agreed. Javascript certainly has more sharp edges, but if you stick to the good parts (or better, use Typescript) and throw in an fp library like Ramda, it's a lot more nimble for working with complex data structures than Python imho. And leveraging concurrency is of course much easier in Node-land too, especially since async/await have become standard fare. That said, Python has some great features (list comprehensions are awesome) and tons of great libraries, so it's still a solid choice for many use cases in spite of its data-wrangling limitations.
goatinaboat 7y ago
This is by design; GvR was opposed to functional programming. Example: https://www.artima.com/weblogs/viewpost.jsp?thread=98196 https://www.artima.com/weblogs/viewpost.jsp?thread=98196