5 ms·

>Python is anything but easy There's plenty of shade you can throw at the good old snake, be it package management, performance / speed, formatting peculiarity

>Python is anything but easy There's plenty of shade you can throw at the good old snake, be it package management, performance / speed, formatting peculiarity but this one is the most unlikely I can think of. What does it make it not easy in your mind?

youerbt 7y ago
I think "easy" is the biggest bait in the industry. Python is a language where, by default, a typo is a potential runtime error. That's far from easy in my book.
- mlthoughts2018 7y ago
  Ever mistyped an output file name in Haskell? This is one of those myths about static typing that really gets under my skin. I worked in a large, hardcore Haskell production environment for several years. There was no difference in the amount “silly typo breaks something later at runtime” types of mistakes, none, between that and the decade or so of production Python experience I have. These bugs enter your system and manifest in such weird ways that it always will be the job of unit and integration testing, not static typing, to catch them. Not with modeling states in the type system. Not with phantom types. Just nope. Frankly to me this is what distinguishes a senior engineer from junior engineers in statically typed languages. Do they understand the language design faculties don’t actually protect them, abandon the misguided idea of encoding protection into the language’s special faculties, and instead put that effort towards making the testing infrastructure easy to understand and update and very fast to run.
  - tome 7y ago
    > There was no difference in the amount “silly typo breaks something later at runtime” types of mistakes, none, between that and the decade or so of production Python experience I have. This is fascinating. You are basically the only person I know who has used Haskell extensively who claims this. Have you considered writing up your experience as a blog post (or even more formally as a technical report)? I think it would be extremely helpful to the programming community and particularly the Haskell sub-community for you to share your point of view.
    - mlthoughts2018 7y ago
      Briefly, there is something very similar to Amdahl’s Law for parallel speedup but for removing the thin layer of defects checkable by static typing. Most defects in any real system aren’t like that, to such a degree that the whole correctness bottleneck is concentrated so heavily in unit and integration testing and the extra language complexity, extra lines of code for type annotation or registry of type system designs, slow compile times or constraints on mutation imposed by the static typing don’t pay for themselves through meaningful defect reduction. It’s like the cost of shipping data to a GPU. The efficiency gained by processing it in parallel on the GPU device must be much greater than the transport cost, or it’s not worth it. But in terms of me ever wanting to write this up with rigorous technical examples, I mean, just look at the level of discourse and tribal downvoting in a thread like this. Even setting aside that this experience was spread across a quantitative trading company and in a large public financial technology company, meaning I definitely can’t publicly share a lot of details of those systems (which adds tons of required effort to convert examples into totally isolated tutorial-like standalone samples), why would anyone with a valuable technical dissenting opinion about Haskell want to open themselves up to that kind of religious backlash? It’s demoralizing and discouraging for me even just in a thread like this one, where I’m just some mostly anonymous commenter talking subjectively about my experience in small comments. There’s no way I’m sticking my neck out on a big technical blog post or technical paper about why leveraging a static type system doesn’t meaningfully reduce defects in real systems. Also to be clear, I think static typing is fine. Some people enjoy it a lot or have clever ideas about using it for expressiveness. Some people also write amazingly concise dynamically typed code that covers a huge variety of use cases in a safe way with pretty much no overhead code to register anything at all about those use cases. People are free to choose their tools and whatever gets a job done is totally fine. The part I find disingenuous is that it seems like only the static typing zealots are trying to come up with a reason to think a certain way of doing things strictly dominates or supersedes a different way of doing things, and it’s totally disingenuous to act like the benefits of static typing on defect rates would be such an argument for “universal” applicability of one certain paradigm.
      - tome 7y ago
        That's a shame. There are numerous voices clamouring "Haskell's too much effort for its benefits to be worth it". You are basically the only voice saying "Its benefits aren't even benefits". It feels like you could really add something beneficial. If only there were some middle ground between carefully considered and reasoned critique and vague and unsubstantiated sniping on message boards, but so be it.
  - youerbt 7y ago
    Well, I'm just pointing out that "easy" is not something that can be attributed to a programming language based on cute, pseudo-code like samples online. You don't see "Python is easy" examples with full test suite attached to them, explaining that, well, you are in for a ride without those. As for your comment: I can believe that production breaking typos may have been at a similar level. I don't believe that the effort to reach that level was the same, though.
  - crdoconnor 7y ago
    I've not worked on Haskell but while reading about it I've always been suspicious that its type system is actually effective at preventing integration bugs. It's nice to hear this echoed. I'd love to read more about this experience (good and the bad).
pjmlp 7y ago
Python allows for very creative programming, just because every feature looks easy in isolation, when used together they can open the door to some head scratching.

youerbt 7y ago

I think "easy" is the biggest bait in the industry. Python is a language where, by default, a typo is a potential runtime error. That's far from easy in my book.

mlthoughts2018 7y ago
Ever mistyped an output file name in Haskell? This is one of those myths about static typing that really gets under my skin. I worked in a large, hardcore Haskell production environment for several years. There was no difference in the amount “silly typo breaks something later at runtime” types of mistakes, none, between that and the decade or so of production Python experience I have. These bugs enter your system and manifest in such weird ways that it always will be the job of unit and integration testing, not static typing, to catch them. Not with modeling states in the type system. Not with phantom types. Just nope. Frankly to me this is what distinguishes a senior engineer from junior engineers in statically typed languages. Do they understand the language design faculties don’t actually protect them, abandon the misguided idea of encoding protection into the language’s special faculties, and instead put that effort towards making the testing infrastructure easy to understand and update and very fast to run.
- tome 7y ago
  > There was no difference in the amount “silly typo breaks something later at runtime” types of mistakes, none, between that and the decade or so of production Python experience I have. This is fascinating. You are basically the only person I know who has used Haskell extensively who claims this. Have you considered writing up your experience as a blog post (or even more formally as a technical report)? I think it would be extremely helpful to the programming community and particularly the Haskell sub-community for you to share your point of view.
  - mlthoughts2018 7y ago
    Briefly, there is something very similar to Amdahl’s Law for parallel speedup but for removing the thin layer of defects checkable by static typing. Most defects in any real system aren’t like that, to such a degree that the whole correctness bottleneck is concentrated so heavily in unit and integration testing and the extra language complexity, extra lines of code for type annotation or registry of type system designs, slow compile times or constraints on mutation imposed by the static typing don’t pay for themselves through meaningful defect reduction. It’s like the cost of shipping data to a GPU. The efficiency gained by processing it in parallel on the GPU device must be much greater than the transport cost, or it’s not worth it. But in terms of me ever wanting to write this up with rigorous technical examples, I mean, just look at the level of discourse and tribal downvoting in a thread like this. Even setting aside that this experience was spread across a quantitative trading company and in a large public financial technology company, meaning I definitely can’t publicly share a lot of details of those systems (which adds tons of required effort to convert examples into totally isolated tutorial-like standalone samples), why would anyone with a valuable technical dissenting opinion about Haskell want to open themselves up to that kind of religious backlash? It’s demoralizing and discouraging for me even just in a thread like this one, where I’m just some mostly anonymous commenter talking subjectively about my experience in small comments. There’s no way I’m sticking my neck out on a big technical blog post or technical paper about why leveraging a static type system doesn’t meaningfully reduce defects in real systems. Also to be clear, I think static typing is fine. Some people enjoy it a lot or have clever ideas about using it for expressiveness. Some people also write amazingly concise dynamically typed code that covers a huge variety of use cases in a safe way with pretty much no overhead code to register anything at all about those use cases. People are free to choose their tools and whatever gets a job done is totally fine. The part I find disingenuous is that it seems like only the static typing zealots are trying to come up with a reason to think a certain way of doing things strictly dominates or supersedes a different way of doing things, and it’s totally disingenuous to act like the benefits of static typing on defect rates would be such an argument for “universal” applicability of one certain paradigm.
    - tome 7y ago
      That's a shame. There are numerous voices clamouring "Haskell's too much effort for its benefits to be worth it". You are basically the only voice saying "Its benefits aren't even benefits". It feels like you could really add something beneficial. If only there were some middle ground between carefully considered and reasoned critique and vague and unsubstantiated sniping on message boards, but so be it.
- youerbt 7y ago
  Well, I'm just pointing out that "easy" is not something that can be attributed to a programming language based on cute, pseudo-code like samples online. You don't see "Python is easy" examples with full test suite attached to them, explaining that, well, you are in for a ride without those. As for your comment: I can believe that production breaking typos may have been at a similar level. I don't believe that the effort to reach that level was the same, though.
- crdoconnor 7y ago
  I've not worked on Haskell but while reading about it I've always been suspicious that its type system is actually effective at preventing integration bugs. It's nice to hear this echoed. I'd love to read more about this experience (good and the bad).

pjmlp 7y ago

Python allows for very creative programming, just because every feature looks easy in isolation, when used together they can open the door to some head scratching.