concise comparison between FP and OOP

that last assignment is pretty neat.

very good programming language in c

definitely a rewarding course

The best course on coursera!

Fantastic end to the series

Absolutely Brilliant Course

Best course of my life!

great course material

excellence experience

Really impressive!

very good course!

Great Adventure.

Fantastic course

Great course.

Excellent!

fruitful

exellent

great!!

Fab!!!

Great!

The last course in "Programming Languages" series. It introduces OOP and contrasts it with functional programming. Pros: - Good introduction to Ruby. Fast yet descriptive. - Good introduction to OOP with key ideas. - Very good comparison of OOP/Functional paradigm as ways to organize the same functionality differently (in opposite ways). - Good explanation of subtyping/generics. Cons: - Ruby may seem a bit too extreme choice for me here. The goal is clear: separate classes and types. However, from practical applications this confusion is often convenient (as was said in the course itself). - Bad examples and representation (a classic old way of teaching something: poor IDE and bad naming). The course illustrate concepts in silly examples (that's how the instructor calls them) with bad/arbitrary naming. As a result, the concept is clear, but it is hard to connect it to the real-world problem. I like examples with Point/Point3D/ColorPoint the most: the problem of multiple inheritance is the inferior since the bad "is-a" modelling is in the first place. This is just not how it is done in OOP. And exactly this bad modelling creates the diamond problem. Overall thoughts about the whole series of "Programming Languages": - the courses do their thing right: they illustrate core concepts of programming languages in different settings and teach you to see programming languages as sets of features and design decisions. The courses compare them and analyze how they work out in different situations. - the courses may not be as useful for practical development as for scientific R&D. However, it is good to know about learned concepts and to be able to see/use them in real development. - the course illustrates that in general functional paradigm is better and OOP is mostly suited for specific domains. However, for me the course implicitly illustrates that extremes are bad: 1. OOP has bad support of binary operations (by double dispatch). However, how often do the one face with such problems in real development? Usually, the domain is defined by business and is not so abstract (and don't forget about KISS). 2. Functional paradigm supports immutability. But this affects performance. And how often do the one care about performance? =) These focuses about specific problems favouring functional approach create a biased picture because we definitely care more about performance (but, of course, not all performance problems come from immutability). To sum up, there is a reason, why OOP is so popular. And there is a reason, why most programming languages supports both approaches in some way or another: just because one approach works better in one cases and other - in other cases. I think, this course lacks this message in a more explicit way.

Again, great course - I was a little bit shaky on the Ruby, but to be honest this was my first real dive into what OOP is "really like" (as far as I can tell). I was also impressed by how certain important concepts from Part B were also tested towards the end (e.g., streams). I also enjoyed the material on subtyping towards the end; it makes you actually want to be interested in implementing a small language like that someday. The only caveat I must mention (and what the missing star is due to) is that, I had a little trouble on my Linux machine getting a version of Tcl/Tk to work with my installation of Ruby, since Ruby doesn't accept the latest (packaged) version of Tcl/Tk. I also had trouble with Jruby, and in the end opted to manually install older versions of Tcl and Tk. But I think the Tetris experience was worth it :) That whole little sidetrack actually also turned me on to the possibility of how PLs use graphics libraries in general, so let's see where that leads...