Yes, I agree, I have also felt that the branches/loops in the language sometimes feel like the remnants of the imperative style of Java from the old days. But, having said that, sometimes for example, when you're just learning about creating methods in Java (not adhering to strict clean code standards), branches/iterative statements help out understand the general flow of the method's task.
One could start with those, and move their way in by understanding that there are OO principles like SOLID, and design principles in place which help out when you're beginning to design the idea of a "method" in your mind/notebook/whiteboard, though it takes a lot of time to practice them and even more to master them.
I personally took my students through a journey, where we were introduced to the imperative style first, got comfortable with it, then moved on to the OO side of things, got comfortable, then worked our way forward while approaching the functional style at the end. It is not always an easy task, but if we consider other things as prerequisites, the functional approach seems fairly easy at the end.
Ah yes, the nomenclature certainly could have been better, I could not agree more there myself.
I've had great results with objects first.
People tend to have a hard time grasping OO after learning the procedural style (I had trouble back in the day). But the opposite is not so. So I always tried to go as OO first as possible. In fact, we start by teaching with a little OO robot rather than the old "Hello World" from the 70s and 80s. So OO is just natural to them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yes, I agree, I have also felt that the branches/loops in the language sometimes feel like the remnants of the imperative style of Java from the old days. But, having said that, sometimes for example, when you're just learning about creating methods in Java (not adhering to strict clean code standards), branches/iterative statements help out understand the general flow of the method's task.
One could start with those, and move their way in by understanding that there are OO principles like SOLID, and design principles in place which help out when you're beginning to design the idea of a "method" in your mind/notebook/whiteboard, though it takes a lot of time to practice them and even more to master them.
I personally took my students through a journey, where we were introduced to the imperative style first, got comfortable with it, then moved on to the OO side of things, got comfortable, then worked our way forward while approaching the functional style at the end. It is not always an easy task, but if we consider other things as prerequisites, the functional approach seems fairly easy at the end.
Ah yes, the nomenclature certainly could have been better, I could not agree more there myself.
I've had great results with objects first.
People tend to have a hard time grasping OO after learning the procedural style (I had trouble back in the day). But the opposite is not so. So I always tried to go as OO first as possible. In fact, we start by teaching with a little OO robot rather than the old "Hello World" from the 70s and 80s. So OO is just natural to them.