4 ms·

I believe it's called multi paradigm languages - most I've used are like that (C++, Kotlin, JavaScript, Python, ...). The only dogmatic OOP languages I can thin

by fhd2 3y ago

I believe it's called multi paradigm languages - most I've used are like that (C++, Kotlin, JavaScript, Python, ...). The only dogmatic OOP languages I can think of are Java (where it is IMHO nastily done), Ruby and Smalltalk (in both of which I never felt the burden of OOP boilerplate). I think it's a Java problem, not an OOP problem.

kaba0 3y ago
A static method is basically a “standalone” function with a namespace only. You can static import it and do whatever you want. Java is a multi-paradigm language, and is absolutely on a different level of expressivity compared to Go. EDIT: Java is really not what people remember from 20 years ago. You can write as functional code as you wish stopping just before Monads. It’s type system is also a different league than Go’s. So it has OOP, imperative and FP.
pjmlp 3y ago
Since most early Java adopters were Smalltalk shops, I fail to see the difference. I used Smalltalk/V before Java came to be, by the way.
lastangryman 3y ago
Yes, good point. I worked in a lot in PHP though and interesting that a lot of the changes it has went through the last 15 years seem to have been "inspired" by Java. A lot of frameworks (Laravel, Symfony, Zend) seem to lean heavily on OOP style, and it's easy (or it was for me anyway) to fall in to the trap of everything must be a class and if not you are doing it wrong, even if the language does not require OOP. Design Patterns, Refactoring, Clean Code, it feels like a lot of my "industry journey" if you like was built on an assumption that everything started with OOP. Go, for me, was the first language I've used in a while that truly detached itself from all that dogma, not just in it's features but it's overall principles and ethos.
dagw 3y ago
Java's "problem" is more cultural and historical than technical. Modern Java has lots of support for functional and multi-paradigm programming. However most non-trivial Java codebases are quite old and don't take advantage of these newer features, plus most Java programmers were trained in the traditional Super-OOP style of Java programming and still program and advocate for that style of programming.

by fhd2 3y ago

kaba0 3y ago

A static method is basically a “standalone” function with a namespace only. You can static import it and do whatever you want. Java is a multi-paradigm language, and is absolutely on a different level of expressivity compared to Go. EDIT: Java is really not what people remember from 20 years ago. You can write as functional code as you wish stopping just before Monads. It’s type system is also a different league than Go’s. So it has OOP, imperative and FP.

pjmlp 3y ago

Since most early Java adopters were Smalltalk shops, I fail to see the difference. I used Smalltalk/V before Java came to be, by the way.

lastangryman 3y ago

Yes, good point. I worked in a lot in PHP though and interesting that a lot of the changes it has went through the last 15 years seem to have been "inspired" by Java. A lot of frameworks (Laravel, Symfony, Zend) seem to lean heavily on OOP style, and it's easy (or it was for me anyway) to fall in to the trap of everything must be a class and if not you are doing it wrong, even if the language does not require OOP. Design Patterns, Refactoring, Clean Code, it feels like a lot of my "industry journey" if you like was built on an assumption that everything started with OOP. Go, for me, was the first language I've used in a while that truly detached itself from all that dogma, not just in it's features but it's overall principles and ethos.

dagw 3y ago

Java's "problem" is more cultural and historical than technical. Modern Java has lots of support for functional and multi-paradigm programming. However most non-trivial Java codebases are quite old and don't take advantage of these newer features, plus most Java programmers were trained in the traditional Super-OOP style of Java programming and still program and advocate for that style of programming.