Do we really need asynchronous programming? I don't think so.
-
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
-
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.
-
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 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 :D
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
-
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 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 fucking 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 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 :D
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 fucking 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 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 fucking 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. -
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 fucking 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
-
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 fucking 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.
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 fucking 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 fucking 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. -
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 fucking 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
-
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 fucking 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 fucking 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. -
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 fucking 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. -
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 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 shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
-
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
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.
-
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 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
-
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 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.
-
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
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.
-
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