>This just isn't true - for some algorithms we are simply not aware of any way to effectively parallelise. That just means we need new algorithms, different ha

>This just isn't true - for some algorithms we are simply not aware of any way to effectively parallelise. That just means we need new algorithms, different habits, and languages which make conncurency more accessible. The vast majority of research into algorithms and computer science in general over the past 75 yeas has focused on single threaded linear computation. I think the thing we can do right now is spin up threads as often as possible. It should be your default approach when writing a new function to consider how to make it functionally pure. If you can, spin that out into a new thread (Depending on the overhead in your language). Even If you can't make it functionally pure there still a good chance you can write it in a way that prevents a potential deadlock or race condition. My argument is basically this: 1) we will find more algorithms that are better at exploiting concurrent resources. 2) as programmers we need to change our default behavior from writing linear programs and then trying to make them take advantage of concurrent hardware to writing concurrent solutions at every level of application design by default from the ground up.