6 ms·

Haskell has enormous momentum now[1], and it's speed of development is accelerating. I came to it not because it was cool, but because my experience maintaining

Haskell has enormous momentum now[1], and it's speed of development is accelerating. I came to it not because it was cool, but because my experience maintaining and refactoring a big Python program had become really painful. Haskell lets me keep the codebase smaller, it's easier to be pretty sure things are working, it's easier to refactor, and I'm sure the language will only keep getting better. Those are all understatements. [1] https://www.haskell.org/communities/05-2017/html/report.html https://www.haskell.org/communities/05-2017/html/report.html

fjsolwmv 9y ago
That's been the story of Haskell for over 10 years. The world and other language ecosystems are changing faster than Haskell is growing. Clojure and Scala give you an alternative to Python that have the power of the Java ecosystem to take your programming out of academic and toy projects. And Python finally has static typing, 10 years after it was announced.
- Jeff_Brown 9y ago
  What changes do you think Haskell can't keep up with? If you want to approximate the cool things in Haskell with a Python-compatible* language, there's Coconut. In addition to static typing, it offers algebraic data types (how I lived without sum types, I don't know) and pattern matching. * every valid Python program is valid Coconut
  - brightsize 9y ago
    "Coconut: Simple, elegant, Pythonic functional programming." http://coconut-lang.org/ http://coconut-lang.org/
    - rthomas6 9y ago
      Wow, this looks very cool! Why is this not more popular? Coconut seems like something many people, including me, would want to use for every Python project of sufficient complexity. What's the catch?
      - platz 9y ago
        You write in a dialect that python programmers do not understand. it is a deviation from the norm. expectations on others that have to read/understand/use your code.
      - brightsize 9y ago
        Fanboy here. I've used Coconut extensively and it's a joy. I wouldn't start a (personal) Python-targeted project without it. Pattern-matching, a non-horrid lambda syntax, lazy evaluation, TCO, a built-in partial function syntax, and finally the pipeline operator (|>) are all things I'd hate to be without now. A more detailed list of features (incl. MyPy integration) is here: http://coconut.readthedocs.io/en/latest/ http://coconut.readthedocs.io/en/latest/ . The docs are just great too. The catches: 1. You have to be OK with a compilation step that isn't part of the Python world. 2. To the best of my knowledge the language has been and still is being developed by a single person, so there's the "Evan gets hit by a bus" risk built in. 3. Tooling is virtually nonexistent. There's a Vim plugin that understands the language syntax but there's zero IDE support. Of course you can debug the generated Python with Pycharm/VS Code/etc and having done it I can say it's not terribly painful but isn't terribly fun either. I think that over time the lack of tooling will be the biggest hindrance to the language's further adoption. OTOH I'd be curious to know if this has been a major factor in other unpopular languages remaining unpopular. I seem to remember a lot of complaints about tooling in the early days of Scala but the language still managed to become fairly successful once that situation improved. Edit: formatting, final thoughts
        rthomas6 9y ago
        I thought about it, and I think the unpopularity of Coconut might be due to the existence of the Toolz library. That gives most things that Coconut does minus better lamda and TCO.
- sidlls 9y ago
  Python has static typing? Since when? In what form?
  - yawaramin 9y ago
    Python 3 supports type annotations natively, and the mypy tool is an external typechecker that you can run just like any other static analysis tool during your build.
    - sidlls 9y ago
      That isn't static typing.
      - CydeWeys 9y ago
        Whatever you want to call it, it's a lot more static than it used to be.
      - yawaramin 9y ago
        - You can specify types - Types are checked before run time - Type errors are reported If that's not static typing, what is?
        sidlls 9y ago
        This argument isn't convincing. These artifacts are hints that can be ignored, not constraints to the python interpreter. It seems to me a bit like arguing that the existence of Coverity (and other static analysis tools) means C is as safe as Rust.
        yawaramin 9y ago
        The types were never meant for the Python interpreter, they were meant as documentation and as input for static analysis tools. Mypy just happens to be a static typechecker that takes advantage of the type annotations. Just because mypy is optional doesn't mean it's not static typing.
- nilkn 9y ago
  You're sort of painting a picture here of Haskell and all other languages skating towards some unknown target point, with Haskell skating the slowest. But, at the risk of sounding like a fanboy, it could be that Haskell simply started out significantly closer to that target point, so that other languages are effectively skating towards it. In this way, both your statement and the parent's statement can be simultaneously true.
sridca 9y ago
That has exactly been my experience as well, and the reason why I decided to work with Haskell professionally instead of continuing to write Python, Elixir or what have you. On to the topic of this submission itself, Elm turned out to be a gateway drug to Haskell for me. Similar to Paul Chiusano[1] I decided to switch from Elm to GHCJS (Haskell). I started with https://haskell-miso.org/ https://haskell-miso.org/ (based on the Elm architecture) but I'm currently developing using http://docs.reflex-frp.org/ http://docs.reflex-frp.org/ [1] https://pchiusano.github.io/2015-04-23/unison-update7.html https://pchiusano.github.io/2015-04-23/unison-update7.html
woolvalley 9y ago
How much of it was haskell, and how much of it was just working with a statically typed language?
- ujal 9y ago
  In my case the verbosity of Typescript or Flow stops me from adopting it. Still waiting for Elm/Haskell-style type signatures for Javascript.
- szatkus 9y ago
  Considering that Haskell type system is much more advanced than others (Java or C++ for example) I think it's a lot.
- Jeff_Brown 9y ago
  I used Java, C and C++ before coming to Python. Unlike theirs, Haskell's type system is complete -- even a function of functions can specify exactly what kinds of functions it uses for inputs and outputs. That makes higher order programming much safer -- and higher-order programming might be the best way to move fast. Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on a page, full of redundancies and boilerplate. In Haskell if you want to make, say, a data type that is either an X or an O (suppose you're writing tic-tac-toe), you could do it in four words: 'data XO = X | O'. (Notice that there's not even a natural way to do that in Java or C, because they don't have sum types; you'd have to make a type that has a flag to indicate whether it is an X or an O. That gets really complicated if they're supposed to have different data associated with it -- but in Haskell, if the X is supposed to carry a float and the O is supposed to carry a string, you just add two more words.) Pattern matching also helps with terseness. I don't have time even to write the last paragraph so I'll skip this one. Purity keeps you from tripping up on IO-related errors. It lets you be much more certain that things are working. It also forces you to keep the IO in a thin top-level layer of your program, which might sound like a pain but once it feels natural you'll find yourself moving faster than you could before. To be sure, Haskell has features that I don't use. But purity, sum types, pattern matching, and the unusually rigorous (it's complete!) type system are all critical to its value to me.

fjsolwmv 9y ago

That's been the story of Haskell for over 10 years. The world and other language ecosystems are changing faster than Haskell is growing. Clojure and Scala give you an alternative to Python that have the power of the Java ecosystem to take your programming out of academic and toy projects. And Python finally has static typing, 10 years after it was announced.

Jeff_Brown 9y ago
What changes do you think Haskell can't keep up with? If you want to approximate the cool things in Haskell with a Python-compatible* language, there's Coconut. In addition to static typing, it offers algebraic data types (how I lived without sum types, I don't know) and pattern matching. * every valid Python program is valid Coconut
- brightsize 9y ago
  "Coconut: Simple, elegant, Pythonic functional programming." http://coconut-lang.org/ http://coconut-lang.org/
  - rthomas6 9y ago
    Wow, this looks very cool! Why is this not more popular? Coconut seems like something many people, including me, would want to use for every Python project of sufficient complexity. What's the catch?
    - platz 9y ago
      You write in a dialect that python programmers do not understand. it is a deviation from the norm. expectations on others that have to read/understand/use your code.
    - brightsize 9y ago
      Fanboy here. I've used Coconut extensively and it's a joy. I wouldn't start a (personal) Python-targeted project without it. Pattern-matching, a non-horrid lambda syntax, lazy evaluation, TCO, a built-in partial function syntax, and finally the pipeline operator (|>) are all things I'd hate to be without now. A more detailed list of features (incl. MyPy integration) is here: http://coconut.readthedocs.io/en/latest/ http://coconut.readthedocs.io/en/latest/ . The docs are just great too. The catches: 1. You have to be OK with a compilation step that isn't part of the Python world. 2. To the best of my knowledge the language has been and still is being developed by a single person, so there's the "Evan gets hit by a bus" risk built in. 3. Tooling is virtually nonexistent. There's a Vim plugin that understands the language syntax but there's zero IDE support. Of course you can debug the generated Python with Pycharm/VS Code/etc and having done it I can say it's not terribly painful but isn't terribly fun either. I think that over time the lack of tooling will be the biggest hindrance to the language's further adoption. OTOH I'd be curious to know if this has been a major factor in other unpopular languages remaining unpopular. I seem to remember a lot of complaints about tooling in the early days of Scala but the language still managed to become fairly successful once that situation improved. Edit: formatting, final thoughts
      - rthomas6 9y ago
        I thought about it, and I think the unpopularity of Coconut might be due to the existence of the Toolz library. That gives most things that Coconut does minus better lamda and TCO.
sidlls 9y ago
Python has static typing? Since when? In what form?
- yawaramin 9y ago
  Python 3 supports type annotations natively, and the mypy tool is an external typechecker that you can run just like any other static analysis tool during your build.
  - sidlls 9y ago
    That isn't static typing.
    - CydeWeys 9y ago
      Whatever you want to call it, it's a lot more static than it used to be.
    - yawaramin 9y ago
      - You can specify types - Types are checked before run time - Type errors are reported If that's not static typing, what is?
      - sidlls 9y ago
        This argument isn't convincing. These artifacts are hints that can be ignored, not constraints to the python interpreter. It seems to me a bit like arguing that the existence of Coverity (and other static analysis tools) means C is as safe as Rust.
        yawaramin 9y ago
        The types were never meant for the Python interpreter, they were meant as documentation and as input for static analysis tools. Mypy just happens to be a static typechecker that takes advantage of the type annotations. Just because mypy is optional doesn't mean it's not static typing.
nilkn 9y ago
You're sort of painting a picture here of Haskell and all other languages skating towards some unknown target point, with Haskell skating the slowest. But, at the risk of sounding like a fanboy, it could be that Haskell simply started out significantly closer to that target point, so that other languages are effectively skating towards it. In this way, both your statement and the parent's statement can be simultaneously true.

sridca 9y ago

That has exactly been my experience as well, and the reason why I decided to work with Haskell professionally instead of continuing to write Python, Elixir or what have you. On to the topic of this submission itself, Elm turned out to be a gateway drug to Haskell for me. Similar to Paul Chiusano[1] I decided to switch from Elm to GHCJS (Haskell). I started with https://haskell-miso.org/ https://haskell-miso.org/ (based on the Elm architecture) but I'm currently developing using http://docs.reflex-frp.org/ http://docs.reflex-frp.org/ [1] https://pchiusano.github.io/2015-04-23/unison-update7.html https://pchiusano.github.io/2015-04-23/unison-update7.html

woolvalley 9y ago

How much of it was haskell, and how much of it was just working with a statically typed language?

ujal 9y ago
In my case the verbosity of Typescript or Flow stops me from adopting it. Still waiting for Elm/Haskell-style type signatures for Javascript.
szatkus 9y ago
Considering that Haskell type system is much more advanced than others (Java or C++ for example) I think it's a lot.
Jeff_Brown 9y ago
I used Java, C and C++ before coming to Python. Unlike theirs, Haskell's type system is complete -- even a function of functions can specify exactly what kinds of functions it uses for inputs and outputs. That makes higher order programming much safer -- and higher-order programming might be the best way to move fast. Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on a page, full of redundancies and boilerplate. In Haskell if you want to make, say, a data type that is either an X or an O (suppose you're writing tic-tac-toe), you could do it in four words: 'data XO = X | O'. (Notice that there's not even a natural way to do that in Java or C, because they don't have sum types; you'd have to make a type that has a flag to indicate whether it is an X or an O. That gets really complicated if they're supposed to have different data associated with it -- but in Haskell, if the X is supposed to carry a float and the O is supposed to carry a string, you just add two more words.) Pattern matching also helps with terseness. I don't have time even to write the last paragraph so I'll skip this one. Purity keeps you from tripping up on IO-related errors. It lets you be much more certain that things are working. It also forces you to keep the IO in a thin top-level layer of your program, which might sound like a pain but once it feels natural you'll find yourself moving faster than you could before. To be sure, Haskell has features that I don't use. But purity, sum types, pattern matching, and the unusually rigorous (it's complete!) type system are all critical to its value to me.