2 ms·
Alright, so I write scientific computing software professionally and, candidly, I find it easier to write efficient software using functional languages than obj
by kxyvr 10y ago
Alright, so I write scientific computing software professionally and, candidly, I find it easier to write efficient software using functional languages than object oriented because of what the languages encourage. For example, say we were writing a PDE solver. Although we can abstract things lots of different ways, at the end of the day, we probably have a really big struct with a lot of different matrices and vectors in it, which constitutes the algorithm's state. The code then passes this state from routine to routine. Now, often, we want to just modify one element in this state and keep a copy around for this or that. In a language like C++, the most straightforward thing to do is use copy construction, but that copies every single item in the structure, which is expensive and unnecessary. Only one thing changed. Certainly, we could make everything in the structure a shared pointer, copy the structure, and then allocate new memory for the one item, which would fix the problem. In fact, this is what most people do. However, now we're doing a lot of memory management by hand, which is error prone, and, at the end of the day, I should be working on better algorithms not fixing memory problems. In a functional language, we typically have immutable data structures with a garbage collector. Or, more specifically, we have reasonable immutable data structures that can handle this for us. For example, in the same scenario above, if we use a language like OCaml and want to modify a single element of a record type, the language does not copy the entire record type. Rather, it creates a new record type with references pointing to the memory of the old one everywhere except for the one element we modified. It's fast. It's efficient. We don't have to do this memory management ourselves.
Technically, I can write efficient code in either OO languages or functional languages, but I've found that for scientific software, meaning PDE solvers or optimization solvers, it's easier to do that in a functional language because the language encourages it. And, no, I'm not ignorant of the issues with writing low level dense linear algebra solvers. Those solvers I do write in C, then I link it out using a foreign function interface. Basically, the right tool for the right job.