@steveroy I tend to distinguish between coding, hacking or even programming as words for the creative process; and software engineering as the term for the aspects of the craft that are more of an engineering discipline.

But there's no reason to assume engineering in general can't be creative, either. It tends to be, by definition, because it's about creating and changing things.

@natecull @jauntywunderkind420 @enkiv2 Early on I went from being introduced to OOP in school via C++/Java, to working with Perl and JavaScript in web apps.

I grew to really like Perl's approach where the language doesn't really stop you from digging into the details of a class; it's instead convention and good sense. Allowing that makes for power and danger: monkey patching is basically the interpreted language's answer to C's ability to shoot yourself in the foot if you choose.

@zensaiyuki @loke @natecull @jauntywunderkind420 @enkiv2 I think that's why REST and JSON took off so massively whereas CORBA and SOAP struggled. I remember how much the ideas of CORBA and SOAP seemed exciting and the reality was disappointing.

The reality is coupling isn't so great. We see how interfaces > inheritance, because interfaces are more like message passing.

The web thrived based on "here's some data, hope you know what to do with it!" so receivers could do whatever they wanted.

@zensaiyuki @loke @natecull @jauntywunderkind420 @enkiv2 This is why we see this OOP vs FP stuff I think: the original Smalltalk idea (I think???) was that data types weren't inherently coupled to a class. You just send the data and it decides whether to react and how.

By coupling methods to data suddenly you have all these "design patterns" to play twister around the way different classes want to interact with the data, versus in FP where a function can just operate on data if it knows how.