3 ms·

No, I'd rather it stayed close to its original design in that regard. I sometimes feel like the success of Python has attracted fans of features available in ot

No, I'd rather it stayed close to its original design in that regard. I sometimes feel like the success of Python has attracted fans of features available in other, less popular programming languages. Those people want to turn Python into their favourite language. I am not a fan of those attempts. Python is a forgiving and malleable programming language, but I sometimes want to quit when I open the repo at a new client only to find code written by someone who was told that functional programming and GraphQL are the future only to get bored halfway through the exercise of writing the app. You literally have to torch the code and start from scratch in those cases. To those who want to turn Python into Golang/Rust/Haskell/Java ... guys, other programming languages are available.

Narhem 2y ago
If it’s a small application starting as functional application makes a lot of sense, it’s like putting rebar before pouring concrete. Even if you start from scratch again you know someone has already started working with the previous structure. Meaning that work was not wasted. Anything to avoid the over complexity associated with delivering content with nodejs it’s like you missed out on building your computational foundation.
- surfingdino 2y ago
  There is a problem and it is not connected to any particular language. The majority of courses, reference material, and existing code is not built around functional programming paradigms.
  - Narhem 2y ago
    Agreed to disagree
pjmlp 2y ago
As someone that has used Python on and off since Python 1.6, mostly for UNIX scripting stuff, if Python is imposed on me as big boys programming language, I at very least expect the same tooling experience as Common Lisp, Smalltalk, Scheme, SELF, JavaScript, in performance, and not having PyPy feeling like an outsider on its little corner.
- surfingdino 2y ago
  I understand the sentiment. I don't think Python can satisfy one group of devs without loosing another, so the best way forward would be to stay true to itself while allowing those groups to adapt it to their expectations. I too have my own little wishes like having an option to turn off GIL much earlier. Python has become such a popular language that it's now harder to steer that ecosystem in one direction or the other.
RandomThoughts3 2y ago
I think it’s a bit disingenuous to put it that way. The comment you are replying to is not asking for a widely different programming style. They want typing which is perfectly understandable. It’s common that as project grows larger and more unwieldy, people ask for more warranty and help from their tooling. I think Python position on this strikes a good balance - provide the infrastructure for adding type hint but delegates type checking to a third party.
- surfingdino 2y ago
  Python uses dynamic typing by design. Removing it would remove one of it strengths (and weaknesses as some insist). It is one of the things that made Python so successful. We have learned over time that adding mypy to the pre-commit hooks is a good thing, but I think that's where we should stop. Give devs an option, but don't force it upon them.
  - deleted 2y ago
    [deleted]
  - robertlagrant 2y ago
    I think you could also argue for some sort of setting that adds additional optimisations based on type hints, but it would have to default to off.

Narhem 2y ago

If it’s a small application starting as functional application makes a lot of sense, it’s like putting rebar before pouring concrete. Even if you start from scratch again you know someone has already started working with the previous structure. Meaning that work was not wasted. Anything to avoid the over complexity associated with delivering content with nodejs it’s like you missed out on building your computational foundation.

surfingdino 2y ago
There is a problem and it is not connected to any particular language. The majority of courses, reference material, and existing code is not built around functional programming paradigms.
- Narhem 2y ago
  Agreed to disagree

pjmlp 2y ago

As someone that has used Python on and off since Python 1.6, mostly for UNIX scripting stuff, if Python is imposed on me as big boys programming language, I at very least expect the same tooling experience as Common Lisp, Smalltalk, Scheme, SELF, JavaScript, in performance, and not having PyPy feeling like an outsider on its little corner.

surfingdino 2y ago
I understand the sentiment. I don't think Python can satisfy one group of devs without loosing another, so the best way forward would be to stay true to itself while allowing those groups to adapt it to their expectations. I too have my own little wishes like having an option to turn off GIL much earlier. Python has become such a popular language that it's now harder to steer that ecosystem in one direction or the other.

RandomThoughts3 2y ago

I think it’s a bit disingenuous to put it that way. The comment you are replying to is not asking for a widely different programming style. They want typing which is perfectly understandable. It’s common that as project grows larger and more unwieldy, people ask for more warranty and help from their tooling. I think Python position on this strikes a good balance - provide the infrastructure for adding type hint but delegates type checking to a third party.

surfingdino 2y ago
Python uses dynamic typing by design. Removing it would remove one of it strengths (and weaknesses as some insist). It is one of the things that made Python so successful. We have learned over time that adding mypy to the pre-commit hooks is a good thing, but I think that's where we should stop. Give devs an option, but don't force it upon them.
- deleted 2y ago
  [deleted]
- robertlagrant 2y ago
  I think you could also argue for some sort of setting that adds additional optimisations based on type hints, but it would have to default to off.