[raspberry1337]

Thank you for the response.

Yes I intend to learn and integrate design patterns and OO programming in general so that I can gain some confidence, and maybe later I can finally understand why my software development professor teachers hated this so much and teached us Haskell and Clojure instead :-)

[eddsh]

If you're anything like me, given enough time you wonder if all the 'fluff' of OO is necessary as you seem to be writing code to satisfy the programming style rather than the domain problem. You'll then try FP and find it has its own pitfalls - especially around how complex the code can get if you have a load of smart Haskell engineers - and suddenly they have the same problems ('fluff'). Apparently at some point I'll have a similar move to Lisp and discover how complex the code base can be with multiple engineers (I'm 8 or 9 years into this engineering journey myself!).

My current goal with software is to write this as simply as possible that a junior developer with 6 months experience could read my code and know how to modify it.

[hnfong]

Agree with the GP. In a sense even if design patterns are not such a great idea, there's so much code written with those patterns in mind (and classes/variables named accordingly) that it's beneficial to understand at least briefly what the names mean.

(That said, quoting Wikipedia, which I agree with also: "A primary criticism of Design Patterns is that its patterns are simply workarounds for missing features in C++". In particular, these days with more modern languages [and also the modernization of C++] some of the workarounds aren't that important any more)

As for why your professors prefer Haskell and Clojure... for some reason functional programming aligns with the way the stereotypical academia type person thinks. In practice, you should be using the best tool for the task, and learning various aspects of software engineering (as opposed to taking a side) should help you in the long run.