5 ms·

Do you understand the difference between extensibility and refactoring? For the purposes of flexibility extensibility is more desirable than refactorability (to

by 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
        Neat. How did you do that? (Seems like something a language ought to forbid, anyway). edit: ok, from what I've deciphered from your Ruby code, it's nothing special. You've declared a global boolean and every invocation of function "p" flips the value, so it's only a parlor trick and nothing to do with the expressivity of the language. Any language with side-effects and mutable globals will achieve this trick in the same manner. It's a trick because your first "p" and your second "p" aren't the same "p", so there's no real violation of the "law of non-contradiction". What about the rest of my comment? The expression problem? That getters/setters are an anti-pattern in OOP languages (just ask Alan Kay...)?

by ukj 7y ago

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
        Neat. How did you do that? (Seems like something a language ought to forbid, anyway). edit: ok, from what I've deciphered from your Ruby code, it's nothing special. You've declared a global boolean and every invocation of function "p" flips the value, so it's only a parlor trick and nothing to do with the expressivity of the language. Any language with side-effects and mutable globals will achieve this trick in the same manner. It's a trick because your first "p" and your second "p" aren't the same "p", so there's no real violation of the "law of non-contradiction". What about the rest of my comment? The expression problem? That getters/setters are an anti-pattern in OOP languages (just ask Alan Kay...)?