6 ms·

I appreciate and agree with the attitude/approach here. I suspect the author may be a bit removed from modern python, as the community is increasingly taking a

I appreciate and agree with the attitude/approach here. I suspect the author may be a bit removed from modern python, as the community is increasingly taking a similar stance. Python is not Haskell, but Python in 2021 with tools like type-hints, mypy, (frozen)dataclasses, Pydantic, etc. is trying to address at least the latter two points here (type-driven & illegal-states-unrepresentable). I'm not aware of ways to enforce function purity in python (do any linters complain about input modification or out-of-scope references?), but I try to make functions as pure as possible regardless of language or domain anyways. I don't mean this as a flamewar, Haskell seems like the right choice for OP. I love how a language like python is making more of these benefits available to a wider audience and I wish more folks embraced these recent advances.

named-user 5y ago
>tools like type-hints, mypy, (frozen)dataclasses, Pydantic, etc. is trying to address at least the latter two points here (type-driven & illegal-states-unrepresentable) At some point you have to admit to yourself that it's the wrong tool for the job, when is this going to be? Dependency/environment management is poor as well given how popular the language is. I believe it's popularity is similar to that of PHP in the past; flooded with carefree users. I would strongly advise against using python for anything other than PoC/experimental endeavours. It's a scripting language, and should be used as such.
- gmfawcett 5y ago
  I don't know. I like Haskell, but practically I would still choose a dynamic language "with benefits" over Haskell for BE development. [1] For example, Python frameworks like FastAPI can enforce type discipline at the system boundary, and frankly it feels like a development sweet-spot. Rigour at the API level, but fast-and-loose reasoning can proceed as normal in the implementation. It's a worse-is-better approach, to be sure, but it has a very appealing effort:result ratio. [1] with the normal caveats -- every project is different, everybody's notion of a "backend" is different, etc. Haskell might be the sanest solution to some backend challenges.
  - claytonjy 5y ago
    I agree and I really like that way of framing it; I want interfaces and contracts strong enough that I don't have to care about the implementation.
  - named-user 5y ago
    FastAPI is hard to contend with for anything marginally complex, without having to dig deep in its internals. If you want performance, or to apply more rigorous (read: enterprisey) development practices, you really are better off looking elsewhere. However, you can get a Data Science python developer to front their code behind an API with minimal ceremony. Type safety does not exist in Python. Type hinting does not solve this problem, neither does Pydantic. These are bandaids for huge shortcomings of using the wrong tool for the job.
    - gmfawcett 5y ago
      Sure, but there's a continuum at play here. Haskell leaves some correctness on the table, right? -- you should be using Idris 2; or better yet, proving your API in Coq and extracting the code. From some perspectives, Haskell is the "worse" in "worse is better". Personally I find python-is-wrong arguments to be a bit naive. "It's a crappy language that's only good enough to build prototypes..." -- like YouTube, for example? :) Ultimately, smart developers are smart, and can get work done with whatever tools they have at hand.
      - fiedzia 5y ago
        Take computer away from them and see how far they'll go. Tools matter. However the community and ecosystem behind Python makes it extremely hard to beat at many games.
        gmfawcett 5y ago
        LOL, I agree that YouTube would be hard to build if you only had a hammer and chisel. :P
    - 5y ago
- claytonjy 5y ago
  I work in data science and engineering, so not using python is not really an option. I'd love to use Julia and Rust instead, but the ecosystems and users aren't there yet. Python continues to earn its reputation as the second-best option for most problems.
  - named-user 5y ago
    I agree absolutely. It's always a matter of choosing the least worst solution with Python, and additionally patching over shortcomings of the language with afterthought-tooling.
  - CraigJPerry 5y ago
    >> Python continues to earn its reputation as the second-best option for most problems Never heard that line before but it resonates with me.
  - dunefox 5y ago
    > I'd love to use Julia and Rust instead, but the ecosystems and users aren't there yet. https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaInterop/RCall.jl https://github.com/JuliaInterop/RCall.jl
- Orou 5y ago
  > I would strongly advise against using python for anything other than PoC/experimental endeavours. I agree with your points, but this seems to lean a bit too far the other way. Yes, Python has plenty of limitations and cases where there are better choices in programming language. But saying that it shouldn't be used in real production systems when there are so many examples of it being used effectively for precisely that seems a bit hyperbolic, no? It's like saying Javascript shouldn't be used in production.
  - romero-jk 5y ago
    At least JS can be 50X faster than Python and it has TS.
  - ModernMech 5y ago
    > It's like saying Javascript shouldn't be used in production. I mean… is that such an unreasonable point of view?
toomanydoubts 5y ago
No matter how many type hints you put in your python code, haskell type system is on another level altogether. I honestly believe every developer should get to experience writing some haskell code at some point in their lifes to really understand what I'm talking about.
- DonaldPShimoda 5y ago
  A lot of people seem to think that type systems are either "you have it or you don't", when in actuality there are languages with type systems that can express significantly more intricate relationships among data than the common languages. The issue, of course, is that most common languages people use have a type system based on C's (with minor improvements). Those are all mostly interchangeable. But languages like Haskell and OCaml have the capabilities to directly express notions with types that Python, Java, or C would deeply struggle with. (All this is to say: I agree with your point that people would benefit from doing a bit of Haskell to experience this first-hand!)
  - Zababa 5y ago
    Another big difference is in performance. If your language doesn't support immutability, adding it in with a library (like in JS) will add a huge runtime cost, while you get that for free in Haskell/OCaml.
gen220 5y ago
> do any linters complain about input modification or out-of-scope references? I know Instagram was experimenting with something similar to this a couple years ago (“Python strict modules”). It might be possible to implement function purity with a decorator. (Kind of like declaring something “safe” in Rust). Definitely agree that Python is becoming more amenable to functional style programming over time. And it’s great!
- ianandrich 5y ago
  > It might be possible to implement function purity with a decorator. (Kind of like declaring something “safe” in Rust). Two parts to this. 1: Does it mutate variables. 2. Does the code have side effects. 1: def no_mut(func): @functools.wraps def new_func(args, *kwargs): new_args = tuple(copy.deepcopy(arg) for arg in args) new_kwargs = {k, copy.deepcopy(v) for k, v in *kwargs return func(new_args, *new_kwargs) return new_func For the second point, gevent seemed to have a trick to identify side effecting code.
8589934591 5y ago
Are there examples of moving from Python to Haskell? Would love to read and evaluate such options since I'm in dire need of moving away from Python to a typed language and Haskell seems like an interesting choice.
- LeonidasXIV 5y ago
  Not from Python to Haskell but Thomas Leonard[1] has a very nice series of blog posts about migrating 0install away from Python to OCaml, of which many points also apply to Haskell which he evaluated as a choice as well. [1]: https://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ https://roscidus.com/blog/blog/2013/06/09/choosing-a-python-...
- smichael 5y ago
  I moved from Python to Haskell, when I had had enough of debugging runtime failures. Excellent choice, go for it.
  - 8589934591 5y ago
    Can you please share codebases (if opensource) where you moved from Python to Haskell? It would help me understand how the porting was done and the design choices too.

named-user 5y ago

>tools like type-hints, mypy, (frozen)dataclasses, Pydantic, etc. is trying to address at least the latter two points here (type-driven & illegal-states-unrepresentable) At some point you have to admit to yourself that it's the wrong tool for the job, when is this going to be? Dependency/environment management is poor as well given how popular the language is. I believe it's popularity is similar to that of PHP in the past; flooded with carefree users. I would strongly advise against using python for anything other than PoC/experimental endeavours. It's a scripting language, and should be used as such.

gmfawcett 5y ago
I don't know. I like Haskell, but practically I would still choose a dynamic language "with benefits" over Haskell for BE development. [1] For example, Python frameworks like FastAPI can enforce type discipline at the system boundary, and frankly it feels like a development sweet-spot. Rigour at the API level, but fast-and-loose reasoning can proceed as normal in the implementation. It's a worse-is-better approach, to be sure, but it has a very appealing effort:result ratio. [1] with the normal caveats -- every project is different, everybody's notion of a "backend" is different, etc. Haskell might be the sanest solution to some backend challenges.
- claytonjy 5y ago
  I agree and I really like that way of framing it; I want interfaces and contracts strong enough that I don't have to care about the implementation.
- named-user 5y ago
  FastAPI is hard to contend with for anything marginally complex, without having to dig deep in its internals. If you want performance, or to apply more rigorous (read: enterprisey) development practices, you really are better off looking elsewhere. However, you can get a Data Science python developer to front their code behind an API with minimal ceremony. Type safety does not exist in Python. Type hinting does not solve this problem, neither does Pydantic. These are bandaids for huge shortcomings of using the wrong tool for the job.
  - gmfawcett 5y ago
    Sure, but there's a continuum at play here. Haskell leaves some correctness on the table, right? -- you should be using Idris 2; or better yet, proving your API in Coq and extracting the code. From some perspectives, Haskell is the "worse" in "worse is better". Personally I find python-is-wrong arguments to be a bit naive. "It's a crappy language that's only good enough to build prototypes..." -- like YouTube, for example? :) Ultimately, smart developers are smart, and can get work done with whatever tools they have at hand.
    - fiedzia 5y ago
      Take computer away from them and see how far they'll go. Tools matter. However the community and ecosystem behind Python makes it extremely hard to beat at many games.
      - gmfawcett 5y ago
        LOL, I agree that YouTube would be hard to build if you only had a hammer and chisel. :P
  - 5y ago
claytonjy 5y ago
I work in data science and engineering, so not using python is not really an option. I'd love to use Julia and Rust instead, but the ecosystems and users aren't there yet. Python continues to earn its reputation as the second-best option for most problems.
- named-user 5y ago
  I agree absolutely. It's always a matter of choosing the least worst solution with Python, and additionally patching over shortcomings of the language with afterthought-tooling.
- CraigJPerry 5y ago
  >> Python continues to earn its reputation as the second-best option for most problems Never heard that line before but it resonates with me.
- dunefox 5y ago
  > I'd love to use Julia and Rust instead, but the ecosystems and users aren't there yet. https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaInterop/RCall.jl https://github.com/JuliaInterop/RCall.jl
Orou 5y ago
> I would strongly advise against using python for anything other than PoC/experimental endeavours. I agree with your points, but this seems to lean a bit too far the other way. Yes, Python has plenty of limitations and cases where there are better choices in programming language. But saying that it shouldn't be used in real production systems when there are so many examples of it being used effectively for precisely that seems a bit hyperbolic, no? It's like saying Javascript shouldn't be used in production.
- romero-jk 5y ago
  At least JS can be 50X faster than Python and it has TS.
- ModernMech 5y ago
  > It's like saying Javascript shouldn't be used in production. I mean… is that such an unreasonable point of view?

toomanydoubts 5y ago

No matter how many type hints you put in your python code, haskell type system is on another level altogether. I honestly believe every developer should get to experience writing some haskell code at some point in their lifes to really understand what I'm talking about.

DonaldPShimoda 5y ago
A lot of people seem to think that type systems are either "you have it or you don't", when in actuality there are languages with type systems that can express significantly more intricate relationships among data than the common languages. The issue, of course, is that most common languages people use have a type system based on C's (with minor improvements). Those are all mostly interchangeable. But languages like Haskell and OCaml have the capabilities to directly express notions with types that Python, Java, or C would deeply struggle with. (All this is to say: I agree with your point that people would benefit from doing a bit of Haskell to experience this first-hand!)
- Zababa 5y ago
  Another big difference is in performance. If your language doesn't support immutability, adding it in with a library (like in JS) will add a huge runtime cost, while you get that for free in Haskell/OCaml.

gen220 5y ago

> do any linters complain about input modification or out-of-scope references? I know Instagram was experimenting with something similar to this a couple years ago (“Python strict modules”). It might be possible to implement function purity with a decorator. (Kind of like declaring something “safe” in Rust). Definitely agree that Python is becoming more amenable to functional style programming over time. And it’s great!

ianandrich 5y ago
> It might be possible to implement function purity with a decorator. (Kind of like declaring something “safe” in Rust). Two parts to this. 1: Does it mutate variables. 2. Does the code have side effects. 1: def no_mut(func): @functools.wraps def new_func(args, *kwargs): new_args = tuple(copy.deepcopy(arg) for arg in args) new_kwargs = {k, copy.deepcopy(v) for k, v in *kwargs return func(new_args, *new_kwargs) return new_func For the second point, gevent seemed to have a trick to identify side effecting code.

8589934591 5y ago

Are there examples of moving from Python to Haskell? Would love to read and evaluate such options since I'm in dire need of moving away from Python to a typed language and Haskell seems like an interesting choice.

LeonidasXIV 5y ago
Not from Python to Haskell but Thomas Leonard[1] has a very nice series of blog posts about migrating 0install away from Python to OCaml, of which many points also apply to Haskell which he evaluated as a choice as well. [1]: https://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ https://roscidus.com/blog/blog/2013/06/09/choosing-a-python-...
smichael 5y ago
I moved from Python to Haskell, when I had had enough of debugging runtime failures. Excellent choice, go for it.
- 8589934591 5y ago
  Can you please share codebases (if opensource) where you moved from Python to Haskell? It would help me understand how the porting was done and the design choices too.