When buying an Android phone: Measure how many days it takes from the vulnerability report (at least publicly) until it's patched in phones already used by customers. Focus on phones more than 2 years old, since your phone will be that age someday. Then: Don't buy from unresponsive makers. I suspect that if a few buying guides included those numbers, some manufacturers and service providers would start paying attention.
It would be very helpful if there were a website that tracked cellphone support information, such as outstanding defects, and average defect correction time. I don't know of any such existing site, but suspect it would be a splendid opportunity to attract a large number of clicks.
While the turn-around time is impressive, it could not possibly have undergone extensive QA testing...
I understand that some bugs can have such OBVIOUS solutions - what could POSSIBLY go wrong with the fix???
And the list goes on....
The perpetually want a set of requirements. And they get upset if a new requirement is added later.
I agree that this is a good, if terse, summation of the basic conflict.
Poorly named, most "Computer Scientists" are NOT scientists. There is no application of the Scientific Method to solve unknown problems. Instead, they are Software Engineers trying to adapt known problems to solution by a versatile tool (the computer). No Science. Just Engineering.
I see software as a way to explore a space. Model it. Determine what more modeling is needed. You are constantly trying to do something that usually is beyond what is computationally possible so you have to figure out what approximation is going to work. What has to be done at full scale and what can be done at lower resolution. Mock up stuff.
This sounds like Science. Very indeterminate. And, not easily estimated. Business managers that employ Software Engineers demand estimates. And schedules. And progress reports.
Also, users of developed software often have - shall we say - hazy views of what is really needed. This can lead to disappointment when the software does not meet expectations.
Thus, to avoid being placed in a bad position, Software Engineers demand detailed requirements, so that they can make accurate estimates and avoid end user disappointment.
You live in a different world, pal... Not necessarily better or worse, but different.
Two problems solved.
(Three if the sharks have lasers.)
What could possibly go wrong?
Lots of people do comp sci and mathematics for the sake of themselves. There generally is a practical application, but it only tends to get discovered many years later. Can you tell me a practical application of the four color theorem?
I understand that. I did say "most", not "all". I am a big proponent of research into purely theoretical topics because they tend to pay big dividends in the future.
However, there are many more people applying mathematics and computer science to practical problems than doing theoretical work - as it should be.
I still maintain that the name of the game is solving practical problems, and a good computer science practitioner should be adept at applying his knowledge to different domains. That is what makes Computer Science important and relevant.
... just like Mathematics.
It means nothing by itself, except as a means to an end of solving practical problems.
That said, it makes all the sense in the world for most Computer Scientists to learn other domains of knowledge to apply to.
The more disciplines you are familiar with, the more adept you will be at applying your programming skills to solving real-world problems.
I have never seen anything fill up a vacuum so fast and still suck. -- Rob Pike, on X.