12 ms·

>Architecture is extremely sensitive to the initial choices due to isolation of side effects. This is fundamentally why it's useless in practice. It requires y

by ukj 7y ago

>Architecture is extremely sensitive to the initial choices due to isolation of side effects. This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation. It requires you to be perfect at Waterfall ( https://en.wikipedia.org/wiki/Waterfall_model https://en.wikipedia.org/wiki/Waterfall_model ). Real-world problems laugh at such idealism.

mic47 7y ago
>Architecture is extremely sensitive to the initial choices due to isolation of side effects. Only if you choose to isolate all side effects from each other. Actually Haskell makes refactoring really easy, so you can adapt your implemention to changing requirements easily.
- h91wka 7y ago
  Why would I need to refactor anything in this situation in the first place?
  - mic47 7y ago
    In what situation? If you predict everything correctly, you don't have to, but I was referring that you don't have to have everything designed upfront, since refactor is much easier and safer than in other languages. I wanted to make point that that #4 is not true.
    - ukj 7y ago
      Is that 1% not true or 99% not true? Amortizing the up-front cost of design, into a continuous cost of refactoring every time the requirements change doesn’t make the original claim false. You are still paying the price of rigidity.
youerbt 7y ago
> This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation. This is simply bs. Haskell is actually a language (that I know of) where, IMO, your initial choices matters least. And that's because it's gives you great refactoring experience.
- ukj 7y ago
  'Great refactoring experience' relative to what? An imperative language? Yeah right! I don't have to refactor extensible code.
  - youerbt 7y ago
    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.

by ukj 7y ago

mic47 7y ago

>Architecture is extremely sensitive to the initial choices due to isolation of side effects. Only if you choose to isolate all side effects from each other. Actually Haskell makes refactoring really easy, so you can adapt your implemention to changing requirements easily.

h91wka 7y ago
Why would I need to refactor anything in this situation in the first place?
- mic47 7y ago
  In what situation? If you predict everything correctly, you don't have to, but I was referring that you don't have to have everything designed upfront, since refactor is much easier and safer than in other languages. I wanted to make point that that #4 is not true.
  - ukj 7y ago
    Is that 1% not true or 99% not true? Amortizing the up-front cost of design, into a continuous cost of refactoring every time the requirements change doesn’t make the original claim false. You are still paying the price of rigidity.

youerbt 7y ago

> This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation. This is simply bs. Haskell is actually a language (that I know of) where, IMO, your initial choices matters least. And that's because it's gives you great refactoring experience.

ukj 7y ago
'Great refactoring experience' relative to what? An imperative language? Yeah right! I don't have to refactor extensible code.
- youerbt 7y ago
  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.