"C# ... does a lot to railroad a programmer into a strongly OOP style that I am opposed to".
C# has functional capabilities as well. People write in it nowadays in a whole lot of different styles, including procedural, OO, functional, reactive.
Yes, the average developer uses it in an OO style, but it can do a lot more.
His argument against OOP makes it sound to me more like he's using OOP design patterns he doesn't like:
> I've spent most of my professional life working with classes and objects, but the more time I spend, the less I understand why you'd want to combine code and data so rigidly. I want to handle data as data and write the code that best fits a particular situation.
To put it simply, I find when using DTOs to store data, and following SOLID principles to write the rest of the code, I end up with quite clean code that provides a very nice separation of code and data, and that the right level of abstraction and loose coupling is exactly what allows me to write the code that best fits a particular situation. Granted, I don't write games, but I do write high-performance, highly-distributed multi-threaded applications where clean and fast connectivity between components is very important, and the ability to unit test basically everything is essential.
I guess to characterize OOP as 'combining code and data rigidly' is just so far off base from my style of OOP and my experience that I really can't identify with this as a reason to drop to C.
C# has functional capabilities as well. People write in it nowadays in a whole lot of different styles, including procedural, OO, functional, reactive.
Yes, the average developer uses it in an OO style, but it can do a lot more.