7 ms·

To most (if not all) production ready languages out there.

ukj 7y ago
Perhaps you didn't understand my point. Being 'good at refactoring' is only a desirable feature if you are spending a lot of your time refactoring code. Why are you spending so much of your time refactoring code? Because your language isn't extensible!
- youerbt 7y ago
  Being good at refactoring is desirable, so you don't have to "anticipate/predict everything ahead of implementation". What is your "extensible code", I don't know, but it doesn't matter, because we are talking about your comment on Haskell. But maybe you are just a troll, so w/e.
  - ukj 7y ago
    Do you understand the difference between extensibility and refactoring? For the purposes of flexibility extensibility is more desirable than refactorability (to me and my problem space anyway). >because we are talking about your comment on Haskell. I am not in the habit of commenting about things in a vacuum. I am comparing Haskell to other tools in my toolbox. I am sure that in the Haskell universe (isolated from the rest of reality) Haskell is the greatest thing ever.
    - the_af 7y ago
      What do you mean by "extensible" and which language in your opinion solves this problem adequately?
      - ukj 7y ago
        I mean adding setters/getters to existing data types. It's solved in any language in which mutable data structures don't require a Rube Goldberg machine like lenses. e.g languages which optimise for expressiveness over purism. Languages which give me the expressive power to disregard the 'law' of non-contradiction if I happen to think it's a good idea to do so for whatever reason https://repl.it/repls/RoundRelevantExternalcommand https://repl.it/repls/RoundRelevantExternalcommand
        the_af 7y ago
        Oh. Ruby. In any case, adding getters/setters doesn't imply extensibility and doesn't apply to FP languages (or rather: in FP languages you can add more functions). Getters/setters are often an anti-pattern anyway. Maybe you have a better example? In any case it's very easy to "extend" types in Haskell, it just looks different to what you'd do in Ruby. As for expressive power, are you familiar with the "expression problem"? [0] There's almost always a trade-off your language is making. I don't understand what you mean by law of non-contradiction in this context. [0] the expression problem: https://en.m.wikipedia.org/wiki/Expression_problem https://en.m.wikipedia.org/wiki/Expression_problem
        ukj 7y ago
        Getters/setters may be seen as anti-patterns in the functional paradigm. They are seen as pattern in the imperative paradigm. Of course I am making trade-offs, but so are you. It's just another word for making choices. What I mean is literally being able to evaluate P ∧ ¬P as True, as an empirical test for a language's expressivity. You can't do that in Haskell - it won't let you. The language is in control, not you. In my problem-space not being in control is an anti-pattern.
        the_af 7y ago
        I meant getters/setters are an antipattern in OOP languages. In FP there are no getters or setters, so the question is meaningless. Ruby is not more expressive than Haskell. In fact, I'm pretty sure it's less expressive, because it cannot say everything Haskell can, but Haskell can say everything Ruby can. You say you understand everything is a trade-off but then you make claims about lack of expressivity ;) Do you know the expression problem? Still don't understand your non-contradiction example.
        ukj 7y ago
        >Still don't understand your non-contradiction example. >Haskell can say everything Ruby can Go ahead and say P ∧ ¬P ⇔ True in Haskell. Here is me saying it in Ruby: https://repl.it/repls/AccurateJauntyDimension https://repl.it/repls/AccurateJauntyDimension
- the_af 7y ago
  > Being 'good at refactoring' is only a desirable feature if you are spending a lot of your time refactoring code. Not a fan of TDD, eh?
  - ukj 7y ago
    TDD has its uses. BDD has its uses. Code first - test later has its uses. YOLO has its uses. Not a fan of silver bullets.
    - the_af 7y ago
      I don't disagree with the "no silver bullet" quote, but you can't answer every question with that phrase. I also agree re TDD, etc. But your comment is still odd. Refactoring seems to be a core tenet of modern programming (regardless of TDD). In TDD in particular it's a central part of how you work, and so your remark sounds odd unless you also claim you don't believe in TDD :)
dmitriid 7y ago
Most languages out there including dynamic ones have built-in IDE support that tracks refactoring down to comments. Don’t know what the state of Haskell refactoring is now but it looks like until very recently “great refactoring” was “change one thing and then manually fix compiler errors”.
- youerbt 7y ago
  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.

ukj 7y ago

Perhaps you didn't understand my point. Being 'good at refactoring' is only a desirable feature if you are spending a lot of your time refactoring code. Why are you spending so much of your time refactoring code? Because your language isn't extensible!

youerbt 7y ago
Being good at refactoring is desirable, so you don't have to "anticipate/predict everything ahead of implementation". What is your "extensible code", I don't know, but it doesn't matter, because we are talking about your comment on Haskell. But maybe you are just a troll, so w/e.
- ukj 7y ago
  Do you understand the difference between extensibility and refactoring? For the purposes of flexibility extensibility is more desirable than refactorability (to me and my problem space anyway). >because we are talking about your comment on Haskell. I am not in the habit of commenting about things in a vacuum. I am comparing Haskell to other tools in my toolbox. I am sure that in the Haskell universe (isolated from the rest of reality) Haskell is the greatest thing ever.
  - the_af 7y ago
    What do you mean by "extensible" and which language in your opinion solves this problem adequately?
    - ukj 7y ago
      I mean adding setters/getters to existing data types. It's solved in any language in which mutable data structures don't require a Rube Goldberg machine like lenses. e.g languages which optimise for expressiveness over purism. Languages which give me the expressive power to disregard the 'law' of non-contradiction if I happen to think it's a good idea to do so for whatever reason https://repl.it/repls/RoundRelevantExternalcommand https://repl.it/repls/RoundRelevantExternalcommand
      - the_af 7y ago
        Oh. Ruby. In any case, adding getters/setters doesn't imply extensibility and doesn't apply to FP languages (or rather: in FP languages you can add more functions). Getters/setters are often an anti-pattern anyway. Maybe you have a better example? In any case it's very easy to "extend" types in Haskell, it just looks different to what you'd do in Ruby. As for expressive power, are you familiar with the "expression problem"? [0] There's almost always a trade-off your language is making. I don't understand what you mean by law of non-contradiction in this context. [0] the expression problem: https://en.m.wikipedia.org/wiki/Expression_problem https://en.m.wikipedia.org/wiki/Expression_problem
        ukj 7y ago
        Getters/setters may be seen as anti-patterns in the functional paradigm. They are seen as pattern in the imperative paradigm. Of course I am making trade-offs, but so are you. It's just another word for making choices. What I mean is literally being able to evaluate P ∧ ¬P as True, as an empirical test for a language's expressivity. You can't do that in Haskell - it won't let you. The language is in control, not you. In my problem-space not being in control is an anti-pattern.
        the_af 7y ago
        I meant getters/setters are an antipattern in OOP languages. In FP there are no getters or setters, so the question is meaningless. Ruby is not more expressive than Haskell. In fact, I'm pretty sure it's less expressive, because it cannot say everything Haskell can, but Haskell can say everything Ruby can. You say you understand everything is a trade-off but then you make claims about lack of expressivity ;) Do you know the expression problem? Still don't understand your non-contradiction example.
        ukj 7y ago
        >Still don't understand your non-contradiction example. >Haskell can say everything Ruby can Go ahead and say P ∧ ¬P ⇔ True in Haskell. Here is me saying it in Ruby: https://repl.it/repls/AccurateJauntyDimension https://repl.it/repls/AccurateJauntyDimension
the_af 7y ago
> Being 'good at refactoring' is only a desirable feature if you are spending a lot of your time refactoring code. Not a fan of TDD, eh?
- ukj 7y ago
  TDD has its uses. BDD has its uses. Code first - test later has its uses. YOLO has its uses. Not a fan of silver bullets.
  - the_af 7y ago
    I don't disagree with the "no silver bullet" quote, but you can't answer every question with that phrase. I also agree re TDD, etc. But your comment is still odd. Refactoring seems to be a core tenet of modern programming (regardless of TDD). In TDD in particular it's a central part of how you work, and so your remark sounds odd unless you also claim you don't believe in TDD :)

dmitriid 7y ago

Most languages out there including dynamic ones have built-in IDE support that tracks refactoring down to comments. Don’t know what the state of Haskell refactoring is now but it looks like until very recently “great refactoring” was “change one thing and then manually fix compiler errors”.

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