Anyone can develop hardware for Windows (and until recently publish drivers with no interference from MS, that has changed and going forward Windows as a platform has and will become less open)
I think that's the kind of issue that some developers are concerned about.
Windows 10, with its automatic updates and push towards everything-as-a-service, gives Microsoft as much control of the distribution chain as it choses to claim, including retrospectively. Developing for Windows 10 is therefore no more future-proof than playing the Apple App Store approval lottery.
I don't think "the cloud" really has it right yet for very small companies with just a couple of servers and "the guy who also does IT", but in time it will.
One of my businesses is not a million miles past that point today, and I think perhaps you're understating how poor cloud offerings are today for that kind of business.
Every now and then someone suggests we go cloud-hosted instead, and I read around again, trying to work out why so many people seem to love the whole cloud idea. Usually the conclusion is that it would literally add an extra zero to our infrastructure costs and dramatically increase the complexity and number of potential failure points. This is all relative to our current modest set-up, using tried-and-tested servers and networking, with a similarly modest support contract with a local IT firm who know what they're doing and, in particular, provide 24/7 monitoring and support for the key systems in case of urgent problems.
There are numerous hosting or support options today for IT functions that are big enough to need real infrastructure and technical skills but not to have dedicated in-house IT staff. I see little reason any business in that sort of position would benefit from going with heavy cloud infrastructure like AWS, unless perhaps they really do need dramatically varying resource levels at different times.
I want to but a new PC laptop too, but it has to run Win7, because just like W8, I won't own another with shitware on it.
IIRC, Microsoft's policy on selling new PCs with Windows 7 preloaded is changing some time around now to prohibit it. Some manufacturers will supply with Windows 10 preinstalled and support downgrade rights, but it looks like that's as good as we're going to get until MS get the message.
While you may be correct according to the way our system is set up, the objection a lot of people have been raising is more about whether that system is in any meaningful sense democratic at this point.
May was elected by the Conservative MPs who in turn were elected by the people.
May wasn't elected by Conservative MPs, she was appointed after everyone else dropped out of the race due to the political infighting within her party. No-one actually voted for her to be PM at any point.
Those Conservative MPs were indeed elected by the people, but only by the people who voted Conservative in the constituencies where a Conservative MP won. That is actually a rather small proportion of the overall population.
When you're several degrees of separation from the general population actually voting directly to show support for you, I think it's a stretch to claim you have a democratic mandate, even if there's no suggestion that anyone broke any law or that the result isn't what our current system properly determined.
You might as well call the President of the US a dictator because they are elected by the Electoral College rather than by the people directly.
And on the rare occasions when the person who becomes POTUS did not win a majority of the popular vote, people do criticise the Electoral College for much the same reasons. But that is relatively rare and the vote is directly for who should become President, which makes it a very different situation on at least two counts to how the British Prime Minister is selected.
It's not true that May is forcing through policies without a mandate, parliament will have to vote on any new legislation.
True, but there is a great deal of power available to the executive officers of a government even without new primary legislation to support them, and in practice our "executive branch" is controlled by the PM.
May is here to stay whether you have an election or not, get over it.
That is almost certainly true, but at the same time it is a damning indictment both of the incompetence of our current official opposition and of our system of government itself.
This is an issue that I think we're going to have to address in the UK now. If you favour stronger political accountability and more democratic power then leaving the EU does remove one large layer of indirectly appointed authority that has probably been more influential in practice than the directed elected authority that came with it. I imagine that was part of the motivation for a lot of the Leave voters, even if the media do love to talk about immigration and racism a lot more. But leaving the EU is surely only a first step if that's your goal, and it will inevitably put greater emphasis on the accountability and transparency of our own national government.
Now that it's all going to be down to us, it could reignite the campaigns to reform our own national system of government as well. I wonder whether there will be renewed pressure on how our MPs are elected, because the last general election was even more disproportionate than usual in its popular-vote-to-MPs conversion. There's certainly a solid democratic argument for revisiting how the government is then formed: the coronation of a new PM and with them effectively a new government has happened twice in three Parliaments, and the middle one was a coalition whose policies were hammered out behind closed doors, so long gone are the days when the Prime Minister was merely a "first among equals" acknowledged by MPs by mutual consent and when voters were primarily choosing a constituency MP at general elections. Then we have the House of Lords, which has long been controversial.
On the one hand, I'm optimistic that whatever the pros and cons of Brexit itself, the current interest in how we are governed might lead to reviewing some of the more debatable aspects of our national system. On the other hand, the extremely controversial nature of Brexit may push some people the other way, favouring the devil they know rather than risking an uncertain future controlled by someone else. Apparently we have invoked the old saying about living in interesting times...
It seems your fundamental point about a pervasive void* in a language is that programmers should be disciplined enough to use language features correctly. I suppose it does always come down to that eventually. I just think a language could offer more than C does to help programmers achieve that. Idiomatic C code tends to use void* for other purposes as well, as a proxy for generics for example, and that shouldn't be necessary IMHO even in a systems programming language.
We're talking about what would be an improvement on C but still retain the flexibility that C has for systems programming.
One of my arguments is that C's raw malloc and free don't fit into the type system cleanly and instead rely on void*. I'm suggesting that there should be more strongly typed tools for manipulating dynamic storage, even if it's necessary to add special features to the language to support them. Many C-style languages have something broadly along the lines I'm talking about, and often they call it "new" and "delete" or something close to that.
I think I've realised where we're slightly talking at cross-purposes here. If you're writing a system-level memory allocator then you need some way to identify the address where some storage of interest starts. A void* is one way to represent that, and if I'm understanding you correctly, this is the sort of situation where you're saying it would be useful.
I agree, but what I'm saying is I don't think a language needs a general purpose void* just because of that. I think it's OK to include a distinct language feature with its own semantics that says put a value of type T at position p in the available memory, and give back a strongly typed reference to it or the language's equivalent (like the placement form of operator new in C++, for example).
Obviously you still need some way to represent those positions, which is necessarily going to vary depending on your architecture. I think it's OK for that type to have special semantics as well. You don't have to make the concept available throughout the entire program.
This is an example of a more general issue with designing a systems programming language. You have to somehow expose the essential hardware interactions, whether it's memory or interrupts or poking magic registers that are hardware-mapped in some way. However, IMHO you ideally want to isolate those very low level operations and wrap them in your normal programming model and type system as soon as possible. My objection to C is that a lot of these details leak, and that's how errors like miscasting or dereferencing null or invalid pointers tend to happen.
I think I understand what you're saying, but I also think it's only a problem if you insist that your "new" and "delete" functionality be provided in the language as functions like anything else. There's no rule that says a language has to be implemented that way. There's also no rule that says just because whatever you use to release dynamically allocated memory when you're done with it can operate on any type that you can dynamically allocate, any other function must be able to do so as well. I think it's OK for allocating and releasing dynamic storage to be special in this way. After all, it is in almost every other language, one way or another.
Much of the above abuse would get flagged by -Wconversion.
Some would, sure. But some things, such as weakly typed enumerations, are standard behaviour and don't tend to trigger warnings except maybe in Lint-style tools.
Good luck writing device driver code without [pointers], though.
I'm not saying you don't need explicit pointers. I'm saying you don't need, for example, those pointers to be nullable by default. I have done my share of embedded work, and I have yet to encounter a situation where accidentally dereferencing a null pointer was a good thing.
Most modern languages either aren't much more strongly typed than C.
I didn't say most modern languages are good, nor did I claim that most modern languages are suitable for systems programming. I don't believe either of those things to be true. In fact, if there's one recurring theme throughout my comments in this discussion, it has been that we are far too willing to put up with existing inferior languages, mostly because of momentum and non-technical issues. I believe that this is holding the industry back from creating and using better languages, even though we have vastly more experience about how to do that now than the creators of languages like C had at the time.
On the other hand, the more complex memory models don't come for free.
No, they don't. At the very least, they add a degree of complexity to the language.
We've long since learned how to avoid mismatched malloc-free pairs in most of the programming world, even if C hasn't. That's the easy stuff, and personally I think it's absurd that we're still using any programming languages that don't provide those kinds of tools one way or another. Today's problems are more about things like out-of-order execution and concurrency. Fine control of things like memory fences for synchronising access to shared or volatile (as in, externally influenced) storage is necessary to write safe code on modern architectures.
There have been several people in this discussion -- though I'm not saying you're one of them -- arguing that C is suitable for systems programming where other languages aren't because it's so transparent and predictable. But the reality is, there was a lot of very detailed discussion happening around the turn of the decade in the C and C++ worlds about these issues. Despite the resultant updates to the standards, plenty of code is still being written that doesn't fully take these issues into account, and plenty of legacy code is still being used that was written before these issues had been formally considered and standardised. So I don't really buy that whole simplicity/predictability argument, nor do I buy that the overheads of doing better are prohibitive. Doing better is necessary to write correct code on a lot of modern platforms, whether it's convenient or not.
They can be polymorphic. But if they are promiscuously so, it's just a void* by another name.
I'm not sure what you mean by promiscuous here. I'm just saying there's no problem, from a type theoretic point of view, with having allocation and release be type-specific so everything in between has a well-specified type that says what it actually is and requires explicit conversion to become anything else. There is no need to introduce a void* or its equivalent anywhere in this model.
I don't see your problem with self-hosting either. Everything actually useful has a type more specific than void*, and there is no reason such types can't be imposed throughout a self-hosted program, even at a systems programming level. If you disagree, can you describe a scenario where you don't believe this would be possible and say why?
"The only way I can lose this election is if I'm caught in bed with a dead girl or a live boy." -- Louisiana governor Edwin Edwards