What do people think of UWP?
-
Marc Clifton wrote:
bothering to even learn more about it.
Let me tell you what I learnt in my past 6 months, or literally-hair-pulling-ly-rough-experience, it works fine and in 2 different ways. 1. You don't use async/await at all. You perform all the operations synchronously. 2. You write every function call, with an await operator. That way, most of the errors (such as Illegal operation, Invalid state) etc would go away. I would go with the second one, but like you said, it still requires us to learn more about it. I built one of my application, 1.5 years ago, which had 0 async await applied, because I did not know anything. But, I was working on another application a few weeks back, and since I knew async/await, I mistakenly added a few function calls as awaited. After that, it forced me to make sure every call in the stack was awaited, otherwise, 1. Illegal state 2. Invalid operation 3. Infinite loop Were only a few of the problems to tackle and work on. I think, in the next update Microsoft should work on these things, to make sure asynchrony is managed by OS itself and even being a feature of language, stays as a pain of the kernel only.
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
Afzaal Ahmad Zeeshan wrote:
I think, in the next update Microsoft should work on these things, to make sure asynchrony is managed by OS itself and even being a feature of language, stays as a pain of the kernel only.
I'm not convinced this is reasonably possible. I assume when you say "asynchrony is managed by OS itself" you are saying the OS should re-use a blocking thread's time-slice? How would you maintain state then for the blocking code? If you save the stacks, registers, etc before loading the new code then you're still basically performing a context-switch with even more overhead. The OS/hardware is already both asynchronous and multi-threaded from its standpoint. The hardware has a specific number of cores ("threads") and the OS switches out kernel threads ("tasks") to make best use of them including suspending blocking kernel threads. Abstracting out these kernel threads into another thread/task pattern is of no concern to the OS and rightfully so. The language being asynchronous would be possible but I'm not convinced it would be a benefit. Multi-threaded applications might rely on the main thread being synchronous which would no longer be a guarantee. Just enabling asynchrony by default might be an alright idea. You could just wrap the return in a
Taskunder the covers. If the function doesn't useawaitthen it'll just run synchronously.public class Whatever
{
public async Task ReturnTwoSynchronously() => 2; //Synchronous currently, access to await if you want
public int ReturnTwoSynchronously2() => 2; //Make the above represented by this standard pattern. As long as await is not used to create asynchronous behavior it will run synchronously.
}At the end of the day though, is it worth the effort? My opinion - probably not.
-
The whole ms uwp concept is a huge waste of a lot of people's time. Like everything else they've produced over the last few years, they came up with it without even thinking about keeping their feet grounded in reality, and all they've done is take phenomenally uncreative steps (which they probably think are highly creative) in a direction that cannot possibly be the way to the future. What is currently being done by weChat and facebook is one of the potential roads to "universal" computer products. That much is obvious, because many of the roads in that direction are patently obvious -- it's just a matter of waiting to see who will get it all to come together. But that won't be ms. Their idea of "universal" is crippled by their new-found lack of vision and creativity. It's a joke, which will be swept under the carpet, within a couple of years (joining all the other dustballs they've previously hailed as the next great thing), and the people who suffer most because of this will be developers who invest their time, skills, and effort into it. Seriously, you'll do your career better by studying COBOL.
I wanna be a eunuchs developer! Pass me a bread knife!
Speaking of COBOL, if you know who Grace Hopper is, I was actually in her office in the basement of the Pentagon once. The fundamental design of COBOL is good; it was intended to be understood by non-programmers. Most other languages, like C/C++ and PHP, are too cryptic and peculiar.
-
If I post some code here and articles would people be interested in UWP? I have some file API's and sample code that could help people. To be honest, I like UWP file operations but they are slightly weird. At the same time have great ways to do chain folder/file creation operations which I like and you can create the simple Append to end of sub/function like before but its a little different then before. Note: 1. I understand peoples problems with windows 10 updates but I have not had any problems with my updates with the exception of office 2010 because its so old windows will not install them properly the first time. 2.If you install visual studio at all, remember to install the Hypervisor for windows first because it uses that to test windows phone apps and needs time to run before you install studio.
jeffery
To answer the question of what I think about UWP, I think that it is built upon legacy technology. It is my understanding that the async/await mess is partially the result of the limitations of the message loop. If someone can explain async/await in a manner that makes clear when we need to use it then that will be popular. For example the clipboard in UWP requires async/await in many places but everywhere else the clipboard does not require threads or waiting (except waiting on the user). I don't understand why UWP needs async/await so much except (1) the message loop for some reason and (2) it is in a separate environment that requires additional security beyond the classical Windows process. I think Java also has async/await; does it? Is it as confusing as UWP is as far as async/await? The requirements for UWP probably go beyond the current design of Windows. Probably Microsoft needs to write another operating system to support the requirements. IBM has developed many operating systems but Microsoft has designed, at most, two operating systems. IBM had an operating system they called the Event Driven Executive; it is probably not relevant here except that the concept of being event-driven is not new. In many ways, Microsoft's technology is behind that of half a century ago and UWP is weighed down by that.
-
To answer the question of what I think about UWP, I think that it is built upon legacy technology. It is my understanding that the async/await mess is partially the result of the limitations of the message loop. If someone can explain async/await in a manner that makes clear when we need to use it then that will be popular. For example the clipboard in UWP requires async/await in many places but everywhere else the clipboard does not require threads or waiting (except waiting on the user). I don't understand why UWP needs async/await so much except (1) the message loop for some reason and (2) it is in a separate environment that requires additional security beyond the classical Windows process. I think Java also has async/await; does it? Is it as confusing as UWP is as far as async/await? The requirements for UWP probably go beyond the current design of Windows. Probably Microsoft needs to write another operating system to support the requirements. IBM has developed many operating systems but Microsoft has designed, at most, two operating systems. IBM had an operating system they called the Event Driven Executive; it is probably not relevant here except that the concept of being event-driven is not new. In many ways, Microsoft's technology is behind that of half a century ago and UWP is weighed down by that.
Sam Hobbs wrote:
In many ways, Microsoft's technology is behind that of half a century ago and UWP is weighed down by that
LOL, reminds me back in my younger days [as an employee] was often required to attend microsoft presentations. I recall one in particular when they introduced "multithreading" (demo: one window set to crash, the other carries on.) (This demo of "brand new tech" was about 10 minutes into an after lunch presentation - at that point I shook my head and left - not back to the office but went home) It was something I knew was already 25+ years old (FFS I had a 'nix running on my own home pc). What sticks in my mind though is the room full of people oohed and aahed over that demo, and were still talking about it the next day back at work. so while true that ms never bring anything new, where they usually [too often] excel is in bringing these things to the market. usually excel as in: there are items even in android/iphone that ms did earlier (not first), .... but they lost the phone battle. (OT - rant: it was 100% their sucky interface that looked just like the same sucky interface on windows 8 (was that uwp 1.0?) that failed their phone. Today it's the win 10 uwp (2.0beta?) that is mostly responsible for hobbling win 10 adoption and killing pc sales; it will also [if not -has already-] wreck their next attempt at a phone. Yes some people like the look, but then again some people drive pink cars. nad's biggest fail is and always will be this insistence on keeping this fugly uwp.
Sin tack the any key okay
-
If I post some code here and articles would people be interested in UWP? I have some file API's and sample code that could help people. To be honest, I like UWP file operations but they are slightly weird. At the same time have great ways to do chain folder/file creation operations which I like and you can create the simple Append to end of sub/function like before but its a little different then before. Note: 1. I understand peoples problems with windows 10 updates but I have not had any problems with my updates with the exception of office 2010 because its so old windows will not install them properly the first time. 2.If you install visual studio at all, remember to install the Hypervisor for windows first because it uses that to test windows phone apps and needs time to run before you install studio.
jeffery
I am sure many people here would read your articles, and learn from your experiences ! The questions always on my mind are: 1. what does it offer me now, and in the future ? 2. what does it cost in terms of "learning curve," set-up, deployment ? 3. what resources are available to get oriented, and start developing ? 4. to what extent can current skills be re-used ? cheers, Bill
«When I consider my brief span of life, swallowed up in an eternity before and after, the little space I fill, and even can see, engulfed in the infinite immensity of spaces of which I am ignorant, and which know me not, I am frightened, and am astonished at being here rather than there; for there is no reason why here rather than there, now rather than then.» Blaise Pascal
-
Their is c/c++ programming forums too. That was a typo. But your a skeptic so try out UWP for yourself. Just remember about what happened to assembly language. All the years wasted to only be replaced with c/c++. However, I prefer vb.net for most apps because their is not a lot of difference to c# with the exception of games/hardcore apps which I prefer to go to c/c++. I found out with a little help on vb.net forums about how to call do p-invokes on device drivers. Only can be coded in c#? No. For the most part, you can code in native c/c++ for apps.
jeffery
jeffery c wrote:
Just remember about what happened to assembly language. All the years wasted to only be replaced with c/c++
OK, I'm voting for that as daftest question of the month. Maybe the year, but it's only April. What I can't tell is if you're: 0. A newbie, who's only seen a few shinies, so far, and doesn't know about the far-shiniers that are also available. 1. Just another ms wu-mao. Note: I don't need you to tell me; I'll see for myself.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Speaking of COBOL, if you know who Grace Hopper is, I was actually in her office in the basement of the Pentagon once. The fundamental design of COBOL is good; it was intended to be understood by non-programmers. Most other languages, like C/C++ and PHP, are too cryptic and peculiar.
Sam Hobbs wrote:
I was actually in her office in the basement of the Pentagon once.
That's an experience I'd swap for a lot. The best thing about COBOL is that it was optimised specifically for handling financial data, so it's blistering fast, when used in that field. The only language that can even come near to keeping up with it is C (with no plusses, sharps, etc.)
I wanna be a eunuchs developer! Pass me a bread knife!
-
The nuclear bomb launch systems AREN'T written in COBOL. The bomb simulation routines were written in JOVIAL, a variant of Algol. Most programs connected with the nuclear industry were written in Fortran. One just needs to look at the infrequent ads from Los Alamos National Laboratories and Livermore Labs to figure this out. COBOL figures prominently in systems for banks, stock trading, and large bureaucracies such as the IRS and the Social Security Administration. By the way, ADA was used when the government replaced the creaky Air Traffic Control system serving the USA. The IBM processors used for Air Traffic Control had not been manufactured for a decade or more (no, they were not the 360/370/390 processors) but I think the room-sized processors could have been replaced with small CMOS processors with the identical instruction set. Reading the ads in Washington Post (during the glory days of the Cold War), one could see that the ELINT (electronic intelligence gathering) systems and COM3 (Command, Control and Communication) systems were also written in assembly language for the unique processors produced by IBM. Just FYI.
-
I am sure many people here would read your articles, and learn from your experiences ! The questions always on my mind are: 1. what does it offer me now, and in the future ? 2. what does it cost in terms of "learning curve," set-up, deployment ? 3. what resources are available to get oriented, and start developing ? 4. to what extent can current skills be re-used ? cheers, Bill
«When I consider my brief span of life, swallowed up in an eternity before and after, the little space I fill, and even can see, engulfed in the infinite immensity of spaces of which I am ignorant, and which know me not, I am frightened, and am astonished at being here rather than there; for there is no reason why here rather than there, now rather than then.» Blaise Pascal
-
Afzaal Ahmad Zeeshan wrote:
I think, in the next update Microsoft should work on these things, to make sure asynchrony is managed by OS itself and even being a feature of language, stays as a pain of the kernel only.
I'm not convinced this is reasonably possible. I assume when you say "asynchrony is managed by OS itself" you are saying the OS should re-use a blocking thread's time-slice? How would you maintain state then for the blocking code? If you save the stacks, registers, etc before loading the new code then you're still basically performing a context-switch with even more overhead. The OS/hardware is already both asynchronous and multi-threaded from its standpoint. The hardware has a specific number of cores ("threads") and the OS switches out kernel threads ("tasks") to make best use of them including suspending blocking kernel threads. Abstracting out these kernel threads into another thread/task pattern is of no concern to the OS and rightfully so. The language being asynchronous would be possible but I'm not convinced it would be a benefit. Multi-threaded applications might rely on the main thread being synchronous which would no longer be a guarantee. Just enabling asynchrony by default might be an alright idea. You could just wrap the return in a
Taskunder the covers. If the function doesn't useawaitthen it'll just run synchronously.public class Whatever
{
public async Task ReturnTwoSynchronously() => 2; //Synchronous currently, access to await if you want
public int ReturnTwoSynchronously2() => 2; //Make the above represented by this standard pattern. As long as await is not used to create asynchronous behavior it will run synchronously.
}At the end of the day though, is it worth the effort? My opinion - probably not.
Oh, some good points. :thumbsup:
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
-
Sorry bill about the mess (flips his coin like Han solo in the cantana to bill), I will make up for up for it with an article here soon. Some people here must be older programmers to know what the nuclear systems are written in.
jeffery
NASA had to re-purpose its existing computers whenever a new satellite was launched. I know for a fact that these were programmed in assembler as that is the fastest language to execute programs in. The programs that processed the data streamed by the satellites were themselves written in assembler. In addition, real-time operating systems were written for machines that you could swear couldn't support such OS for lack of even minimal hardware support. All of this in the 1970s. Been there, done that.
-
Their is c/c++ programming forums too. That was a typo. But your a skeptic so try out UWP for yourself. Just remember about what happened to assembly language. All the years wasted to only be replaced with c/c++. However, I prefer vb.net for most apps because their is not a lot of difference to c# with the exception of games/hardcore apps which I prefer to go to c/c++. I found out with a little help on vb.net forums about how to call do p-invokes on device drivers. Only can be coded in c#? No. For the most part, you can code in native c/c++ for apps.
jeffery
jeffery c wrote:
Just remember about what happened to assembly language. All the years wasted to only be replaced with c/c++.
Could you elaborate on this? Or are you just using it in a poor attempt at reductio ad absurdum?
-
If I post some code here and articles would people be interested in UWP? I have some file API's and sample code that could help people. To be honest, I like UWP file operations but they are slightly weird. At the same time have great ways to do chain folder/file creation operations which I like and you can create the simple Append to end of sub/function like before but its a little different then before. Note: 1. I understand peoples problems with windows 10 updates but I have not had any problems with my updates with the exception of office 2010 because its so old windows will not install them properly the first time. 2.If you install visual studio at all, remember to install the Hypervisor for windows first because it uses that to test windows phone apps and needs time to run before you install studio.
jeffery
jeffery c wrote:
If I post some code here and articles would people be interested in UWP?
Yep, definitely. I've got an existing Xamarin app that runs on iOS and Droid, but I've been toying with the idea of creating a UWP app with it as well (for desktop/laptop machines). I don't know much about UWP (been a bit busy with porting my ASP.NET app over to .NET Core and coding the Xamarin apps) so it'll be interesting to see what it can do and whether it's suitable for my needs. :thumbsup:
Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.
-
If I post some code here and articles would people be interested in UWP? I have some file API's and sample code that could help people. To be honest, I like UWP file operations but they are slightly weird. At the same time have great ways to do chain folder/file creation operations which I like and you can create the simple Append to end of sub/function like before but its a little different then before. Note: 1. I understand peoples problems with windows 10 updates but I have not had any problems with my updates with the exception of office 2010 because its so old windows will not install them properly the first time. 2.If you install visual studio at all, remember to install the Hypervisor for windows first because it uses that to test windows phone apps and needs time to run before you install studio.
jeffery
It's not popular and is used by very few people/companies today. I had considered writing an article series on it last year and then decided against it. If you've got them drafted already, I'd say post them - don't expect a lot of feedback though, outside of casual 5 votes.
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
Marc Clifton wrote:
bothering to even learn more about it.
Let me tell you what I learnt in my past 6 months, or literally-hair-pulling-ly-rough-experience, it works fine and in 2 different ways. 1. You don't use async/await at all. You perform all the operations synchronously. 2. You write every function call, with an await operator. That way, most of the errors (such as Illegal operation, Invalid state) etc would go away. I would go with the second one, but like you said, it still requires us to learn more about it. I built one of my application, 1.5 years ago, which had 0 async await applied, because I did not know anything. But, I was working on another application a few weeks back, and since I knew async/await, I mistakenly added a few function calls as awaited. After that, it forced me to make sure every call in the stack was awaited, otherwise, 1. Illegal state 2. Invalid operation 3. Infinite loop Were only a few of the problems to tackle and work on. I think, in the next update Microsoft should work on these things, to make sure asynchrony is managed by OS itself and even being a feature of language, stays as a pain of the kernel only.
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
-
If I post some code here and articles would people be interested in UWP? I have some file API's and sample code that could help people. To be honest, I like UWP file operations but they are slightly weird. At the same time have great ways to do chain folder/file creation operations which I like and you can create the simple Append to end of sub/function like before but its a little different then before. Note: 1. I understand peoples problems with windows 10 updates but I have not had any problems with my updates with the exception of office 2010 because its so old windows will not install them properly the first time. 2.If you install visual studio at all, remember to install the Hypervisor for windows first because it uses that to test windows phone apps and needs time to run before you install studio.
jeffery
I like what Microsoft is trying to do with UWP apps. It's the only game in town if you want to run the same application on both your desktop and mobile device. The only problem is that there aren't enough Windows 10 Mobile users to drive the demand for UWP apps. If Windows 10 Mobile could get just 20% of the mobile market it would change everything.
-
jeffery c wrote:
Just remember about what happened to assembly language. All the years wasted to only be replaced with c/c++.
Could you elaborate on this? Or are you just using it in a poor attempt at reductio ad absurdum?
No, this is really referring to a difference of opinion not absurdity. Because a programming language being irrelevant is bases on overall demand and assembly language and/or fortran or any other language is used in specific scenarios. Those 70-80's languages are only used in nasa mainframes or any mainframe which are mostly irrelevant because of the training tine required to show people how to use one. Time sharing was a big problem because once an connection was established to the machine you could only have a handful of connections depending on the setup. This slowly changed but initially was not. Look up thee enaic computer.
jeffery
-
No, this is really referring to a difference of opinion not absurdity. Because a programming language being irrelevant is bases on overall demand and assembly language and/or fortran or any other language is used in specific scenarios. Those 70-80's languages are only used in nasa mainframes or any mainframe which are mostly irrelevant because of the training tine required to show people how to use one. Time sharing was a big problem because once an connection was established to the machine you could only have a handful of connections depending on the setup. This slowly changed but initially was not. Look up thee enaic computer.
jeffery
jeffery c wrote:
Those 70-80's languages are only used in nasa mainframes
I'm with you that some languages have become less popular, even to the point where they could be called esoteric. Though I'd draw a line at calling them irrelevant. Perhaps something like Fortran / Cobol tends to be used just (or rather mostly) in legacy systems yes - does that make them irrelevant? Assembly is still used though, quite a bit in fact, wherever you see hardware with extreme limits in resources you're sure to see at least some ASM codes (even in lieu of C), think stuff like a washing machine controller. Another place it gets used often is drivers. Also this new "fashion" of IoT is a prime place for ASM to help out where a higher level language just doesn't provide the full control. And then there's still those who go and optimise after a compiler's done its best. Not to mention, in some cases certain things are just impossible to do in the higher level language. Even in DotNet there are some features impossible to implement in C# without reverting to IL instead (i.e. DotNet's "ASM"). No matter the language which was used to produce the program, it's rather rare to see users being trained in a language instead of how to operate the program. Think e.g. something like SAP, 99% of all its training is done on end users explaining to them which value to put into what field and what button to click when - not anything about the language used to develop those forms. Why would you think that training on a "mainframe" is any different, especially for the operators? In fact it's probably more useful to train users on a higher level language (for stuff like scripts and automation) while leaving the lower level stuff to actual programmers.
-
If I post some code here and articles would people be interested in UWP? I have some file API's and sample code that could help people. To be honest, I like UWP file operations but they are slightly weird. At the same time have great ways to do chain folder/file creation operations which I like and you can create the simple Append to end of sub/function like before but its a little different then before. Note: 1. I understand peoples problems with windows 10 updates but I have not had any problems with my updates with the exception of office 2010 because its so old windows will not install them properly the first time. 2.If you install visual studio at all, remember to install the Hypervisor for windows first because it uses that to test windows phone apps and needs time to run before you install studio.
jeffery
With Windows Phone completely dead right now, my personal opinion of UWP / .NET Native is that it's a huge pain in the ass and not worth using at the moment except for very limited use cases. I'm personally of the opinion that WPF is a better solution for *almost* every application with many less "gotchas". As you've noted, you can still get it into the store with their converter. The thing that really kills UWP for me is lack of emit and code gen, which I use extensively. Reflection also becomes painful. The desktop to store app converter is pretty brilliant. It's great. I wish they would kill UWP / .NET Native and put the resources into coming up with a better solution that doesn't rely on native compilation. Android seems to be doing just fine without it.
Blog: [Code Index] By Mike Marynowski | Business: Singulink
-
jeffery c wrote:
Those 70-80's languages are only used in nasa mainframes
I'm with you that some languages have become less popular, even to the point where they could be called esoteric. Though I'd draw a line at calling them irrelevant. Perhaps something like Fortran / Cobol tends to be used just (or rather mostly) in legacy systems yes - does that make them irrelevant? Assembly is still used though, quite a bit in fact, wherever you see hardware with extreme limits in resources you're sure to see at least some ASM codes (even in lieu of C), think stuff like a washing machine controller. Another place it gets used often is drivers. Also this new "fashion" of IoT is a prime place for ASM to help out where a higher level language just doesn't provide the full control. And then there's still those who go and optimise after a compiler's done its best. Not to mention, in some cases certain things are just impossible to do in the higher level language. Even in DotNet there are some features impossible to implement in C# without reverting to IL instead (i.e. DotNet's "ASM"). No matter the language which was used to produce the program, it's rather rare to see users being trained in a language instead of how to operate the program. Think e.g. something like SAP, 99% of all its training is done on end users explaining to them which value to put into what field and what button to click when - not anything about the language used to develop those forms. Why would you think that training on a "mainframe" is any different, especially for the operators? In fact it's probably more useful to train users on a higher level language (for stuff like scripts and automation) while leaving the lower level stuff to actual programmers.
I level with you on most of this except most users barely know where the power button is on their computer. I worked in IT at a public K-12 school system and the multimedia/computer teachers were the only ones who had half a clue about them(I am from KY). The science teachers do not know how to program or even learn. High science class was the exception probably.
jeffery