|
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.
|
|
|
|
|
Well, I agree with going synchronous first, but sometimes you run into situations where that is just dumb. While going to school I was writing changes to a windows app and asked my teacher why I wasn't seeing any changes. This was a puzzle put up as a challenge on the school board.
You can't see any changes until your code is idle... OH!
In the mean time a fellow student came up with an estimate of 6 months to find a solution on the current machines. I felt that was BS, but I could also see what I was doing wasn't efficient and he might be right about that piece of code. Anyway I didn't finish the code, but I did write code that finished in 5 minutes, had several thousand solutions that I could view in the windows app while I'm chugging away to finish the code, and I was able to find several bugs in the logic. Left school, worked on it on my own, found/fixed the bugs, added performance changes, so now I have logic that finishes in 2 minutes with 5 times as many solutions and I am quite confident it is finding all the solutions, but no way to absolutely prove it.
I DO NOT want to sit there for two minutes with no visibility of progress being made. So, while it is running, I see a running total of solutions found, some statistics on how close to the end I am, dynamic interaction with the code so I can have the code slow down and show me the progress.
Now, how could I do that on a Windows app WITHOUT asynchronous programming?
I found a bug in a service app that was built to handle thousands of requests a second. It was built to run several threads solving different requests simultaneously. I didn't even question that. I did question the throttle to keep the thread count to a max amount when it really would go 2 times the step amount past the thread maximum.
IE, there are times when async isn't just good, but required. I agree, that doesn't mean it should be the first goto you use.
|
|
|
|
|
The second hand on your watch is actually the third one...
|
|
|
|
|
Only if you replaced it twice.
|
|
|
|
|
Zero-based array?!?!? 
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
