You see the saying “Don’t Fight The Framework” quite a lot. And for good reason, the framework was designed for a certain design pattern, or methodology which works well for its intended use. When forcing a framework to do something it wasn’t meant to be used for, you always end up in a world of hurt. For example, think about everyone you know who uses the Python Django framework: they either love it or absolutely hate it! Why the big divide? They’re fighting the framework! The same goes for Programming Languages. It doesn’t matter if you’re using Java, or Python, or Scala. Each language has its core strength and weakness. They find common programming patterns and makes their attempt at solving these common problems. They can be Object Oriented, Functional, Procedural, or even a mix. It helps to spend the time (trust me, it won’t take long) to figure out your working language’s nuances to achieve maximum usability, readability, and consistency.
When faced with a large project with a lot of unknowns (e.g. Programming Language, Framework, etc.) there tend to be two types of people: those who embrace the opportunity, and those who complain. I hear a lot of “We already know Java, let’s just do it in Java.” And that’s perfectly fine! Not everyone wants to learn about every language out there. But when you do, it’s important not to treat every language like Java. Don’t treat them all the same. For instance, Java likes to access properties with getter and setter methods prepended with “get” and “set”. Objective-C uses “set”, but prefers the property name as the getter. Swift, Groovy, and Scala for example automatically wrap the property in accessor methods and uses property syntax so it doesn’t look like you’re wrapping it in a method. Python either prefers accessing the property directly or wrapping it in an “@property” decorated method. The point is, there are many different ways of solving these common problems, and each language has its own way of doing it. Don’t fight the language please.