5 ms·

I guess I took the bait when you "included" dynamic languages, so your little conversation is misleading at best. On topic: Oh, these are great and I wish Hask

I guess I took the bait when you "included" dynamic languages, so your little conversation is misleading at best. On topic: Oh, these are great and I wish Haskell had more of that. But these are "dumb" actions, really. How about: * writing terrible code to get something working, then breaking it down and putting it back up as something production ready * changing core data structure and updating all the code that uses it * solving some problems in separate projects and combining them together * copy-pasting code from another project and adjusting it to a current project All of the above of course without running the program once in between, without changing the desired program's behavior etc. And no, I don't think you can't do that in Java, I just think that Haskell is better at it.

dmitriid 7y ago
All of the above are a combination of of trivial automated code refactorings and some manual work because there's no silver bullet: * writing terrible code to get something working, then breaking it down and putting it back up as something production ready Automated: Extract method, move code, pull members up/down, rename etc. * changing core data structure and updating all the code that uses it Depending on what exactly you're changing. From as simple as automated "update type signatures of all affected functions and methods" to automated "rename" to yes, hunting down compiler errors * solving some problems in separate projects and combining them together and * copy-pasting code from another project and adjusting it to a current project Once again, depending on what and how you combine, using the things from above. There are more powerful tools than "oh, let's run the compiler for each change and manually fix all the errors". The flow should be "let's run all the automated refactorings and then run the compiler to see if those missed something". And these automated refactorings are often reversible with a simple Cmd/Ctrl-Z. Ah, yes. And many of these are available even for dynamically typed languages (but not as powerful and sometimes with caveats, for obvious reasons).
- youerbt 7y ago
  Yes, Haskell is worse with those "trivial automated" (due to worse tooling, nothing about the language prevents that), but imo better with those "hunting down compiler errors". And I take easier manual work on hard problems over trivial automation any time. Java and Python are simply not languages that encourage (or even make possible) writing code that is easy under those changes. In Haskell you have immutability (if something is declared, that's its final value, so I can simply move it around), purity (code that is basically context independent), dumb data structures (no "enterprise boolean" with nontrivial internal state and ceremony to initialize), functional (no code attached to mutable data that may implicitly require data to be in special state), no nulls in flow control (that are invisible to a compiler, so yea good luck moving function around that expects no nulls), ergonomic creation of data/types (so you don't have strings/integers everywhere that are opaque to a compiler). There is no contest, really. Maybe with some modern languages like Rust or TypeScript, but I haven't tried those.
  - dmitriid 7y ago
    > And I take easier manual work on hard problems over trivial automation any time. However, most changes/refactorings I usually encounter are due to trivial problems that can be automated. And I'd love to have those tools for FP where a lot of changes are still just that: rename a function or a field in a data structure, extract a function, rename/move a module, update type signatures etc. However, it looks like the stronger the static typing, the worse are the tools :) Not enough manpower to take care of them, perhaps?
    - youerbt 7y ago
      Yea... that's a trade off, unfortunately, and I won't pick sides here. Stronger static typing has so much potential for tooling, but none of that is reality, sadly. As for Haskell, I think, it's a combination of manpower (so popularity, really) and the fact that the compiler wasn't developed with tooling in mind. Thanks for conversation, stranger, and have a nice day!
      - dmitriid 7y ago
        And same to you, kind stranger!
    - tome 7y ago
      > most changes/refactorings I usually encounter are due to trivial problems that can be automated This is interesting because another popular argument against Haskell is "Haskell's type checker can only check trivial properties that can be automated". Either automating trivial things is valuable or it's not, and the anti-Haskell camp seems not to agree on which!
      - dmitriid 7y ago
        Automating trivial things is immensely valuable. And yes, Haskell’s type checker can only check a subset of things.

dmitriid 7y ago

All of the above are a combination of of trivial automated code refactorings and some manual work because there's no silver bullet: * writing terrible code to get something working, then breaking it down and putting it back up as something production ready Automated: Extract method, move code, pull members up/down, rename etc. * changing core data structure and updating all the code that uses it Depending on what exactly you're changing. From as simple as automated "update type signatures of all affected functions and methods" to automated "rename" to yes, hunting down compiler errors * solving some problems in separate projects and combining them together and * copy-pasting code from another project and adjusting it to a current project Once again, depending on what and how you combine, using the things from above. There are more powerful tools than "oh, let's run the compiler for each change and manually fix all the errors". The flow should be "let's run all the automated refactorings and then run the compiler to see if those missed something". And these automated refactorings are often reversible with a simple Cmd/Ctrl-Z. Ah, yes. And many of these are available even for dynamically typed languages (but not as powerful and sometimes with caveats, for obvious reasons).

youerbt 7y ago
Yes, Haskell is worse with those "trivial automated" (due to worse tooling, nothing about the language prevents that), but imo better with those "hunting down compiler errors". And I take easier manual work on hard problems over trivial automation any time. Java and Python are simply not languages that encourage (or even make possible) writing code that is easy under those changes. In Haskell you have immutability (if something is declared, that's its final value, so I can simply move it around), purity (code that is basically context independent), dumb data structures (no "enterprise boolean" with nontrivial internal state and ceremony to initialize), functional (no code attached to mutable data that may implicitly require data to be in special state), no nulls in flow control (that are invisible to a compiler, so yea good luck moving function around that expects no nulls), ergonomic creation of data/types (so you don't have strings/integers everywhere that are opaque to a compiler). There is no contest, really. Maybe with some modern languages like Rust or TypeScript, but I haven't tried those.
- dmitriid 7y ago
  > And I take easier manual work on hard problems over trivial automation any time. However, most changes/refactorings I usually encounter are due to trivial problems that can be automated. And I'd love to have those tools for FP where a lot of changes are still just that: rename a function or a field in a data structure, extract a function, rename/move a module, update type signatures etc. However, it looks like the stronger the static typing, the worse are the tools :) Not enough manpower to take care of them, perhaps?
  - youerbt 7y ago
    Yea... that's a trade off, unfortunately, and I won't pick sides here. Stronger static typing has so much potential for tooling, but none of that is reality, sadly. As for Haskell, I think, it's a combination of manpower (so popularity, really) and the fact that the compiler wasn't developed with tooling in mind. Thanks for conversation, stranger, and have a nice day!
    - dmitriid 7y ago
      And same to you, kind stranger!
  - tome 7y ago
    > most changes/refactorings I usually encounter are due to trivial problems that can be automated This is interesting because another popular argument against Haskell is "Haskell's type checker can only check trivial properties that can be automated". Either automating trivial things is valuable or it's not, and the anti-Haskell camp seems not to agree on which!
    - dmitriid 7y ago
      Automating trivial things is immensely valuable. And yes, Haskell’s type checker can only check a subset of things.