|
|
One Night in Cardiff
Oops, sorry, reading phonetically!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
Star Trek IV: The Voyage Home?
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Came across this reply from the .NET Junkie[^ and he puts forward a compelling argument for why we should focus on writing better synchronous code before we try to write asynchronous code.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I am totally in sync with him.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
