3 ms·

Well, I kind of am to be frank. OOP really mostly obscures an implementation and is often taught almost religiously as "the true one way". In the end, Exchange

Well, I kind of am to be frank. OOP really mostly obscures an implementation and is often taught almost religiously as "the true one way". In the end, Exchange is a stellar example of the obscured and therefore unfathomable implementation. You should really watch "Simple Made Easy" by Rich Hickey and think really hard about it. If you don't come to the conclusion that most software development could be way more sustainable in the long run would we use simpler tools and approaches instead of complecting everything especially with questionable OOP balast then maybe we have very different experiences.

FpUser 6y ago
>"OOP really mostly obscures an implementation " I see nothing wrong with OOP. It is convenient for many things. It is not a silver bullet though. Nothing is. Personally I do not adhere to any concept / programming paradigm. They're just tools. I use many. Depends on what I am doing. Generally one can take a tool and put it to good use while the other will fuck things up regardless.
- disgruntledphd2 6y ago
  I think OOP is useful where you need to have state and functions kept together. It's a little easier to have foobar.update(), rather than update(foobar, state). I started off mostly programming in R, so using mostly bare functions, but I have to admit that objects are really, really useful when you need to maintain state. Yes, you can do it with closures, but it's a little harder and a little uglier. That being said, the mutability that makes objects useful is also problematic in that you can end up with magically updating references without defensive copying.
  - FpUser 6y ago
    I feel that many of the theories concerning software developer's practice are concocted concocted mostly out of the author's desire to show that their way is the only one and capitalize on that. It is their own business. Not mine. I have bigger fish to fry and do not dwell on my screwdrivers.
  - kaliszad 6y ago
    The point is exactly, it is somewhat easier exactly in that one case when you have a single state _foobar_ somewhere and work with it all the time. In almost all other cases the second case is actually simpler. I don't know R and I don't really want to know it. For me, it doesn't seem to bring anything extra to the table that I couldn't do in Clojure or ClojureScript much more consistently and simply. If in my project, I have a number of transformation functions for my state, passing it around isn't a huge deal as it is just a nested map usually. It forces you to be very consistent and helps you as the project grows. Also, most of the functions are easily transferable between projects even when the state would have a very different structure. Of course the whole thing is a complicated topic and in some cases you want mutability and local state e.g. because the performance is a bit better. Usually, that involves a few simple transformations.
    - disgruntledphd2 6y ago
      See, this is because you don't deal with data and statistics on a regular basis, which I do. And if you figure out how to fit a generalised additive model in clojure with one line of code, please let me know :) So, in DS/stats you end up needing mutability because the datasets are really large, and the models take a long time to run, so copying is generally bad.

FpUser 6y ago

>"OOP really mostly obscures an implementation " I see nothing wrong with OOP. It is convenient for many things. It is not a silver bullet though. Nothing is. Personally I do not adhere to any concept / programming paradigm. They're just tools. I use many. Depends on what I am doing. Generally one can take a tool and put it to good use while the other will fuck things up regardless.

disgruntledphd2 6y ago
I think OOP is useful where you need to have state and functions kept together. It's a little easier to have foobar.update(), rather than update(foobar, state). I started off mostly programming in R, so using mostly bare functions, but I have to admit that objects are really, really useful when you need to maintain state. Yes, you can do it with closures, but it's a little harder and a little uglier. That being said, the mutability that makes objects useful is also problematic in that you can end up with magically updating references without defensive copying.
- FpUser 6y ago
  I feel that many of the theories concerning software developer's practice are concocted concocted mostly out of the author's desire to show that their way is the only one and capitalize on that. It is their own business. Not mine. I have bigger fish to fry and do not dwell on my screwdrivers.
- kaliszad 6y ago
  The point is exactly, it is somewhat easier exactly in that one case when you have a single state _foobar_ somewhere and work with it all the time. In almost all other cases the second case is actually simpler. I don't know R and I don't really want to know it. For me, it doesn't seem to bring anything extra to the table that I couldn't do in Clojure or ClojureScript much more consistently and simply. If in my project, I have a number of transformation functions for my state, passing it around isn't a huge deal as it is just a nested map usually. It forces you to be very consistent and helps you as the project grows. Also, most of the functions are easily transferable between projects even when the state would have a very different structure. Of course the whole thing is a complicated topic and in some cases you want mutability and local state e.g. because the performance is a bit better. Usually, that involves a few simple transformations.
  - disgruntledphd2 6y ago
    See, this is because you don't deal with data and statistics on a regular basis, which I do. And if you figure out how to fit a generalised additive model in clojure with one line of code, please let me know :) So, in DS/stats you end up needing mutability because the datasets are really large, and the models take a long time to run, so copying is generally bad.