3 ms·

Change one thing and manually fix compiler errors it's what I'm talking about. Point me to something like that, for, lets say, Python. For example to error whe

Change one thing and manually fix compiler errors it's what I'm talking about. Point me to something like that, for, lets say, Python. For example to error when I misuse return value of a function. Or when I decide that this string is no longer a string but a customer name. Or when my function will call IO operation, but it's not allowed to do so. Or when I add new field to a record and its not fully constructed somewhere.

dmitriid 7y ago
This is what I dislike about Haskell discourse: - We are a statically typed language with significantly better support for refactoring than anything else out there - But... - Let's say Python Let's say Java, why don't we? A language with significantly better support than "change one thing and manually fix compiler errors". See IntelliJ's capabilities: https://www.jetbrains.com/help/idea/refactoring-source-code.html https://www.jetbrains.com/help/idea/refactoring-source-code.... (there are 23 subsections) And even Python's capabilities are significantly better than manually hunting through compiler errors (though obviously not as extensive): https://www.jetbrains.com/help/pycharm/refactoring-source-code.html https://www.jetbrains.com/help/pycharm/refactoring-source-co...
- youerbt 7y ago
  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

This is what I dislike about Haskell discourse: - We are a statically typed language with significantly better support for refactoring than anything else out there - But... - Let's say Python Let's say Java, why don't we? A language with significantly better support than "change one thing and manually fix compiler errors". See IntelliJ's capabilities: https://www.jetbrains.com/help/idea/refactoring-source-code.html https://www.jetbrains.com/help/idea/refactoring-source-code.... (there are 23 subsections) And even Python's capabilities are significantly better than manually hunting through compiler errors (though obviously not as extensive): https://www.jetbrains.com/help/pycharm/refactoring-source-code.html https://www.jetbrains.com/help/pycharm/refactoring-source-co...

youerbt 7y ago
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.