> but I suspect it would be a giant mash up of "if mobile do X else do Y," which isn't really "universal" in my mind

Well, it would link against different runtime libs, either static or dynamic, with the same interface - it would not bundle the binaries of all platforms (closer to Apple's use of the term Universal). Universal API is just cross-platform API, like Qt or anything similar.... except with support for a lot more disparate architectures... like FireMonkey. Or it is just better Java. Java, Qt (QtQuick is much closer), wxWidgets, LCL... all support multiple platforms. But they never really grew beyond the traditional x86/64 desktop/server (Java Mobile and Android Java were not seamless). This would just add mobile platforms to the mix with near complete API.

> They used to provide a library (skypekit) to do that but they decided to cut it off

Sure. I am not arguing about their business choices, just the technical ones. It is fairly easy to port the protocol code across different architectures. I used to use SIP, in preference to Skype. It worked well enough. So the problems are not technical, if they try.

You are not arguing against the Universal API. You are arguing against mobile specific UIs on the desktop.

Skype UI isn't that complicated to replicate. In mobile development, it is typical to maintain multiple UIs. That's not considered the main challenge. The original Skype was developed in Delphi. AFAIK, it still is. Delphi today supports multi-platform apps and UIs (with platform specific behaviors), with a UI designer tailor-made for that role, although it uses its own FireMonkey framework (not sure about the extent to which it supports Universal API) which supports both Desktop and Mobile apps. Skype UI was written on VCL. It is supposed to be fairly easy to port to FireMonkey. Modern frameworks, especially the modern mobile frameworks, make it quite easy to scale to a wide range of resolutions and devices, as long as devs keep that in mind. The Skype dev team might have gone with MS API since FireMonkey was perhaps not mature enough then.

I recall that the protocol code was written in C++, which I assume is portable C++, since Skype is already available on all platforms and I doubt that they have multiple code bases for protocol code. I am not sure how good the native code interop is in Universal API.

I don't use the Universal App API. So I have to ask. How is it worse than the model used by the Android and iOS API? Why wouldn't it be adequate for an app like Skype.

> Makes me wonder how I managed a 16 hour surgery the other day without ever getting bored or distracted (kind of hard to do when the patient is trying so hard to die on your table).

Clearly, without your patient's help in keeping you focused, you would have gotten distracted and wandered away from the OP after seeing a squirrel in the window :-).

Seriously, you know enough Statistics to know that your circumstance does not make a case against the study in any way, even if it was a comparable task. Your surgery task is a compound, concurrently distributed team task. It is not anything like the candidate tasks under consideration in this study. You don't need to have special powers of concentration to not be distracted in a surgery (at least no more than passing boards).

> in a state were Asians and blacks make up a similar portion of the population.

A quick peek at Wikipedia says that Asians (14.9%) are over twice the population of African-Americans (7.2%) in California. Just nitpicking.

I mean the full Python stack (IPython notebook + Spyder with IPython, PyLab, Pandas, statsmodels).

For almost everything in stats, I prefer the RStudio experience. The flow feels much better, even though my Python is much better than my R. Machine Learning is one stats topic though, where I still prefer Python - I just like Scikit-learn.

If I was doing linear algebra directly, I would have preferred the Python stack with NumPy. PyLab stack is more for Matlab users than R users. On the stats side, Pandas and statsmodels are still not yet an R replacement for me. They are a great start though and seem to have gotten everything right so far.

I use both R and Python. R itself is actually quite nice and more efficient for interactive use, once you get used to it. For interactive exploration with statistics, I actually prefer it to Python (and I have been using Python for ~15 years). Lots of helper functions. Everything uses the DataFrame datastructure. Good, concise and consistent documentation.

Unless you are a R library dev, for most users, its best to see R as a shell for statistics, rather than a programming language. So its language horribleness does not matter much.

I use Python to process data and R to explore it. Once I settle on something, if I need to put it into a larger pipeline, I either find an implementation in Python or link R to Python via rpy2.

> A python statistics library with some funky C linkage to the R library would take over in milliseconds

That's what rpy2 is.

> there's nothing else out there that is even attempting to solve the same problems.

You mean move semantics? That would be the main innovation of Rust. C++ also has them now. Perhaps Rust has them better, but it would be inaccurate to say that no one is even attempting to solve these problems.

Yes, worked for me too. Thanks.

"intergrate video in interface" isn't working though. Had the same problem with nightlies too.

I do indeed prefer mplayer over VLC since the CPU utilization is better. However, my mplayer does not do VP9. VLC nightly was suggested and it worked. But I would like to switch back to mplayer as soon as I can.

I did update my ffmpeg. The one that comes with Trusty did not work with youtube-dl.

That worked. Thanks.

I am aware. .NET Native just removes some JIT costs and improves load times (60% is the claim). It does not make actual program execution much faster. I don't expect the benchmarks to change much. Although, MS CLR was probably a bit better in performance than the Mono implementation. Let's see how this code merge fares. There are free and commercial native compilers for Java. They don't help all that much. I imagine things to be similar. No idea about how good the disk and memory improvements will play out.

> Does it mean the video has been encoded in VP9 if the nerd stats say DASH in Flash?

Not all DASH streams are VP9. From what I have seen: The mp4 streams (DASH and non-DASH) are h264. webm DASH streams are VP9. webm non-DASH is VP8.

I use youtube-dl to download presentations from Youtube. I have been getting VP9 webms for months from Youtube. If you type youtube -F , you can see all the DASH webm streams, which are encoded by VP9. The non-DASH webms are VP8 videos. With youtube-dl, you can select the DASH video and audio streams and combine them with ffmpeg. The file sizes are indeed much better.

Short Test Video:
youtube-dl --prefer-ffmpeg -f 247+171 https://www.youtube.com/watch?...
39 secs of this 720p clip comes out to 5.6 MB. With H264, it would 10.8 MB.

The only problem I have is that I have to play them by dropping them in Firefox. I have not managed to get any of my desktop media players to get the codecs (Ubuntu 14.04). If any of you solved this, let me know.

> Both C# and C++ offer low level functionality

Not really. Can you write a device driver in C#? How about a plain DLL? CLR is a VM. Its CPU performance is OK (2-8 times slower than C).

http://benchmarksgame.alioth.d...

But programs written on it have memory requirements that are higher than ones written in plain systems languages. The runtime footprint on the disk is also massive. I don't think you can really make a case that C# is a low-level language. It is not that much more CPU efficient than Java. Mono performance is worse than Java.

http://benchmarksgame.alioth.d...

Of course, CLR is better than dynamic language aka scripting language runtimes. But that's about it.