|
I can't read the article (the Thought Police doesn't allow me to see the Internet, only some sites) but I agree with the piece you reported.
Asynchronous code is necessary but it is tricky and requires a good understanding of the synchronous code. Otherwise you simply make mistakes on multiple threads contemporarily 
Geek code v 3.12
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
// No comment
|
|
|
|
|
den2k88 wrote: but it is tricky
About as tricky as cooking dinner, as long as you don't create a total mess.
As long as you have well defined areas where threads may overlap, keep those areas as small as possible, access those areas as sparingly as possible and use proper synchronization for every access, you are totally safe.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: About as tricky as cooking dinner
Quite tricky indeed, if you're not satisfied to just not poison yourself  To cook an averagely tasting, looking and smelling dinner one should have a healthy dose of experience, think just how it is easy to burn onions or undercook eggs the first times, or to make overcooked pasta for example.
The menaing is just that: before starting to think to exotic dishes make some experience in cooking a simple carbonara (which ain't so simple for beginners by the way).
Geek code v 3.12
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
// No comment
|
|
|
|
|
And then again, most people do it every day successfully.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Successfully as in "not poison", which is the equivalent of "it just works". And we're talking of grown-ups (=people with experience). If you take a person who never cooked or cooked very little you probably end up with a very bad dish (= software of poor quality).
That's the main point of what I'm saying: learn how to walk before attempting to run.
Geek code v 3.12
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
// No comment
|
|
|
|
|
Sure. I just can't hear anymore what kind of new languages and tools we need to solve this or that problem. So my version is: Learn how to walk before running off to the next new thing, only to discover that it still can't replace experience and some effort.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Yes, but they will be the women. The failures will be the men. Being a mere male, all my attempts to cook are quickly taken over by my better half and I am banished from the kitchen.
|
|
|
|
|
I don't know what we may need or not need, but I'm going to take another shot at writing my own UI. This time I'm going to use something that Mickeysoft can't pull away from under my feet, like OpenGL. Anyway, it's not going to get very far without letting I/O, message queues, rendering, data access and the actual applications run in separate threads.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: but I'm going to take another shot at writing my own UI
Did your first shot result in something one could take a look at?
Recursion: see Recursion.
|
|
|
|
|
Yes, I once posted some small video clips. I will try to find them.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I found one video, but it shows more of the graphics. The only UI object visible is the small menu in the upper left corner and it's not used here. I think there was another one, but I will have to look.
For now, it's more graphics and animation: Video #1[^]
Edit:
Here is another one. The resolution was reduced to a low value so that the text at least remained readable: Video #2[^]
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
modified 19-Mar-15 5:26am.
|
|
|
|
|
Ah! I always wanted to make a spaceship-game. Looks good! Thanks for digging it up
Recursion: see Recursion.
|
|
|
|
|
It actually was more of a browser game, just without the browser. Instead of sleepy web pages we had the 3D engine showing stuff of interest in the background and the UI in the foreground for the gameplay. It may also show what nice web applications can be done if you just forget about browsers and everything connected with them.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I would say, don't use guns unless you're an army guy or a security provider!
Similarly, don't use async programming model unless you know what you're doing. async programming can be made easy if you're able to understand, why WPF applications seem like to hang up when you're working with a (web of disk) resource, user would believe that the application has just hung up whereas it is waiting for the thread to be freed to update the GUI.
Synchronous programming is easy, I know... Just write the code and the machine would execute line-by-line. No problem right? But that is a good thing while programming a Console application. Client knows, he has to wait for the command to execute. But, if you're providing a graphical interface, you've already given the developers a pain in (well you know)... Thus using async model won't be painful enough for them. They will be able to handle.
Finally, everyone has their own point of view. I have never used async model in Console application, waiting doesn't cause a problem... That cursor keeps me notified that something is going on (unless I am asking for a value to be fetched; with a label above). But if I am going to develop a WPF application, I should be using async model for responsiveness of the graphical interface.
The one thing I like about the answer is the ASP.NET MVC solution, he is right! Browser would always wait for the time until the response has been made and sent back. Using async model there would be an idiotic action.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Yes, he's right that the individual browser will wait anyway, but using async/await in MVC is less about faster individual responses and more about a single server handling more connections.
Anyone who thinks comparing individual times of sync verses async will show faster async times doesn't understand async programming and hasn't compared the results. Async isn't free lunch - it comes with overhead. Responsiveness doesn't always mean faster either, it's about providing feedback to the user that "we're working on it" and it means your UI isn't stuck during the process.
|
|
|
|
|
Yes, you're right! Even responsive applications have to wait until the entire process has been completed; only the UI update thread hangs.
As far as ASP.NET MVC is concerned, in the new models and templates, you will find the ASP.NET team has themself used async/await keywords; in abundance.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
WPF applications don't need to by async to be responsive. If you want to let WPF do some graphic rendering, just call its dispatcher. No need to use the new Async/AWait stuff.
|
|
|
|
|
Actually async await in WPF is used while working with resource; internet or disk based, where it might consume a few time. Graphic rendering in WPF is based on DirectX so it won't be problem with performance. 
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
While I agree with the overall tone of his post (async/await in .NET is the new hammer making everything look like new nails), I disagree with the assertion that async coding is "new" or even "hard". The vast majority of .net programmers have been doing async coding since back in the days of .NET 1.0. Anyone who has handled events in .NET has probably done async coding. They may not have known it, and they may have done things wrong, which blew up in seemingly weird ways (and were written off as "cannot reproduce" tickets). But it's async coding.
Async coding in .NET is hard, yes. But async in general can be a breeze if you have the right framework for it. Example: async coding in Node is dead simple.
|
|
|
|
|
I have a GUI that allows the user to trigger processing that involves several web service requests, on two independent web services, and several email messages to subscribers. There is very little I can do to optimize the length of this processing anywhere close to the 100ms limit[^], so when the user clicks the "Force Processing" button, I await that processing and give the user back their UI. I think this is a bloody good reason for using asyn.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
|
|
|
|
|
I can't read the article either but good luck developing a desktop application that doesn't hard lock and go into a 'not responding' state every time someone triggers an event handler without implementing asynchronous multi threading.
|
|
|
|
|
Asynchronous programming is not needed if you have an advanced OS that can extract the parallelism from your executable and distribute that processing across all of its cores.
Otherwise, you need to learn how to do it. It will probably serve you better than trying to learn the newest sexy programming language that hides the multitasking with a "trust us, we know what you want to do".
It's really cool too.
|
|
|
|
|
If you ever get for a sec outside of website programming and try some multi-threading, there is no way you can do anything without asynchronous calls.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
If your goal is faster individual responses, I agree. I also agree with the point about reducing unnecessary complexity. However, he ignores the argument that using async/await in MVC is more about server resources than user wait time.
Given two servers, one written using sync the other async, each with a single connection the server written using sync code will respond faster. But as the number of connections increases the dynamic will change. The async server will return responses sooner as the sync server begins to slow down as unhandled requests queue up and it eventually begins refusing connections altogether long before the async one does.
He makes the argument that other tools are more worth your time. However, that it subjective. Will learning functional programming and re-writing my application in F# prove more valuable in the long run? Probably. But can I more quickly grasp the async model and implement it along my hot paths? More likely.
Does this mean I should implement async/await from the very start? Be careful of pre-optimization. My last project I wrote using async/await - it took me an afternoon of investigation to determine how to properly use it. It wasn't a significantly large project, but it's in use, under load and stable. I have never found a significant overhead in tracking down async bugs, but that's because I spent time learning how to handle async exceptions and properly implementing logging.
|
|
|
|
|
Naturally before jumping from one bandwagon to another simply because one voice in the crowd shouts "the other one is better", one should at least try to understand the concepts behind the instruments on the first bandwagon.
Of course it also follows that if one actually learned to play some music on the instruments with some modicum of proficiency before discarding them as ill-suited to composing a symphony then that would help.
Probably help even more if one had an idea of what the symphony was supposed to be about in the first place, but one can't ask for everything.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
