|
|
|
|
|
by hunterpayne
238 days ago
|
|
1) You are just pretending globals don't exist. Some problems are best modeled with global variables. Many are not, but when you need a global, you need a global. Forcing people to copy globals around because you won't admit this doesn't really help. 2) The main bottleneck in the vast majority of code is memory accesses (also called memory pressure). This is why most optimizing compilers don't really change the overall speed of code much these days. You are optimizing the wrong thing and in the process increasing the memory pressure. You can either as a field keep ignoring this 25 years after hardware changed to make memory accesses the bottleneck, or you can keep making fad languages that fewer and fewer people use. The second choice has the added cost of degrading how most devs view CS in general. PS The reason compiler writers like FP is because its a good way to write a compiler. This isn't true of almost anything else in software outside of the classroom. PPS I say this as someone currently writing a compiler in an FP language (for a unique use but its still a compiler) |
|
On the issue of copy-to-modify, if you can prove the old copy will never be used after you modify it, it's perfectly safe to implement it as an in place modification.
How do you prove/enforce this? With tracking ownership+lifetimes, like Rust does. In fact I'd argue that this makes Rust a functional language (no UD), and Rust isn't slow.