4 ms·
The problem I've always had with these back-and-forths between various programming philosophies is that the very nature of the argument exposes the reason the a
by bussierem 6y ago
The problem I've always had with these back-and-forths between various programming philosophies is that the very nature of the argument exposes the reason the arguments don't work.
The most common (but not only) way each side argues its point is to take some contrived example and show how philosophy X does it well, and how philosophy Y does it terribly. These examples are often ranted about by the "Y" proponents because "it's a bad problem choice designed to make Y look bad".
Yes. It is. Because X and Y were not designed to solve the same problems. If you pick an example Y is good at, most of the time X will be bad at it. So if you're doing something like that, use Y. But if you're doing something X is good at, then pick X
Why would you intentionally shoot yourself in the foot to use a framework, language, philosophy, etc. that was never intended to be used for that thing when there's something that was? Stop arguing about who's better at what. X and Y are good at different things. That's why they're _different philosophies/languages/technologies_.
- acdha 6y agoThe other related observation I make is that our field suffers from dogmatic thinking. A methodology is a tool, not a holy calling which cannot be altered: if it's working for your team, it's good; if not, adjust to something which works better. The problems come in when someone reads some over-stated screed about design patterns, pure functional programming, etc. and then decides that they have to throw every other tool in the toolbox out, and follow The Right Way™ in every possible way even when they're spending most of their time on problems of their own creation rather than their job. The various philosophies being debated will change over time but that mindset is remarkably stable.
- PaulDavisThe1st 6y agoSo let's say I've decided to sit down and write a digital audio workstation. I've got to pick at least one programming language and at least one general programming style. Let's say I pick C++ and (somewhat by implication) a generally OOP style. Someone comes along and says "oh, you could do this much better with Haskell and functional programming". How can you argue that the comparison involves an "X and Y" that are not designed to solve the same problem? Advocates for languages and programming styles are generally doing so on the basis that there is a broad class of software development problems/projects that will benefit from the use of their preferred "X and Y". Sure, there are some DSLs that are clearly not intended to be compared with (say) C++. And there are some overall programming styles that clearly suite certain kinds of software much more than others (e.g. the absence of an event loop somewhat changes everything, as does high level distributed parallelism). But OOP isn't an example of such a thing.
- jancsika 6y ago> How can you argue that the comparison involves an "X and Y" that are not designed to solve the same problem? Because Y is Haskell and your project has soft-realtime scheduling constraints. But if Y were Rust, point taken.