4 ms·

What else people can do - videos, articles - just to avoid learning a little bit of Java? Stop that laziness and learn OOP properly, you'll find a good use for

• chriswarbo 8y ago
  > Stop that laziness and learn OOP properly, you'll find a good use for it! This is my biggest problem with OOP: proponents keep shifting the goalposts to avoid criticisms. If someone follows OOP practice, and it doesn't work out perfectly, then they must not have been doing it "properly". Hence "OOP" becomes a nebulous term, encompassing a whole bunch of approaches (encapsulation, inheritance, subtype polymorphism, dynamic dispatch, SOLID, MVC, etc.) but if any of those don't work in some situation then they mysteriously don't count as 'proper OOP' in that case. I used to be very deep down the OOP rabbit hole (oh the joys meta-object protocols!), but these days I tend to stick to functional programming. I wouldn't claim it's the best way to program, and there are different tools for different jobs, etc. but one thing I've taken to heart is that we should try to make the easy thing be the correct thing. An example of this is static type systems: it's possible to write correct code without types, but it's much easier to get things wrong. Type checking rules out a lot of those wrong things, which makes it more likely we'll do the correct thing (note: I'm not saying static types make things easier, I'm saying that the easiest thing to do in the presence of static types is usually more correct than the easiest thing to do when there are no types). Automated testing is another example, as is purity, effect systems, capability models, etc. Even the fact that Java forces us to write a class in a correctly-named file just for "hello world" is an example of making the path of least resistance more "correct" (although I disagree with Java's notion of what's "correct"). Even if we concede that these complainers aren't doing OOP "properly", that just means OOP is fraught with gotchas, misaligned incentives and lacks objectively checkable criteria. I wouldn't want to pursue any practice where earnest, researched attempts to follow it not only lead to the very problems that it claimed to avoid, but is met with advice to follow the practice "properly". Just look at how much of softwareengineering.stackexchange.com is bogged down in philosophical pontificating about the nature of OOP! As for your specific claim, after doing OOP in several languages for many years, professionally, academically and recreationally, I count Java among the worst (PHP is slightly worse). I could say that if you want to do OOP "properly" you should try Smalltalk, but that would be yet more philosophical snobbery (you should instead try Smalltalk because it's a great language ;) )
  • viach 8y ago
    > OOP is fraught with gotchas, misaligned incentives and lacks objectively checkable criteria Like, almost everything in programming these days (especially the frontend part)? I actually like how functional code looks like, especially ML dialects - OCaml, Haskell, F# What stopping me from trying to use these languages in prod is the lack of tooling (mostly refactoring), in the sense what Idea can offer. And when you have >3 people in a project with a language which has no mature refactoring tools, there is a problem then, a big one. Imho of course.
    • anonimito 8y ago
      Have you tried HIE/hlint for rrfactoring haskell code?
    • chriswarbo 8y ago
      > > OOP is fraught with gotchas, misaligned incentives and lacks objectively checkable criteria > Like, almost everything in programming these days (especially the frontend part)? Everything has problems; that doesn't mean everything is equally problematic. My point is that we should favour practices which are unambiguous and encourage objectively good things, and that OOP isn't either of those. W.r.t. functional programming, I wasn't trying to argue in favour of it specifically here. I write a lot of procedural code, and keep looking for opportunities to learn/apply logic programming ;)