Do you have any proof of this? Because all you need to do to turn that sequential software into parallel software is run it in a web server. In fact, with emphasis on UI responsiveness on the frontend and scalability on the backend, I would be willing to bet the majority of programmers are writing parallel software. But I'm willing to let you prove me wrong with data.
If you're talking about single process cgi/wsgi/node-style-eventloops, the composition of sequential software is still effectively sequential if the data is disjoint. If you have non-disjoint data and a single process environment, then you do have to consider shared mutable information at some point in your architecture. This is mitigated by the fact that shared mutable information in the web domain is typically handled by a database or information store of some kind designed for concurrent use. I am going to make the somewhat bold claim that if you store shared, mutable data in the web application process you are doing it wrong (and for other reasons besides just this one).
I'm sorry, but I simply have no idea what you're talking about. I'm sure it's just me being an idiot, but I'm lost whenever we talk about "composition of sequential software with disjoint data". Could you explain this to me like I'm an 8-year-old?
Sorry, I'm a math person, I use math terms out of habit :)
Your initial statement was that if you take a single threaded program and run multiple instances of it in a single process (composition of sequential software), concurrency issues appear even for programmers working on sequential processes. I wanted to clarify that this is only the case when variables that are modified as part of execution are shared between them. If no variables modified as part of program execution are shared, this is equivalent to saying the data of the programs are disjoint.
To get down to web-level nitty gritty: If you modify global or module level variables, you will run into trouble. If you keep variable that will be modified in a scope specific to the request you are currently handling, and persist objects using an information store designed for concurrency, you will be fine. Avoiding mutable global variables and using specialized data stores have been best practices in coding for a long time.
Do you have any proof of this? Because all you need to do to turn that sequential software into parallel software is run it in a web server. In fact, with emphasis on UI responsiveness on the frontend and scalability on the backend, I would be willing to bet the majority of programmers are writing parallel software. But I'm willing to let you prove me wrong with data.