McLaren? Deep 6 by Microsoft. Are these moves unnerving for developer base?

[Mike Gibson]

In this fast changing tech world, learning new things It's part of the job of a developer. I'm not a developer but I see the value of the new async interfaces for file access, http, etc. A non blocking UI is the essence of a touch device.

Non-blocking UI != Async. My programs do all sorts of background processing using the standard Win32 multithreading model. Win32 has the most sophisticated implementation of multithreading of any OS. Instead of taking advantage of that, MSFT threw it away and implemented the goofy Async model, which intertwines threading and UI code. It's a horrible design. And not only is it a terrible design, it also has horrible performance due to Async and the FileBroker. For example, simply enumerating files is orders-of-magnitude slower in WinRT than in Win32 (Win32 is 180 times faster). You might say, "so what, WinRT is fast enough". Not true, the MSDN forums are full of baffled devs trying to figure out why simply listing all the photos on a device takes so long. Win32 could enumerate them in 15 milliseconds while RT's lovely Async **** takes three seconds. That's a real-world impact ... now add in the requirement to actually touch the data in image file (e.g. get the photo size) and things slow to an absolute, unusable crawl in WinRT.

Implementing Winrt in Windows 7 probably is too costly. Maybe they could have made Windows 8 a free upgrade, but the OS got such a bad reputation that few would have taken the offer.

That's why MSFT should have simply added a native scalable UI API in Win32. MSFT needs to do only what's required, not go off on some idiotic "new paradigm" that screws all the existing Windows developers. They did the same back in my day with OS/2 and after it failed they fell back to Win16 (which is the equivalent to Win32 today) and had enormous success.

Microsoft bet everything in the success of the Surface and PCs with touchscreen. They really thought that the touch interface add a lot of value for Windows users, but sadly for them the public didn't agree.

Actually, adding quality touchscreen support in Windows is a good idea. The problem is that it wasn't added to Win32 (which only has limited support) but only in the critically limited and poorly implemented RT effort.

Final nail in the WinRT coffin? The fact that MSFT's own developers rejected it. Where is freaking WinRT Office??? It has been two years since the WinRT revolution and there's no WinRT Office available. The fact that the world's largest software company, with 90,000+ employees, couldn't manage to produce a sophisticated WinRT app in two years should tell you something.

Horrible design, horrible implementation ... yet Nadella is doubling down on "Universal Apps". MSFT is going to crash and burn big time in 5-10 years.

 

[rodan01]

Based on this comment I'm concluding that you aren't a software developer. Although we work on creating software because there is money to be made it isn't the only motivator. Good software requires developers who have a passion for what they're working on. It is that personal investment that drives developers to create software that is of high quality, innovative, and useful.

New APIs means being able to do more things... or do existing things in a more efficient manner. It's exciting to see if a current product can be enhanced and expanded. The availability of these new APIs flips the switch on thinking about new opportunities. I've stopped developing for any of Microsoft's mobile platforms because they talk a good game, but fall far short in their delivery. In the memorable words of Sweet Brown, "Ain't nobody got time for dat!"

Of course there are software mills that churn out basic, no-frills, uninspired apps. Those are the ones that aren't interested in new APIs. But those apps aren't the ones that grab customers' attention.

MS could add 100.000 new APIs but if a project has low roi in WP. It won't be developed.
I don't like developers that are passionate about the new APIs, because that's not the primary objective. The primary objective is to develop great software. APIs are just tools, you learn them to improve the quality of the app. I don't want someone that is productive only when there are new APIs, and bore and unproductive when the initial excitement vanish.

Although, there are many kind of developers, there are part time developers that have pet projects, hobbyist. For those the news of 4500 APIs could make a difference, because the economic factor is not as important in their motivation. But WP has an overpopulation of those.

 

[WillysJeepMan]

MS could add 100.000 new APIs but if a project has low roi in WP. It won't be developed.
I don't like developers that are passionate about the new APIs, because that's not the primary objective. The primary objective is to develop great software. APIs are just tools, you learn them to improve the quality of the app. I don't want someone that is productive only when there are new APIs, and bore and unproductive when the initial excitement vanish.

Although, there are many kind of developers, there are part time developers that have pet projects, hobbyist. For those the news of 4500 APIs could make a difference, because the economic factor is not as important in their motivation. But WP has an overpopulation of those.

If that's what you got out of what I posted... there's nothing left to say about it.

 

[Elitis]

You might be tired of people acting like Nokia is the only OEM for WP, but your fatigue doesn't change reality. You are free to count on rumor for other companies to produce WP devices, but at this point in time they aren't. Is the bar set so low that rumors are worthy to be counted as if they are reality?

The Samsung ATIV SE was rumored to be in production before it was announced. There are countless other phones that have been rumored to be in production or even leaked. I'm not saying every rumor will turn out to be true. I'm saying we've got a good chance to see a flagship device that isn't from Nokia. And seeing as you kind of lumped my two points into one category, rumor or not, we've still got other WP OEMs that have already produced something. HTC, Samsung, Xolo, Huawei, and a few others.

 

[rodan01]

If that's what you got out of what I posted... there's nothing left to say about it.

I read again trying to find a hidden gem in your post. Sorry, there is not much in it.



I don't think is a good quality if a developer get so excited and motivated by the new stuff. Of course you have to study the new stuff, but the motivation or excitement should be in delivering good software that solve the users needs. The best solution may or may not include the new APIs, but that shouldn't affect your productivity and your motivation.

 

[rodan01]

Non-blocking UI != Async. My programs do all sorts of background processing using the standard Win32 multithreading model. Win32 has the most sophisticated implementation of multithreading of any OS. Instead of taking advantage of that, MSFT threw it away and implemented the goofy Async model, which intertwines threading and UI code. It's a horrible design. And not only is it a terrible design, it also has horrible performance due to Async and the FileBroker. For example, simply enumerating files is orders-of-magnitude slower in WinRT than in Win32 (Win32 is 180 times faster). You might say, "so what, WinRT is fast enough". Not true, the MSDN forums are full of baffled devs trying to figure out why simply listing all the photos on a device takes so long. Win32 could enumerate them in 15 milliseconds while RT's lovely Async **** takes three seconds. That's a real-world impact ... now add in the requirement to actually touch the data in image file (e.g. get the photo size) and things slow to an absolute, unusable crawl in WinRT.


That's why MSFT should have simply added a native scalable UI API in Win32. MSFT needs to do only what's required, not go off on some idiotic "new paradigm" that screws all the existing Windows developers. They did the same back in my day with OS/2 and after it failed they fell back to Win16 (which is the equivalent to Win32 today) and had enormous success..

I like Task as a construct that abstracts an asynchronous call. It's cleaner than passing callbacks.


The async keyword in c# does an amazing job in simplifying the asynchronous calls, the callback spaghetti is over. So, to me those are good changes.


In winrt every API that takes more than 50ns (if I remember correctly) has to be async. The framework was developed from the ground up for touch devices that can't block the UI thread. In win32 it's optional, the developer decide when they use background tasks.


People generally repeat that developers shouldn't write complex multi-threading code because it's not cost effective. The solution in winrt goes in that direction.



Yep, winrt is here to stay. The last bit of information related to office and winrt, I think it was at build. Supposedly the office team was working with the winrt team to add new APIs to support desktop related features in vnext. Microsoft is standardizing in winrt

 

[Maitrikkataria]

If you're aware of those bits of information, then maybe It's a lack of the basic ability of dismissing inconsistent ideas. Because what you posted doesn't make sense.

API's are important, you cannot develop everything on your own. For example, if you hadn't had leap motion or MYO's API, you would be doing a monkey dance to develop them, probably charging a ton to your client or else shredding each and every penny of your pockets.

Believe me, if you want to keep an ecosystem health and viable, API's are important!

 

[Maitrikkataria]

Based on this comment I'm concluding that you aren't a software developer. Although we work on creating software because there is money to be made it isn't the only motivator. Good software requires developers who have a passion for what they're working on. It is that personal investment that drives developers to create software that is of high quality, innovative, and useful.

New APIs means being able to do more things... or do existing things in a more efficient manner. It's exciting to see if a current product can be enhanced and expanded. The availability of these new APIs flips the switch on thinking about new opportunities. I've stopped developing for any of Microsoft's mobile platforms because they talk a good game, but fall far short in their delivery. In the memorable words of Sweet Brown, "Ain't nobody got time for dat!"

Of course there are software mills that churn out basic, no-frills, uninspired apps. Those are the ones that aren't interested in new APIs. But those apps aren't the ones that grab customers' attention.

Yes, I agree with you. There are hardwares that needs API to integrate with Apps, I don't know how he intends to keep the economic app development while developing the entire API alongwith the application.

 

[Maitrikkataria]

Samsung makes a boatload of money with their Android devices and if they focus on another platform it's Tizen not Windows Phone.

True, I agreed with what you have said. To support you with statistics, please find the coverage of "Microsoft Now Builds Nearly 95% Of All Windows Phones" by the Verge. People are not trying to rationalize their thoughts on how much the WP's are actually made by Microsoft. I hope this drives the conversation in positive way. :smile:

 

[Mike Gibson]

I like Task as a construct that abstracts an asynchronous call. It's cleaner than passing callbacks. The async keyword in c# does an amazing job in simplifying the asynchronous calls, the callback spaghetti is over. So, to me those are good changes.

Multithreading in Win32 eliminated the callback problem 20+ years ago.

In winrt every API that takes more than 50ns (if I remember correctly) has to be async. The framework was developed from the ground up for touch devices that can't block the UI thread. In win32 it's optional, the developer decide when they use background tasks.

It's 50 ms (milliseconds). MSFT's own RT apps violate that rule, e.g. Solitaire routinely sputters when dragging and animating cards. So, what did the vaunted Async in WinRT buy us there?

People generally repeat that developers shouldn't write complex multi-threading code because it's not cost effective. The solution in winrt goes in that direction.

What do you think Async is? It's a method of multithreading that uses callbacks from the Async/Thread Pool manager. Async solves NONE of the problems intrinsic to multithreading in programs, e.g. protection of variables from simultaneous access, preventing users from starting the same operation again, aborting operations, etc. You can see devs running into these problems over and over again in WinRT on the MSDN forums.

Async solves none of the important problems, completely screws up simple things like file operations, nukes the use of widely available open source libraries, and has abysmal performance. What a huge mistake.

 

[rodan01]

Multithreading in Win32 eliminated the callback problem 20+ years ago.


It's 50 ms (milliseconds). MSFT's own RT apps violate that rule, e.g. Solitaire routinely sputters when dragging and animating cards. So, what did the vaunted Async in WinRT buy us there?


What do you think Async is? It's a method of multithreading that uses callbacks from the Async/Thread Pool manager. Async solves NONE of the problems intrinsic to multithreading in programs, e.g. protection of variables from simultaneous access, preventing users from starting the same operation again, aborting operations, etc. You can see devs running into these problems over and over again in WinRT on the MSDN forums.

Async solves none of the important problems, completely screws up simple things like file operations, nukes the use of widely available open source libraries, and has abysmal performance. What a huge mistake.

 

[wuiyang]

all i want is that windows phone SDK can have access to call log, that's all, and SMS too
and microsoft should have a pop up when an app is trying to get data from your phone