As an English person I believe you are thinking of the whole of the UK as London. Lots of that sort of thing around there, not so much the rest of the place.
Population UK: 64.1 million
Population US: 318.9 million
So that is 1/5th the population of a near continental sized country. The UK may not be big but it is dense (Admittedly not as dense as some Asian countries).
For regular trips that is true, and great. For more urgent trips or trips where the date may be flexible you are kind of stuck paying that huge cost most the time.
I used to live in Cambridge and had a similar problem on my frequent visits to Newcastle which I couldn't pin a date down for.
Not defending this case of its use, but there is a time and place for 'goto'. Not many of them and people do use them for terrible things but in the right circumstance it is the right solution.
Only really posting this because I want to do my part to clear the 'goto' stigma that seems common in the younger programmers. It still exists because it can still do good ( sometimes :) )
There are no secure systems written in ANY language (to my knowledge).
At the end of the day all computers and systems can be broken. Using C/C++ might open up that up to being more likely when someone isn't thoughtful enough in the implementation. The trade off comes in when you want to risk the higher chance of security problems for the better performance.
This is just my opinion, I believe that we spend way too much time writing in these 'safe' languages at the cost of performance when it often isn't really needed and in the long run just adds to the bloat of our systems. This comes from my belief that if anyone is willing to spend the time and money to break a system they will. So why are we burdening our piggy banks with the same security as our bank vaults?
It is used for that exact memory control and access that this article demonizes so that we can have efficient and thought out systems.
When those systems aren't well thought out or secure you have security issues. C/C++ lets you build a wobbly treehouse _and_ a secure fortress. It is up to the developer which one is made...
Weirdly, UI interfaces are also a problem in the game world. Where we want to have a designer or artist design and implement something in a game in a fast way we often resort to using Scaleform[1]. It is flash based tool for games, within the industry it is notorious for how slow and inefficient it is. A simple UI element can often be more costly than a major in-game 3D object.
We are willing to pay this extra cost for these elements because they are often required to be quickly put together and then iterated on over a long period of time in a very dynamic and changing system. Some elements may be moved from Scaleform into a more native implementation but for the most part it is left to be slowly parsed and inefficiently rendered.
Basically, where we need fast changing interfaces that arent necessarily implemented by high skill programmers then we are going to take a performance hit to get the same level of visuals we could get if we had the time and manpower to approach it better.
Weirdly, UI interfaces are also a problem in the game world. Where we want to have a designer or artist design and implement something in a game in a fast way we often resort to using Scaleform[1]. It is flash based tool for games, within the industry it is notorious for how slow and inefficient it is. A simple UI element can often be more costly than a major in-game 3D object.
We are willing to pay this extra cost for these elements because they are often required to be quickly put together and then iterated on over a long period of time in a very dynamic and changing system. Some elements may be moved from Scaleform into a more native implementation but for the most part it is left to be slowly parsed and inefficiently rendered.
Basically, where we need fast changing interfaces that arent necessarily implemented by high skill programmers then we are going to take a performance hit to get the same level of visuals we could get if we had the time and manpower to approach it better.
There are a number of reasons this is not openly available. Just a few:
- It may lock the programmer into a specific CPU
- The CPU cache/pipeline is less generic than you might think. Making setting a standard way to change it from within a program problematic.
- Multiple programs may be running at the same time. Having the a program dictate cache behaviour would effect all running applications.
- Arbitrary changes to behaviour would have performance implications when the change is made. In a multiple application situation that could mean flipflopping behaviour.
Generally though the benefit of the manual control wouldn't be worth the cost/risk/loss of platform support for most applications as CPU behaviour is very good and it would probably be cheaper to just upgrade to a more expensive CPU than to spend the time on developing improvements to the algorithm.
In the rare case where you do need specific behaviour and it is worth while it would be worth speaking to the vendors rather than doing it yourself.
I have contacted the University organisations, my application was a little late so I had missed a lot of funding opportunities that go early but applied for anything that was available and spoke to my supervisor for departmental funding. Unfortunately, there isn't a lot going this year on that level due to changes in the system it seems.
The original plan has been to have enough saved to cover the very basic living costs and then small bar/shop job for anything extra. There is no way I could work my current job with full-time research on top, that for sure :)