That aside though, does Microsoft really struggle to recruit these people? Is it really so hard to find people to sort out say WPF and keep it uptodate? With Microsoft's pay and benefits I can think of plenty of people that would more than happily do exactly that and wouldn't be competent enough to boot. Is Microsoft really looking to hire people like that? I believe most people would assume that Microsoft would be inundated with people with that sort of skillset, and so have simply never bothered to look to apply.
I can't speak specifically for WPF, not knowing that team closely. But there are two points. First, it does actually have a team (again!), and they are actually doing things. The real problem is that they have a lot of accumulated work from the period when it was neglected, and a lot of it is the rather unglamorous stuff like bug fixing, perf improvements, and supporting the more recent underlying tech (to remind, the existing renderer still uses D3D9, which becomes more of a problem as new drivers focus their primary support to D3D10+, and ship more bugs in D3D9, especially for patterns of usage that aren't similar to what games do).
I think that very long-term, the bet is still on the WinRT stuff, which should be more palatable now that these apps can actually run in a window rather than fullscreen, and sandbox restrictions have been significantly relaxed. Obviously, the prerequisite here is widespread adoption of Win10+, so it'll take quite a while longer.
But whatever option we take, we need to make it possible to compile Lua to bytecode, or make it run on the DLR. All projects to date seem pretty shite on this front (unless something has changed since I last looked), and whilst I recognise it'd be incredibly time consuming I do have the time and budget to pursue this (and even open it up as an open source project). This isn't too dissimilar to the sort of work you're doing, although our needs are much more basic. Do you have any overall advice, or decent references for implementing languages on the.NET platform? resources seem few and far between and even a brief MSDN article on the topic seems to have vanished (and was grossly out of date anyway) or is this one of those things that you really just have to dive in and learn through trial and error? Overall programming language design and compiler design is less of an issue (I've been working my way through programming language pragmatics on and off for some time now anyway).
For DLR, I don't think there are any really good docs. There's the existing implementations, and there are people around who made them who are basically the sole experts in that area, like Jim Hugunin; but unless you're one of those guys, the learning curve is rather steep. And because the demand for this stuff is not particularly high (which is why the original IronPython and IronRuby work had wound down), you see all those projects that get started on sheer enthusiasm, and then die because of the lack of interest before getting to anything stable enough.
So if you want to do it, it's either a lot of trial and error, or finding and hiring one of those guys who know it.
Compiling to bytecode is, on balance, a step up in difficulty. The good thing is that CLR bytecode and runtime is fairly well documented by the ECMA spec (and then there's the version with MS-specific implementation detail commentaries). The bad thing is that it's pretty low-level when you're using it as a basis for a dynamic language like Lua, so you will need to build a lot of scaffolding on top, especially for the interop with.NET.
Also, the problem with the DLR approach is compatibility with the stock implementation. For example, you want to let them run Python scripts? That's great, but it's highly likely that they'll also want to use some popular Python packages at some point, and those packages are at least partially implemented in C - so you don't just need compatibility wit
Microsoft needs to calm the fuck down with all the hipster technologies it's desperate to support, because giving their devs free reign to work on whatever the fuck they want (or at least, that's how it appears) seems to mean that they no longer have anyone working on the things they need to work on.
I've heard this many times, but you need to understand one simple thing. Developers aren't just fungible resources to be arbitrarily assigned to projects. They have their own preferences, and the same guy that's doing X won't suddenly start doing Y if X is cut (I've seen people leave over such things before); and even if they do, there is a big difference in productivity between working on something you love, and working for a paycheck, no matter how big.
Then, of course, even ignoring personal interests, people have vastly different backgrounds and proficiencies. You can't take a guy who is, say, an expert in writing client-side JS code, and put him to work on the WPF low-level graphics layer (which is mostly C++) to optimize it; and the reverse is also true. Well, you can, but you're effectively wasting a valuable resource for very little gain elsewhere.
And in places as big as diverse as MS, people often acquire very specific, narrow experience that is rare and valuable, but nearly useless elsewhere. For example, I'm a debugger guy - I wrote two dynamic language debuggers (for Python and now for R) from scratch pretty much all by myself, and have maintained and significantly contributed to two others (another one for Python, and Node.js). Give me another language, or another platform to target, and I'll crank one out in record time. Something tangentially related to that area - basically anything involving deep understanding of programming languages, the corner cases of their specs and intricacies of their VMs etc - sure, no problem. But I have pretty much zero clue how web authentication and authorization works beyond using existing libraries on the most basic level, for example. Sure, I can learn it if need be, but it'll take a while to get to the level of implementing such things, and I won't be producing much value in the meantime.
So if you want to boost some tech, you need to somehow get more people with the specific background for that tech; and such people within the company are usually found on specific other projects, that may very well not be in the "fad of the day" category. And money is not usually as much of a problem as people - when it comes to the requisite level of experience, the market is undersupplied today in general, and it's the employees who shop around more so than the companies.
(Speaking of, if there's anyone around with good knowledge of.NET and/or C++ - both is even better - with some Linux background, and interested in working on Python tooling and/or a cloud-based highly scalabe IPython/Jupyter service, ping me.)
Thing is, when Romero left id, their games stopped being games and started being tech demos.
I don't know what exactly it was that he brought to the team, but it's clear that it was essential to the awesomeness that was Doom.
And, in any case, he's still a great map designer. Just looking at this map makes this evident - it got the very authentic Doom feel to it, and is enjoyable to play.
Well, in that sense it's not really just about languages, right?
As the old joke goes, to determine if someone is a good programmer or a bad programmer is to ask them if they can do something extremely complicated. A bad programmer will say that they can't do it. A good one will say that they can do it, they just don't know how yet.
It depends a lot on the language. If you know Java, you can be expected to pick up C# in matter of days, but something like Python might get some more time to adjust to, for example. And going from Java to, say, Lisp or Haskell, is a serious mental challenge, and that Java knowledge may well hinder you more than it'll help.
R is actually kinda similar, and in some ways worse. It looks reassuringly familiar with its C-like syntax, and in many ways it will even behave the same if you write code in C style (though you'll quickly get frustrated with the standard library being very counter-intuitive). But the resulting code will be extremely bad R code - mainly because it would be horribly slow. And writing it fast means writing it the "R way", which is very different from how you normally do things in Java or C++.
Also, under the hood, R is actually very much like Lisp, with a layer of syntactic sugar on top giving it that C-like appearance. But in truth, everything is a function call, literally - even assignments and function definitions themselves. Idiomatic R code, especially in the libraries, often uses that fact to great effect, but to someone coming from a C-style language the result is usually utterly incomprehensible.
The type system is also very alien. I mean, it's a language that doesn't even have a notion of scalar types - everything is a vector (or other kind of collection), it's just that some vectors only have 1 element, and most operators are vectorized. Which means that e.g. something as simple and familiar as if (a == 0)... can, and eventually will, fail with mysterious errors like "argument is of length zero" or produce incoherent results - because "a" was an empty or a multiple-element vector, and == got vectorized.
The attitude can actually go even further on some teams. On mine, we approach it as, "this should be open source unless there's a damn good reason for it not to, and even then we should first see if we can fix that reason".
Why? We mainly do developer tools (including Python and R Tools for Visual Studio, just to bring this back on topic). In 2015, if you want respect from the developer community, you have to be open source, and in a real way (i.e. not just dumping the code as an incomprehensible tarball); and this is doubly true for existing communities around open source languages and frameworks like Python and R.
To be fair, though, for Microsoft to be even considered in the same league as Google when it comes to taking open source seriously is a big change from even 5 years ago. So if your assessment is how you really feel about it, I think we (I am a developer at Microsoft, working on open source software) have made considerable progress.
Full disclosure: I am a developer on both PTVS and RTVS (different but intersecting subsets of the same team work on both).
So why has no one mentioned RStudio yet? We just seem to be talking R. This is pretty much a clone of RStudio so far, with *slightly* better code-completion.
And a license that is not Affero GPL v3.
I think you will find that there are other differences that you may find interesting and useful beyond that, though. The video is a very brief overview, and doesn't show everything in detail, but some things are already visible. For example, notice how at 1:15, the history brings up the entire multiline expression, that is editable as such (rather than scrolling through each individual line of it).
MS tools for open languages rarely give anything I can't get elsewhere, just the same stuff over their own tooling. I remember them pitching Python tools as if they invented the first IDE with code-completion for Python while I had been using tools with equivalent functionality for 10 years prior.
With respect to "first IDE with code completion" - I'm not aware of it having ever been pitched like that.
What it had been pitched like - and what was true - is that it's the IDE with the best code completion, especially on large volume of pure Python code (as opposed to C modules where all the completion data comes from doc comments anyway). Until it and PyCharm showed up, most Python IDEs were doing very basic completion based on function names and such.
The big difference we made was adding an analysis engine that actually keeps track of the flow of values throughout the source code, across module boundaries even; and tracking more than just classes, but also e.g. individual values of tuples and dicts. This enables good completion for many common dynamic patterns that conventional identifier-matching approach cannot handle. And because the flow goes both ways, you can, for example, call a function in one place of your program, and then when you're editing the function, you will see the types of arguments, and the corresponding members, based on all its call sites.
Have a look at this, and tell me which IDE that you've used 10 years ago could do it back then. Heck, most Python IDEs out there can't do it today! Code completion for a dynamic language is hard.
As far as "give anything I can't get elsewhere" - how about this?
In my opinion, if you're coming from a generic software development background, you will really prefer Python over R for pretty much anything that GP has listed. R is a very... quirky language, with an even quirkier standard library, and will quickly drive someone used to the familiarity and comfort of most mainstream languages nuts.
R is not quite in the same boat. Yes, it's a niche language, but it's a niche language with a niche that's actually different from regular software development. It's used for stuff like statistical modeling, data science and machine learning. And in those areas, it is dominant.
Nothing can be "desirable for Bitcoin" per se, since Bitcoin is not a person or entity, and doesn't have interests. Various persons and entities involved in Bitcoin have interests. You're basically just claiming that those who have interests different from yours aren't worthy of consideration. But neither you, nor anyone else individually is in a position to enforce this (albeit these DDoS attack shenanigans seem to be pretty clear in identifying which side is willing to stoop down all the way to activity that's both illegal and unethical to defend its interests).
When I followed the links in the referenced blog post, I've seen plenty of "emotionally charged rhetoric", but it was all coming from the anti-XT guys.
I am a complete outsider. Until today, I only had very vague knowledge of XT, and no understanding of the underlying problems. Having heard what either side had to say, I don't know who's right in a sense of what's better, but the XT guys are much more professional and level-headed about pitching their arguments.
Heck, even your post itself is a prime example of it. You keep repeating words like "shilling" and "spamming" over and over, in contexts that make them clear personal attacks on your opponents.
The next major hurdle is convincing people to actually use this. Regular users who have no clue will just stick to FB messenger etc, which doesn't have end-to-end encryption and isn't going to get it. And people who understand how it works and care about their privacy would never use something like this.
The only way this would be even remotely useful is if governments actually start banning services with no backdoors. But if they do, I very much doubt they'll stop at "backdoor, but requires cooperation of other countries". They'll want their own. And, at the same time, because it's practically impossible to actually enforce anti-crypto laws, ban or no ban, no-backdoor encryption will continue to be used on "dark nets".
This is an attempt to offer a compromise that none of the sides involved are even remotely interested in.
The word "thermonuclear" in "thermonuclear bomb" comes from the term "thermonuclear fusion", which itself is a clarification of "nuclear fusion" (as opposed to "nuclear fission"). It's an unfortunate terminological quirk that by now is firmly entrenched and is a de facto standard. "Fission bomb" and "fusion bomb" would have been more accurate descriptions, but that ship has sailed.
If you keep ignoring candidates because they're "not likely to even be on the ballot", guess what? They won't be on the ballot. It's called a self-fulfilling prophecy.
If you're a registered Republican, vote Rand in the primaries. If you're a registered Democrat, vote Sanders. If it's possible in your state, register as both and vote both.
When was the last time US was "called upon when there is a major issue taking place" by governments that are actually in charge of the place in question?
You haven't addressed his actual question. Sure, the locals might not have TVs that would actually take full benefit of an 1080i broadcast, but we do. If DPRK really broadcast it in 1080i, all Western channels need to do is to rebroadcast that, and everyone can see the high-quality pic. If they have deliberately manipulated the video to look lower quality than it originally was, "why?" is a perfectly reasonable question to ask.
Effectively it means that clueless coders will keep copy-pasting crappy webkit-prefixed HTML from StackOverflow etc, it'll work for them, and they'll assume that it's the right way going forward, and will keep doing that. So in practice it just makes -webkit-* a de facto standard.
Slashdot Mirror
That aside though, does Microsoft really struggle to recruit these people? Is it really so hard to find people to sort out say WPF and keep it uptodate? With Microsoft's pay and benefits I can think of plenty of people that would more than happily do exactly that and wouldn't be competent enough to boot. Is Microsoft really looking to hire people like that? I believe most people would assume that Microsoft would be inundated with people with that sort of skillset, and so have simply never bothered to look to apply.
I can't speak specifically for WPF, not knowing that team closely. But there are two points. First, it does actually have a team (again!), and they are actually doing things. The real problem is that they have a lot of accumulated work from the period when it was neglected, and a lot of it is the rather unglamorous stuff like bug fixing, perf improvements, and supporting the more recent underlying tech (to remind, the existing renderer still uses D3D9, which becomes more of a problem as new drivers focus their primary support to D3D10+, and ship more bugs in D3D9, especially for patterns of usage that aren't similar to what games do).
I think that very long-term, the bet is still on the WinRT stuff, which should be more palatable now that these apps can actually run in a window rather than fullscreen, and sandbox restrictions have been significantly relaxed. Obviously, the prerequisite here is widespread adoption of Win10+, so it'll take quite a while longer.
But whatever option we take, we need to make it possible to compile Lua to bytecode, or make it run on the DLR. All projects to date seem pretty shite on this front (unless something has changed since I last looked), and whilst I recognise it'd be incredibly time consuming I do have the time and budget to pursue this (and even open it up as an open source project). This isn't too dissimilar to the sort of work you're doing, although our needs are much more basic. Do you have any overall advice, or decent references for implementing languages on the .NET platform? resources seem few and far between and even a brief MSDN article on the topic seems to have vanished (and was grossly out of date anyway) or is this one of those things that you really just have to dive in and learn through trial and error? Overall programming language design and compiler design is less of an issue (I've been working my way through programming language pragmatics on and off for some time now anyway).
For DLR, I don't think there are any really good docs. There's the existing implementations, and there are people around who made them who are basically the sole experts in that area, like Jim Hugunin; but unless you're one of those guys, the learning curve is rather steep. And because the demand for this stuff is not particularly high (which is why the original IronPython and IronRuby work had wound down), you see all those projects that get started on sheer enthusiasm, and then die because of the lack of interest before getting to anything stable enough.
So if you want to do it, it's either a lot of trial and error, or finding and hiring one of those guys who know it.
Compiling to bytecode is, on balance, a step up in difficulty. The good thing is that CLR bytecode and runtime is fairly well documented by the ECMA spec (and then there's the version with MS-specific implementation detail commentaries). The bad thing is that it's pretty low-level when you're using it as a basis for a dynamic language like Lua, so you will need to build a lot of scaffolding on top, especially for the interop with .NET.
Also, the problem with the DLR approach is compatibility with the stock implementation. For example, you want to let them run Python scripts? That's great, but it's highly likely that they'll also want to use some popular Python packages at some point, and those packages are at least partially implemented in C - so you don't just need compatibility wit
Microsoft needs to calm the fuck down with all the hipster technologies it's desperate to support, because giving their devs free reign to work on whatever the fuck they want (or at least, that's how it appears) seems to mean that they no longer have anyone working on the things they need to work on.
I've heard this many times, but you need to understand one simple thing. Developers aren't just fungible resources to be arbitrarily assigned to projects. They have their own preferences, and the same guy that's doing X won't suddenly start doing Y if X is cut (I've seen people leave over such things before); and even if they do, there is a big difference in productivity between working on something you love, and working for a paycheck, no matter how big.
Then, of course, even ignoring personal interests, people have vastly different backgrounds and proficiencies. You can't take a guy who is, say, an expert in writing client-side JS code, and put him to work on the WPF low-level graphics layer (which is mostly C++) to optimize it; and the reverse is also true. Well, you can, but you're effectively wasting a valuable resource for very little gain elsewhere.
And in places as big as diverse as MS, people often acquire very specific, narrow experience that is rare and valuable, but nearly useless elsewhere. For example, I'm a debugger guy - I wrote two dynamic language debuggers (for Python and now for R) from scratch pretty much all by myself, and have maintained and significantly contributed to two others (another one for Python, and Node.js). Give me another language, or another platform to target, and I'll crank one out in record time. Something tangentially related to that area - basically anything involving deep understanding of programming languages, the corner cases of their specs and intricacies of their VMs etc - sure, no problem. But I have pretty much zero clue how web authentication and authorization works beyond using existing libraries on the most basic level, for example. Sure, I can learn it if need be, but it'll take a while to get to the level of implementing such things, and I won't be producing much value in the meantime.
So if you want to boost some tech, you need to somehow get more people with the specific background for that tech; and such people within the company are usually found on specific other projects, that may very well not be in the "fad of the day" category. And money is not usually as much of a problem as people - when it comes to the requisite level of experience, the market is undersupplied today in general, and it's the employees who shop around more so than the companies.
(Speaking of, if there's anyone around with good knowledge of .NET and/or C++ - both is even better - with some Linux background, and interested in working on Python tooling and/or a cloud-based highly scalabe IPython/Jupyter service, ping me.)
Thing is, when Romero left id, their games stopped being games and started being tech demos.
I don't know what exactly it was that he brought to the team, but it's clear that it was essential to the awesomeness that was Doom.
And, in any case, he's still a great map designer. Just looking at this map makes this evident - it got the very authentic Doom feel to it, and is enjoyable to play.
Well, in that sense it's not really just about languages, right?
As the old joke goes, to determine if someone is a good programmer or a bad programmer is to ask them if they can do something extremely complicated. A bad programmer will say that they can't do it. A good one will say that they can do it, they just don't know how yet.
Which is an especially ironic comparison in light of e.g. this.
It depends a lot on the language. If you know Java, you can be expected to pick up C# in matter of days, but something like Python might get some more time to adjust to, for example. And going from Java to, say, Lisp or Haskell, is a serious mental challenge, and that Java knowledge may well hinder you more than it'll help.
R is actually kinda similar, and in some ways worse. It looks reassuringly familiar with its C-like syntax, and in many ways it will even behave the same if you write code in C style (though you'll quickly get frustrated with the standard library being very counter-intuitive). But the resulting code will be extremely bad R code - mainly because it would be horribly slow. And writing it fast means writing it the "R way", which is very different from how you normally do things in Java or C++.
Also, under the hood, R is actually very much like Lisp, with a layer of syntactic sugar on top giving it that C-like appearance. But in truth, everything is a function call, literally - even assignments and function definitions themselves. Idiomatic R code, especially in the libraries, often uses that fact to great effect, but to someone coming from a C-style language the result is usually utterly incomprehensible.
The type system is also very alien. I mean, it's a language that doesn't even have a notion of scalar types - everything is a vector (or other kind of collection), it's just that some vectors only have 1 element, and most operators are vectorized. Which means that e.g. something as simple and familiar as if (a == 0) ... can, and eventually will, fail with mysterious errors like "argument is of length zero" or produce incoherent results - because "a" was an empty or a multiple-element vector, and == got vectorized.
Also, R is GPL.
The attitude can actually go even further on some teams. On mine, we approach it as, "this should be open source unless there's a damn good reason for it not to, and even then we should first see if we can fix that reason".
Why? We mainly do developer tools (including Python and R Tools for Visual Studio, just to bring this back on topic). In 2015, if you want respect from the developer community, you have to be open source, and in a real way (i.e. not just dumping the code as an incomprehensible tarball); and this is doubly true for existing communities around open source languages and frameworks like Python and R.
To be fair, though, for Microsoft to be even considered in the same league as Google when it comes to taking open source seriously is a big change from even 5 years ago. So if your assessment is how you really feel about it, I think we (I am a developer at Microsoft, working on open source software) have made considerable progress.
Full disclosure: I am a developer on both PTVS and RTVS (different but intersecting subsets of the same team work on both).
So why has no one mentioned RStudio yet? We just seem to be talking R. This is pretty much a clone of RStudio so far, with *slightly* better code-completion.
And a license that is not Affero GPL v3.
I think you will find that there are other differences that you may find interesting and useful beyond that, though. The video is a very brief overview, and doesn't show everything in detail, but some things are already visible. For example, notice how at 1:15, the history brings up the entire multiline expression, that is editable as such (rather than scrolling through each individual line of it).
MS tools for open languages rarely give anything I can't get elsewhere, just the same stuff over their own tooling. I remember them pitching Python tools as if they invented the first IDE with code-completion for Python while I had been using tools with equivalent functionality for 10 years prior.
With respect to "first IDE with code completion" - I'm not aware of it having ever been pitched like that.
What it had been pitched like - and what was true - is that it's the IDE with the best code completion, especially on large volume of pure Python code (as opposed to C modules where all the completion data comes from doc comments anyway). Until it and PyCharm showed up, most Python IDEs were doing very basic completion based on function names and such.
The big difference we made was adding an analysis engine that actually keeps track of the flow of values throughout the source code, across module boundaries even; and tracking more than just classes, but also e.g. individual values of tuples and dicts. This enables good completion for many common dynamic patterns that conventional identifier-matching approach cannot handle. And because the flow goes both ways, you can, for example, call a function in one place of your program, and then when you're editing the function, you will see the types of arguments, and the corresponding members, based on all its call sites.
Have a look at this, and tell me which IDE that you've used 10 years ago could do it back then. Heck, most Python IDEs out there can't do it today! Code completion for a dynamic language is hard.
As far as "give anything I can't get elsewhere" - how about this?
In my opinion, if you're coming from a generic software development background, you will really prefer Python over R for pretty much anything that GP has listed. R is a very... quirky language, with an even quirkier standard library, and will quickly drive someone used to the familiarity and comfort of most mainstream languages nuts.
R is not quite in the same boat. Yes, it's a niche language, but it's a niche language with a niche that's actually different from regular software development. It's used for stuff like statistical modeling, data science and machine learning. And in those areas, it is dominant.
Nothing can be "desirable for Bitcoin" per se, since Bitcoin is not a person or entity, and doesn't have interests. Various persons and entities involved in Bitcoin have interests. You're basically just claiming that those who have interests different from yours aren't worthy of consideration. But neither you, nor anyone else individually is in a position to enforce this (albeit these DDoS attack shenanigans seem to be pretty clear in identifying which side is willing to stoop down all the way to activity that's both illegal and unethical to defend its interests).
You're not in charge of deciding what Bitcoin market is or isn't.
When I followed the links in the referenced blog post, I've seen plenty of "emotionally charged rhetoric", but it was all coming from the anti-XT guys.
https://www.reddit.com/r/Bitco...
https://www.reddit.com/r/Bitco...
https://www.reddit.com/r/Bitco...
https://github.com/bitcoin-dot...
I am a complete outsider. Until today, I only had very vague knowledge of XT, and no understanding of the underlying problems. Having heard what either side had to say, I don't know who's right in a sense of what's better, but the XT guys are much more professional and level-headed about pitching their arguments.
Heck, even your post itself is a prime example of it. You keep repeating words like "shilling" and "spamming" over and over, in contexts that make them clear personal attacks on your opponents.
Node.js modules?
The next major hurdle is convincing people to actually use this. Regular users who have no clue will just stick to FB messenger etc, which doesn't have end-to-end encryption and isn't going to get it. And people who understand how it works and care about their privacy would never use something like this.
The only way this would be even remotely useful is if governments actually start banning services with no backdoors. But if they do, I very much doubt they'll stop at "backdoor, but requires cooperation of other countries". They'll want their own. And, at the same time, because it's practically impossible to actually enforce anti-crypto laws, ban or no ban, no-backdoor encryption will continue to be used on "dark nets".
This is an attempt to offer a compromise that none of the sides involved are even remotely interested in.
The word "thermonuclear" in "thermonuclear bomb" comes from the term "thermonuclear fusion", which itself is a clarification of "nuclear fusion" (as opposed to "nuclear fission"). It's an unfortunate terminological quirk that by now is firmly entrenched and is a de facto standard. "Fission bomb" and "fusion bomb" would have been more accurate descriptions, but that ship has sailed.
This assumes that for all of the actors involved, nuclear obliteration is the worst possible option.
It might not be a valid assumption.
If you keep ignoring candidates because they're "not likely to even be on the ballot", guess what? They won't be on the ballot. It's called a self-fulfilling prophecy.
If you're a registered Republican, vote Rand in the primaries. If you're a registered Democrat, vote Sanders. If it's possible in your state, register as both and vote both.
When was the last time US was "called upon when there is a major issue taking place" by governments that are actually in charge of the place in question?
You haven't addressed his actual question. Sure, the locals might not have TVs that would actually take full benefit of an 1080i broadcast, but we do. If DPRK really broadcast it in 1080i, all Western channels need to do is to rebroadcast that, and everyone can see the high-quality pic. If they have deliberately manipulated the video to look lower quality than it originally was, "why?" is a perfectly reasonable question to ask.
The reason why the web became such a mess back in late 90s - early 00s is precisely because everyone was afraid to "break the Internet".
Does -moz- work in other browsers?
Effectively it means that clueless coders will keep copy-pasting crappy webkit-prefixed HTML from StackOverflow etc, it'll work for them, and they'll assume that it's the right way going forward, and will keep doing that. So in practice it just makes -webkit-* a de facto standard.