4 ms·

What are your favorite new developments in tooling? I haven’t used Haskell since 2014.

by bufo 5y ago

whateveracct 5y ago
For all the new tools (HLS, Wingman), it's the core tooling that has improved the most since the then. GHC (+ghci) and cabal are leagues ahead of 2014 now. Some other cool tooling advancements since then that come to mind are.. Nix integration (both nixpkgs and haskell.nix), ghc heapview, ghcjs, a glut of formatters, ghcid (is this that new?)
- bufo 5y ago
  Thanks I'll take a look!
  - whateveracct 5y ago
    Perusing GHC changelogs since then will show you a _lot_ of new things in the language, compiler, and repl for sure.
- wyager 5y ago
  Ghcid rocks! Makes it super easy to develop in a terminal with no IDE. Just a text editor here and ghcid there, telling me instantly when I make a mistake.
  - exdsq 5y ago
    Why would you want to develop in a terminal with no IDE? The only other people I've seen do this were long-term Haskell developers (I remember seeing someone fixing a bug with sed!)
    - wyager 5y ago
      It makes you write better code with a smaller local conceptual branching factor. You need to be able to keep the number of concepts required to comprehend a piece of code small enough to fit in working memory. This forces you to structure your code well, come up with better abstractions, etc. It's also more zen, faster (in terms of UI responsiveness), less prone to breaking, requires less maintenance and configuration, etc. IDEs are generally terrible for code quality, (and for my personal happiness,) but they're also viral because if one person working on a codebase is using an IDE, then they're probably going to write code that forces everyone else to also use an IDE - e.g. because understanding the code practically requires jump-to-definition.
      - runeks 5y ago
        > […] e.g. because understanding the code practically requires jump-to-definition. Wait… so the code you write makes me magically able to know the record field names of your data types without looking at their definition? Your statement may be true if it’s talking only about the core logic of an application, but when we get to the part that interfaces with the rest of the world, things always get somewhat messy. An IDE is a huge help here. I mean, sure, you may be able to memorize the arguments that “readCreateProcess” takes (https://www.stackage.org/haddock/lts-18.19/process-1.6.13.2/System-Process.html#t:CreateProcess https://www.stackage.org/haddock/lts-18.19/process-1.6.13.2/...), but sometimes it’s really handy to have an IDE help you with this.
        wyager 5y ago
        > I mean, sure, you may be able to memorize the arguments that “readCreateProcess” takes How frequently would you use and subsequently forget how to use this function? If I use a library function like this, I most likely write it exactly once in my codebase. The cognitive overhead of going on hackage one time per project-library is very small. I agree an IDE makes you marginally faster in this case - just pointing out that this marginal benefit need not be significant.
        whateveracct 5y ago
        Knowing record field names without looking at the definition isn't a critical path of coding worth optimizing. Amdahl's Law applies to code editing too. Hoogle and even a simple "rg -A10 'data TheRecordName'" work perfectly fine. No reason to shave seconds with an entirely different tool. For readCreateProcess, I just..look at the Haddocks while I program :)
    - whateveracct 5y ago
      Speaking from years of pro & hobbyist Haskelling: Good Haskell modules tend to be quite literate and are therefore easy to read as plaintext. Clicking into the source of Hackage is often very fruitful compared to other languages (Go comes to mind.) Often they aren't meant to be read top-to-bottom of course, but they're a few hundred lines of code that makes sense and backs a very readable export list. And good Haskell isn't especially bound by writing and managing the code. You spend most of the time thinking and then a small amount of excellent, composable code pops out. Rinse, repeat, compose it all together.
      - runeks 5y ago
        > And good Haskell isn't especially bound by writing and managing the code. You spend most of the time thinking and then a small amount of excellent, composable code pops out. Rinse, repeat, compose it all together. Haskell is no different than any other language in this regard. Implementing e.g. a standard CRUD app in Haskell using “beam” involves a lot of boilerplate, for which a proper IDE is super useful.
        wyager 5y ago
        > Haskell is no different than any other language in this regard It absolutely 100% is. This is half the reason people like to use it. > Implementing e.g. a standard CRUD app in Haskell using “beam” involves a lot of boilerplate I haven't used beam, but for me, the appeal of Haskell is that that you can throw out like 90% of the low-semantic-density boilerplate you see elsewhere. Composable abstractions, typeclasses, generics, lenses, etc. - all of these things directly serve to reduce unnecessary semantic sparsity, and incidentally obviate the need for an IDE.
        foldr 5y ago
        Haskell has a decent web ecosystem at this point. However, if you really want to avoid boilerplate when writing a CRUD app, your best choice is one of the big, boring popular web frameworks (Ruby on Rails, Django, etc.) 90% of boilerplate avoidance has less to do with fancy language features than it does with someone else already having done the work for you. (And dynamic languages like Ruby and Python do allow all kinds of fancy abstractions anyway - just without the security of compile time typing.)
    - thih9 5y ago
      Less distraction. An IDE gives you hints and you learn to rely on them; it takes 1 second to check something and you end up doing many checks like this. In a terminal you have to check everything and remember about everything yourself. Maybe it takes 1 minute instead of 1 second. So you only do this when it matters and you make sure you remember the result because you don’t want to waste that 1 minute again.

What are your favorite new developments in tooling? I haven’t used Haskell since 2014.

by bufo 5y ago

What are your favorite new developments in tooling? I haven’t used Haskell since 2014.

For all the new tools (HLS, Wingman), it's the core tooling that has improved the most since the then. GHC (+ghci) and cabal are leagues ahead of 2014 now. Some other cool tooling advancements since then that come to mind are.. Nix integration (both nixpkgs and haskell.nix), ghc heapview, ghcjs, a glut of formatters, ghcid (is this that new?)

bufo 5y ago
Thanks I'll take a look!
- whateveracct 5y ago
  Perusing GHC changelogs since then will show you a _lot_ of new things in the language, compiler, and repl for sure.
wyager 5y ago
Ghcid rocks! Makes it super easy to develop in a terminal with no IDE. Just a text editor here and ghcid there, telling me instantly when I make a mistake.
- exdsq 5y ago
  Why would you want to develop in a terminal with no IDE? The only other people I've seen do this were long-term Haskell developers (I remember seeing someone fixing a bug with sed!)
  - wyager 5y ago
    It makes you write better code with a smaller local conceptual branching factor. You need to be able to keep the number of concepts required to comprehend a piece of code small enough to fit in working memory. This forces you to structure your code well, come up with better abstractions, etc. It's also more zen, faster (in terms of UI responsiveness), less prone to breaking, requires less maintenance and configuration, etc. IDEs are generally terrible for code quality, (and for my personal happiness,) but they're also viral because if one person working on a codebase is using an IDE, then they're probably going to write code that forces everyone else to also use an IDE - e.g. because understanding the code practically requires jump-to-definition.
    - runeks 5y ago
      > […] e.g. because understanding the code practically requires jump-to-definition. Wait… so the code you write makes me magically able to know the record field names of your data types without looking at their definition? Your statement may be true if it’s talking only about the core logic of an application, but when we get to the part that interfaces with the rest of the world, things always get somewhat messy. An IDE is a huge help here. I mean, sure, you may be able to memorize the arguments that “readCreateProcess” takes (https://www.stackage.org/haddock/lts-18.19/process-1.6.13.2/System-Process.html#t:CreateProcess https://www.stackage.org/haddock/lts-18.19/process-1.6.13.2/...), but sometimes it’s really handy to have an IDE help you with this.
      - wyager 5y ago
        > I mean, sure, you may be able to memorize the arguments that “readCreateProcess” takes How frequently would you use and subsequently forget how to use this function? If I use a library function like this, I most likely write it exactly once in my codebase. The cognitive overhead of going on hackage one time per project-library is very small. I agree an IDE makes you marginally faster in this case - just pointing out that this marginal benefit need not be significant.
      - whateveracct 5y ago
        Knowing record field names without looking at the definition isn't a critical path of coding worth optimizing. Amdahl's Law applies to code editing too. Hoogle and even a simple "rg -A10 'data TheRecordName'" work perfectly fine. No reason to shave seconds with an entirely different tool. For readCreateProcess, I just..look at the Haddocks while I program :)
  - whateveracct 5y ago
    Speaking from years of pro & hobbyist Haskelling: Good Haskell modules tend to be quite literate and are therefore easy to read as plaintext. Clicking into the source of Hackage is often very fruitful compared to other languages (Go comes to mind.) Often they aren't meant to be read top-to-bottom of course, but they're a few hundred lines of code that makes sense and backs a very readable export list. And good Haskell isn't especially bound by writing and managing the code. You spend most of the time thinking and then a small amount of excellent, composable code pops out. Rinse, repeat, compose it all together.
    - runeks 5y ago
      > And good Haskell isn't especially bound by writing and managing the code. You spend most of the time thinking and then a small amount of excellent, composable code pops out. Rinse, repeat, compose it all together. Haskell is no different than any other language in this regard. Implementing e.g. a standard CRUD app in Haskell using “beam” involves a lot of boilerplate, for which a proper IDE is super useful.
      - wyager 5y ago
        > Haskell is no different than any other language in this regard It absolutely 100% is. This is half the reason people like to use it. > Implementing e.g. a standard CRUD app in Haskell using “beam” involves a lot of boilerplate I haven't used beam, but for me, the appeal of Haskell is that that you can throw out like 90% of the low-semantic-density boilerplate you see elsewhere. Composable abstractions, typeclasses, generics, lenses, etc. - all of these things directly serve to reduce unnecessary semantic sparsity, and incidentally obviate the need for an IDE.
        foldr 5y ago
        Haskell has a decent web ecosystem at this point. However, if you really want to avoid boilerplate when writing a CRUD app, your best choice is one of the big, boring popular web frameworks (Ruby on Rails, Django, etc.) 90% of boilerplate avoidance has less to do with fancy language features than it does with someone else already having done the work for you. (And dynamic languages like Ruby and Python do allow all kinds of fancy abstractions anyway - just without the security of compile time typing.)
  - thih9 5y ago
    Less distraction. An IDE gives you hints and you learn to rely on them; it takes 1 second to check something and you end up doing many checks like this. In a terminal you have to check everything and remember about everything yourself. Maybe it takes 1 minute instead of 1 second. So you only do this when it matters and you make sure you remember the result because you don’t want to waste that 1 minute again.