OOP with Dependency Injection is just soykaf-oriented Functional Programming

Dependency Injection didn't solve OOP, it proves that Procedural/Functional Programming is THE correct approach to development. If you've used a language that relies on DI (Java SpringBoot, .NET, etc), you'll notice that you no longer really care about the class, rather you're more interested in the methods that the injected object provides. News flash, dependency injection turns the injected classes into Modules, and it's methods into exported functions. So, why are you still using a language that shoehorns functional programming through DI, instead of a proper language like Haskell, OCaml, C, Scheme, Clojure, etc?

>>34561 >If you've used a language that relies on DI (Java SpringBoot, .NET, etc), you'll notice that you no longer really care about the class, rather you're more interested in the methods that the injected object provides. News flash, dependency injection turns the injected classes into Modules, and it's methods into exported functions. Those are job languages, not hobby or passion project languages. Virtually all employed programmers have little to no say what languages are used in the businesses they work in, it's a top-down decision.

>>34563 >Job Languages Why would you willingly work for a company that uses bad technology. Unless you're a brainwashed drone who is willing to comply to a corporate hierarchy.

It shouldn't be that hard to incorporate Clojure into a Java project or F# into a C# project. I don't know any good resources for learning F# (or whether you can even use it on Linux) but there is Clojure for the Brave and True (https://www.braveclojure.com/introduction/).

>>34561 > you'll notice that you no longer really care about the class You still care about classes, OP got OOP and DI wrong. I recommend using it in a few real world projects, and then taking your conclusion before spilling comments.

>>34573 >Using it in a few real world projects I've used OOP languages for work for a long time, and DI in the last 3. This is what lead me to this conclusion. I mostly write OCaml, and Haskell now, but when I have to touch a OOP language that shoehorns modules with DI it is like a man trying to be a woman.

>>34570 Can't speak for others. In the case of my wife and I because we arrived at a dead end. No flats cheap enough to live in on welfare. I have two physical disabilities that would, in our soykafty society, make it exceedingly difficult to find another job. Recently managed to get that formally acknowledged, at least it makes it more difficult for my employer to fire me. So... yeah. Need to pay the bills and, by circumstance, resistance in that department had become nigh impossible. Sucks.

>>34580 Don't read into it much lain, that guy is just baiting with his "I don't understand why anyone take an easy job for lots of money unless they're brainwashed" take. This thread premise is silly and reeks of bait. "If you just recontextualize one part of a programming paradigm as something else, we can make a super weak argument that you're actually doing a different programming paradigm! OOP BTFO!"

>>34561 >So, why are you still using a language that shoehorns functional programming through DI, instead of a proper language like Haskell, OCaml, C, Scheme, Clojure, etc? Because we are learning Java at my university (I want to kill myself).

>>34597 i feel you so fuarrrking much jesus. it's painful. do the minimum and learn something fun to detox

OOP (and Java) are useful for software that doesn't change - finished products. Waterfall planned, whitepapered, board roomed products. Only sometimes OOP/Java is useful for unfinished products built by a **very** large number of people. Sometimes. But rarely. Otherwise it's an obstacle. No more, no less. OOP is in 9/10 of the cases the wrong tool for the job, except the remaining 1/10 cases have been over-represented for the past 5 decades... ... because the industry has been trying to resist economically caused changes for said past 5 decades.

>>34601 >finished products. Waterfall planned, whitepapered, board roomed products. Only software I know fits this description is sed, tr, grep, cat. All written in ansi c

>>34607 Procedural code is good too. At least you can reason about what's going on without some retard using "Interface Segregation" to hide the implementation from you. I think an Imperative Functional style is the truly correct approach to programming, with Procedural being the next best thing, followed by Pure Functional, Array Oriented, and so on. It's how far from the machine you go the deeper you move down the rabbit hole of OOP, instead it is wise to think with the machine rather than like the machine, that is where procedural and other imperative styles are nice. I know exactly what's happening. Even if my code is complex and layered, I can still walk through it without having to understand some hierarchy of objects, or dependency injection.

>>34598 Yep, I thought CS kids would be like me or even more, but the most techy guy I've met (excluding my friend who actually knows his stuff, but I knew him in high school) just talks about webdev APIs. I've even met some people who have never done programming before... why would you do CS if you've never done programming before? Java feels like a bad introduction language because doing basic things requires using concepts you don't understand. Beginners won't get to interact with concepts like memory, linking and compilation, and whatnot. Personally I'm trying to appreciate what I can about Java, after all, "the best language is the one you know" or whatever, but things annoy me, like the wrapper classes for primitives (int and Integer are two distinct types) and the lack of pointers (understandable but nonetheless annoying).

>>34664 The only interesting part of Java is the JVM. If you want to learn some cool stuff study its source code.

>>34670 I'd rather study the BEAM vm to be honest

>>34672 That's fair too, they're both impressive pieces of software.

>>34664 People fall into CS because both parrents and the school system hammer it into their heads that the only Correct career path is that of a corporate drone, and there aren't many jobs more corporate than maintaining a badly programmed Java codebase that's been in use since the late-90s.

>OOP with Dependency Injection is just soykaf-oriented Functional Programming The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

>>34570 Some people have bills to pay and soykafty corporate jobs are generally pretty stable and pay moderately well

>>34664 Why do wrapper classes annoy you? If anything they make the language more consistent. If you don't like OOP, I get that, but wrapper classes are not a difficult concept compared to most of C++. What's the alternative? Having no primitives? Also, why do you value pointers so much? For extremely performant code I suppose it's useful but ultimately when working with many people manual memory management becomes a bad idea, especially when eeking out performance isn't required. The vast majority of software is not embedded systems, it's B2B CRUD. In most cases using low level languages is just people trying to satisfy their own ego at the expense of the long term maintainability of the project, by programmers who are probably worse than you. >>34779 People fall into CS because every job pays like soykaf or is like kicking dead whales down the beach.

>>34779 >[...] there aren't many jobs more corporate than maintaining a badly programmed Java codebase that's been in use since the late-90s. lmao you damn sure have that right

>>34561 POOF! Prototypes: Objection-Orientation done right. http://fare.tunes.org/files/cs/poof.pdf

>>36341 To be 100% honest with you, I’ve never tried any functional lang except F#. With that said, static typing is the tedious part. I want to be able to talk about objects in the domain and what they do. I don’t want the constraint of needing to use only pure stateless functions to get in the way of that. And I want to make only the smallest possible change to the code base when what I’m modelling changes, or I learn something new.

>>36353 Functional code bases are a lot smaller than imperative ones. Making the smallest possible change is called monkey patching, and it's the reason you NEED a functional ruleset to hold your hand. Every single imperative code base becomes a mess that is a fact. Functional code bases on the other hand typically age fairly well, and are MUCH easier to refactor, since your interfaces are implicit.

>>34561 Oop equates to employment

>>38826 Occupation Oriented Programming is soul sucking. If you're in a situation where the engineers can't dictate their tools, then it's best to start looking for a job. Where developers are viewed as an expense rather than a value add they are often the first on the chopping block.

Just use Flows lmao >>34597 >>34598 Yes, you should learn kotlin instead. >>36335 So javascript isn't as terrible after all? >>36356 Depends on the project then whether one wants to rewrite the entire thing each time a change request comes up while deadlines and budgets are a thing. And hey, call me unenlightened all you want but it's the exception where the purely idealist approach wins out over the more pragmatic and stupid one. In the end users and managers don't give a damn about how elegant your code base is and OOP languages provide a good enough model to procedurally hack together the features they want with enough separation of concerns to divide the work up into discrete modules. That's why it's still job languages and will likely remain so.

>>38827 That's nice and all but people still need to live. Sometimes you have to go with the flow.

>>38828 Functional code bases can just as easily be cut up into modules, and I'd argue they lend themselves to that kind of division even better than OOP (*cough* inheritance *cough*). The real problem for functional code bases would be things like HOF, tail recursion, PAFs, and shared state avoidance melting people's brains if they aren't familiar with the concepts. Most people do not formally learn FP during school, and they are damn sure not going to spend time learning it once they've graduated.

I've gone on record saying that 90% of all object-oriented code is just procedural and functional programming reinvented from first principles. I think the existence of utility "classes" alone make a pretty convincing argument against OOP. In all seriousness, OO isn't inherently bad, but it's not well-suited to general-purpose programming. It came with a lot of good ideas, particularly in regards to polymorphism, but most of those ideas don't need traditional OO to work. Describing a problem in terms of objects, their relationships, and their interactions makes intuitive sense, and it fit with what Simula and Smalltalk, the languages generally credited with OO as we know it today, were trying to do. But in the Real World, most programs aren't about concrete Things interacting with other concrete Things; they're about abstract data structures and algorithms. When I write out swap(x, y) , for example, I don't care who's doing the swapping, just that a swap is performed.

>>38834 >go with the flow This guy gets it! Java's recent standardization of the Flow API has been actually not that bad. It provides a good deal of FP's advantages and you should check it out if you're stuck with an enterprise JVM job. >>38835 >you can just easily Sorry but I gotta stop you right there. While I agree on the advantages, having to force everything into that paradigm while needing to come up with quick hacky workarounds for garbage poorly documented APIs or having to deal with constantly changing requirements, remodeling everything into that perfect structure again is often not as simple. While basic division of concerns through interfaces often does the job and some ugly state preservation saves the day. Especially for state machines and view/scene trees OOP is a good tool. In FP you would have to (mis)use modules as quasi classes for the same thing. And classic inheritance is also very rarely used today. It's instead dependency inversion and delegation patterns. Kotlin offers this natively from the get go now and reduces pretty much all the boiler plate aside of feeling more OOP and less of a mess than Java. But definitely feel free to set up your projects in FP. I personally am trying to get proficiency in Elixir but I've already stumbled on instances where I'd rather have a basic for loop over some convoluted recursion scheme. Same reason I don't want to use Rust for everything unless it's a rewrite of existing code which is certain not to change specs any time soon while requiring a high level of both rigor and performance. You don't need granite when simple brick will do just fine. >>38838 Yes, I regard good OOP as code which basically acts as a scaffold for the procedural meat of the code and the handling of the RX, builder pattern or flow chains that its components provide. Imho that offers the best of all worlds, offering multi paradigm flexibility and choice. Which is important in commercial projects since there's rarely the luxury to adhere to a dogma of sometimes philosophical or academic nature. Oftentimes things just need to get stapled together but with the right principles it can still be quite robust and solid. But when ever you can, use Kotlin over Java. That's my corpo-wagie's two cents on this. But that said, use whatever you feel is the best tool for the job or passion project.

>>38838 >When I write out swap(x, y) , for example, I don't care who's doing the swapping Wrong. You care very much about who is doing the swapping. Is this a static function provided, or a dynamic one open for extension? Do you provide it, or does a library? If you use multiple libraries, which is it from? OOP is elegant because it abstracts over many of these things in a way that is obvious and simple. It tends to create code which is somewhat extensible, and generally allows requirements to be updated without changing a lot of intermediary code. OOP's failings are really just the duals of these advantages. Its simplicity makes it inexpressive, it's obviousness leads to a lack of thought, its extensibility creates over-generalisation, etc.

>>35135 Sorry it's been like a year, I dunno why I didn't get back to you >Why do wrapper classes annoy you? If anything they make the language more consistent. Today I agree with this. It wasn't a difficult concept, but I thought it was frustrating that we should need primitive wrappers in the first place. But there was no solid foundation for this than my feelings. >Also, why do you value pointers so much? Not having access to memory addresses made me confused on how I am supposed to achieve particular things. That probably happens to anyone who goes from C++ to Java though, I'm sure there's a Java way I just didn't know. Thankfully we use C++ from here on out, but I'm annoyed we used it in the first place when we will never touch it again.