7 ms·

>Makes it pretty much impossible to understand code by just looking at a single file. This always made OOP so frustrating to me. You have to go look in tons of

• hutzlibu 3y ago
  Unless you had a nice UML diagramm. (But then you had to keep the diagramms in sync with the code)
  • rad_gruchalski 3y ago
    And someone invented BPML. So one can have diagrams and code!
• thom 3y ago
  Are there programming paradigms for which this isn’t the case?
  • Detrytus 3y ago
    Well, the functional programming promise is that output is a function (pun intended) of inputs, no side effects allowed, thus you can understand any given function by reading only its code, no additional context required.
    • carlmr 3y ago
      I find if you combine this with a strong type system like in F# the promise is upheld. You need strong type guarantees on the parameters to make it easy to understand the behavior though.
    • uoaei 3y ago
      That's not a pun, that's just the definition of 'functional'.
    • thom 3y ago
      Sure, but that's still you having to go to lots of places to understand what individual functions do, which doesn't seem different to the original complaint about OOP.
  • ponderings 3y ago
    I at times still write spaghetti code. I switch to functional if the repetition justifies it. It can be quite beautiful. OT: I remember someone noting that he tried to have modular code with as little functionality per module but reached a point where searching for things took writing it. I sometimes ponder if it would be possible to create a DSL for every tiny niche part of each application. It would likewise depend on how awesome the documentation is and if you can even find it. I think LLM's could make both ideas viable. One would be able to find anything and figure out how it works. Could have a committee that judges how reusable your language extensions are and possibly grades you as a programmer with hints on how to improve. Writing the coffee machine DSL should give you bragging rights. A bit like languages nowadays accumulate new features. In an ideal world one would write functions, the repetition of those would be documented and spawn language features, repetition and usage of those would spawn features in the lower language in which the language is implemented which in turn would spawn machine instructions. All using real data in stead of a cultivated hunch or popularity contest. How many installs, how often does that part of the code run, how many cycles can we save globally.
    • thom 3y ago
      People don't want DSLs though. There's an enormous contingent of programmers these days who seem to object to literally any form of abstraction at all. They just want to see - imperatively - what something does from top to bottom.
• Retric 3y ago
  It’s possible to write OOP code where each object stands alone in its own file and just passes messages to other objects. Breaking things up is supposed to make things easier and it usually does.
  • commandlinefan 3y ago
    IME, most programmers just write procedural/imperative code using OO semantics rather than trying to write actual OOP code. If you're auto-generating your data classes and then writing static utility functions to operate on them, you're about as non-object oriented as you can get in an object oriented language.
    • Retric 3y ago
      In some ways I agree, but OO is best in moderation. The goal is to be a more useful programming technique and large class hierarchies filled with self contained objects end up being ridged when you want to change fundamental aspects of the project. The objects in OO really don’t need to have anything to do with the outside world. Projects where the majority of the code sits in a handful of giant bloated objects passing messages to each other tends to be quite flexible in practice. This works because rather than treating objects as consistent bundles of data and code throughout the program it’s often useful to think in terms of different contexts and then pass messages between those contexts. The advantage being you have fewer side effects to worry about when editing code, which is really the entire point of OO.
      • commandlinefan 3y ago
        > don’t need to have anything to do with the outside world I'd take that a step farther - if they do, that's probably a sign that you're taking things too literally. They probably _shouldn't_ have anything to do with the outside world. I die a little inside every time somebody introduces inheritance with that stupid Dog extends Animal example.
    • whstl 3y ago
      Yes. It pisses me off to no end that in most modern OOP schools there is a noticeable lack of "objects knowing about themselves", since a lot of focus is put on on reducing file LOC and splitting things mindlessly. I've seen developers claiming that "encapsulation" is just about "having getters/setters and private fields". But those getter/setters never get any custom implementation, they're just accessors for other classes. It's not really OOP anymore at this point. Classes are just records, or depositories of procedural subroutines. In the name of Single Responsibility Principle, there's a lot of breaking up classes in a way that forces encapsulation to be broken. A class doesn't always have to expose all its data!
• tjansen 3y ago
  Why is OOP different in that regard? Functional programs can also be spread over many files. The difference between FP/OOP and AOP is that with FP/OOP you know where to look. References outside the file you are currently looking at are usually declared at the top of the file. While with AOP there are no references in the files that are affected by AOP code.
  • whizzter 3y ago
    There is good and bad OOP, but I think a frequent problem that occurs in _older_ OOP is that when people try to abstract things you end up with functionality in base-classes that can possibly be overriden in subclasses but it might be complicated for reasons and carries extra data, the control flow going from parent->child->parent->child,etc in unfortunate cases (some of this can probably also be attributed to programmers caring more about memory consumption back in the days OOP was popular, leading to many cludgles). With a more functional style you often rather make consumers to pass a function with behavior modifying code, the upside is that the specialization is given from the call-site and that the callee can is more explicit about passing out things without needing to care about the specialization context, and often it's easy to compose specializations in this way in one place.
  • yakubin 3y ago
    Those are not the only options. Old-style procedural structural programming while avoiding unnecessary side effects, globals etc is just fine.
  • paulddraper 3y ago
    A couple reasons this happens in practice. OOP emphasizes encapsulation, decomposition, and dependency injection more aggressively than other paradigms. See SOLID. [1] While not necessarily bad, it does result in more "pieces." Java -- arguably holding the #1 spot for OOP popularity -- requires that each (public) class be in its own file. This results in a lot of files. [1] https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID