5 ms·

But it I throw mature Python/C++ code at you, with concepts you don't know, how is it easier? Those Haskell threads are full of exaggerations. I don't know/use

But it I throw mature Python/C++ code at you, with concepts you don't know, how is it easier? Those Haskell threads are full of exaggerations. I don't know/use a lot of Haskell concepts and I can still produce software with it. You can be just fine with IO and passing everything as arguments. Which is, well, what article is talking about.

vbezhenar 7y ago
Why do you write Python and C++ in one line? C++ is an extremely hard and esoteric language. Python is very easy language. They are like two opposite points.
- pjmlp 7y ago
  Python is anything but easy, it is the same caliber as C++, just lacking implementations able to execute as fast. If you are able to master all the language changes between minor releases, master every language feature across objects, metaprogramming, functional, old style classes, multiple inheritance, slots,...., the complete standard library, and all major third party libraries, I bow to thee.
  - lapnitnelav 7y ago
    >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.
    - 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.
  - coldtea 7y ago
    >Python is anything but easy, it is the same caliber as C++, just lacking implementations able to execute as fast. Yeah, that's stretching it to absurdity. Python is easy to get started, and easy to adopt any of the extra features (e.g. slots, metaprogramming, async, etc) piecemeal. And easy to read most codebases. Haskell is not easy to get started, not easy to adopt the extra features piecemeal, and not easy to read most codebases.
    - tome 7y ago
      > Haskell is not easy to get started Agreed > and not easy to read most codebases. Hmm ... debatable. I have to dig in to the implementation of Python libraries and Haskell libraries regularly. I'm much more confident that I'll come away understanding the latter than the former! > not easy to adopt the extra features piecemeal I can't see any evidence of this. Can you name a few Haskell features that can't be adopted in the absence of other features?
      - coldtea 7y ago
        I didn't say that they "can't be adopted", but that it's "not easy" to adopt them (and specifically it's not as easy as Python or even Java, C#, Lua, whatever) -- because they come with a bigger mental burden...
        tome 7y ago
        OK ... can you name a few Haskell features that can't be adopted easily in the absence of other features?
        AstralStorm 7y ago
        How do you functionally manipulate an indexed mutable structure like a vector? How about the common task of CSV file manipulation? Database access? (Simplest of FFI.) Not reopening nor reparsing the file every time you want to do something? At the same time, with known upper bound on memory use? Note how almost none of standard CRUD and web stuff is easy to write in Haskell from scratch and libraries do not help a lot. You always end up in some variant of IO monad, typically multiple incompatible ones at the same time, making the pure functional nature of the language moot. You get to glue the various kinds of IO explicitly. Haskell feels like writing a CPU (high level state machines everywhere), except with less readability and more verbiage than Verilog. The propensity of Haskell programmers to abbreviate everything and add redundant "helper" functions under different names does not help. Programming is stateful because world has a state, and Haskell's handling of state is annoying at every step even for someone versed in it.
- user5994461 7y ago
  C++ can be quite manageable in a professional setting, where you get Qt or boost. Then it's like any other programming language. I think the major troubles for beginners with C++ is that you can't do anything out of the box like work with files, create a directory or perform a HTTP request. Whereas python or java are ready to use.
  - wutbrodo 7y ago
    Eh, I strongly disagree with this characterization. I did c++ for a few years at Google and am now back to developing in it, and I'd say it's probably my favorite language to work in a codebase that sets the right constraints on it. But that doesn't change the fact that it is replete with unintuitive footguns even for those comfortable/experienced with it, in a way that Python or Java absolutely isn't. The closest thing i can think of in Python is passing a mutable object (like an empty list) as a default param value. C++ is littered with bug-prone landmines like that.
scottLobster 7y ago
It's easier because Python/C++ have huge communities at this point and Haskell does not. It's also easier because most people learn some variety of Java/Python/etc as their first language. So languages with similar structures and conventions are easier to grasp. Every time someone has suggested I learn Haskell the discussion goes similar to suggesting I learn German. Sure German from a language perspective has some advantages over English in some situations. Some even argue that it's an objectively better language. But I live in Pennsylvania and speak English as a first language. Outside of moving to Germany/Switzerland/Austria, how do the advantages of German provide enough benefit for me to invest the massive amounts of time to become fluent? Sure if we could turn back the clock on Computer Science education and have everyone learn lisp as their first language maybe we'd all be avid Haskellers these days and be better off for it. But given how history went it is "harder" to learn and less productive to work in due to external factors alone, regardless of how intrinsically easy/hard the language may be (which is entirely subjective).
- dmix 7y ago
  There's still plenty of value in learning Haskell even if you're not going to use it daily. I'd go as far as saying it's essential for anyone who likes programming beyond just a profession. Same with lisp. You don't need to learn all of the language extensions or how to architect serious applications with free as the OP said but it's very useful knowledge and one of the pedestals from which all other languages should be judged. Plus you'll understand why Idris and dependent types are an interesting future development in safety and language design. While also understanding the source and inspiration of many features in far more popular languages like JS and Rust. And there may be a real future in it via PureScript and other similar projects.

vbezhenar 7y ago

Why do you write Python and C++ in one line? C++ is an extremely hard and esoteric language. Python is very easy language. They are like two opposite points.

pjmlp 7y ago
Python is anything but easy, it is the same caliber as C++, just lacking implementations able to execute as fast. If you are able to master all the language changes between minor releases, master every language feature across objects, metaprogramming, functional, old style classes, multiple inheritance, slots,...., the complete standard library, and all major third party libraries, I bow to thee.
- lapnitnelav 7y ago
  >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.
  - 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.
- coldtea 7y ago
  >Python is anything but easy, it is the same caliber as C++, just lacking implementations able to execute as fast. Yeah, that's stretching it to absurdity. Python is easy to get started, and easy to adopt any of the extra features (e.g. slots, metaprogramming, async, etc) piecemeal. And easy to read most codebases. Haskell is not easy to get started, not easy to adopt the extra features piecemeal, and not easy to read most codebases.
  - tome 7y ago
    > Haskell is not easy to get started Agreed > and not easy to read most codebases. Hmm ... debatable. I have to dig in to the implementation of Python libraries and Haskell libraries regularly. I'm much more confident that I'll come away understanding the latter than the former! > not easy to adopt the extra features piecemeal I can't see any evidence of this. Can you name a few Haskell features that can't be adopted in the absence of other features?
    - coldtea 7y ago
      I didn't say that they "can't be adopted", but that it's "not easy" to adopt them (and specifically it's not as easy as Python or even Java, C#, Lua, whatever) -- because they come with a bigger mental burden...
      - tome 7y ago
        OK ... can you name a few Haskell features that can't be adopted easily in the absence of other features?
        AstralStorm 7y ago
        How do you functionally manipulate an indexed mutable structure like a vector? How about the common task of CSV file manipulation? Database access? (Simplest of FFI.) Not reopening nor reparsing the file every time you want to do something? At the same time, with known upper bound on memory use? Note how almost none of standard CRUD and web stuff is easy to write in Haskell from scratch and libraries do not help a lot. You always end up in some variant of IO monad, typically multiple incompatible ones at the same time, making the pure functional nature of the language moot. You get to glue the various kinds of IO explicitly. Haskell feels like writing a CPU (high level state machines everywhere), except with less readability and more verbiage than Verilog. The propensity of Haskell programmers to abbreviate everything and add redundant "helper" functions under different names does not help. Programming is stateful because world has a state, and Haskell's handling of state is annoying at every step even for someone versed in it.
user5994461 7y ago
C++ can be quite manageable in a professional setting, where you get Qt or boost. Then it's like any other programming language. I think the major troubles for beginners with C++ is that you can't do anything out of the box like work with files, create a directory or perform a HTTP request. Whereas python or java are ready to use.
- wutbrodo 7y ago
  Eh, I strongly disagree with this characterization. I did c++ for a few years at Google and am now back to developing in it, and I'd say it's probably my favorite language to work in a codebase that sets the right constraints on it. But that doesn't change the fact that it is replete with unintuitive footguns even for those comfortable/experienced with it, in a way that Python or Java absolutely isn't. The closest thing i can think of in Python is passing a mutable object (like an empty list) as a default param value. C++ is littered with bug-prone landmines like that.

scottLobster 7y ago

It's easier because Python/C++ have huge communities at this point and Haskell does not. It's also easier because most people learn some variety of Java/Python/etc as their first language. So languages with similar structures and conventions are easier to grasp. Every time someone has suggested I learn Haskell the discussion goes similar to suggesting I learn German. Sure German from a language perspective has some advantages over English in some situations. Some even argue that it's an objectively better language. But I live in Pennsylvania and speak English as a first language. Outside of moving to Germany/Switzerland/Austria, how do the advantages of German provide enough benefit for me to invest the massive amounts of time to become fluent? Sure if we could turn back the clock on Computer Science education and have everyone learn lisp as their first language maybe we'd all be avid Haskellers these days and be better off for it. But given how history went it is "harder" to learn and less productive to work in due to external factors alone, regardless of how intrinsically easy/hard the language may be (which is entirely subjective).

dmix 7y ago
There's still plenty of value in learning Haskell even if you're not going to use it daily. I'd go as far as saying it's essential for anyone who likes programming beyond just a profession. Same with lisp. You don't need to learn all of the language extensions or how to architect serious applications with free as the OP said but it's very useful knowledge and one of the pedestals from which all other languages should be judged. Plus you'll understand why Idris and dependent types are an interesting future development in safety and language design. While also understanding the source and inspiration of many features in far more popular languages like JS and Rust. And there may be a real future in it via PureScript and other similar projects.