|
We just need to wait for the US election in November. After that covid will go away and all lives will stop mattering.
|
|
|
|
|
Only if you know who doesn’t win!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
My wife is retiring in a couple of weeks after 27 years with a casual dining chain in the US. This is a direct result of Covid. Anyone (in upper or middle management) near retirement age was offered a really good package. She was only 2 years from her planned retirement and the deal was too good to pass up...besides, if she had stayed, it would have meant more responsibilities (restaurants) for less pay.
As to the question at hand, this pandemic has already caused many dining establishments and bars to close, at least for now...the ones with deep pockets may survive but not without massive layoffs. In the meantime, fast food and delivery are thriving.
As the numbers of cases continue to rise in many parts of the country, including my area there is a new problem arising...people are scared to come to work as some staff have become infected. Now is not a good time to be in the restaurant business.
I don't see things getting back to normal until a vaccine is widely available...maybe by 2021 but at this point, nobody knows.
"Go forth into the source" - Neal Morse
|
|
|
|
|
I have a parser generator called Parsley[^] which I have not updated in a while.
One of the neat things it can do is link several grammars** into several different parsers, and then link the different parsers it generates together so they can use each other to perform sub-parses. There are a number of advantages to this, including the fact that you can disambiguate grammar constructs by factoring them out over multiple grammars - since the parsers each have their own parse table, you won't have duplicate entries which causing ambiguity.
But I just realized I could parallelize the code generation for it too wherein each different grammar crunching task runs its own CPU bound operation to create the parse tables. And it's easy.
** a grammar is a document that tells the parser how to parse something. Usually it's written in a variant of BNF or EBNF.
I came up with all of this during a conversation about schizoaffective disorder. My mind is really funny sometimes.
I think it helped that I've been doing so much async stuff lately.
Real programmers use butterflies
|
|
|
|
|
Interesting
Can you elaborate a little on how to decide when to activate one (or more) of
the (sub?) parsers?
Of course you can activate a number of parsers simaultaneuously on a given input (sub)string
Long, long time ago in one of the compilers we used a mix of bottom up and top down (recursive descent) parsers, is that (more or less) similar to what you are describing?
|
|
|
|
|
Member 12982558 wrote: Can you elaborate a little on how to decide when to activate one (or more) of
the (sub?) parsers?
The share a symbol table, so when you reference a symbol from a foreign grammar it invokes the subparser
like here's an excerpt of a grammar i wrote:
/ SlangStatement.xbnf
// This is the XBNF spec for Slang Statements (gplex version - unicode enabled)
// Slang is a CodeDOM compliant subset of C#
@import "SlangExpression.xbnf";
// Statements
// we use this with our skipped lists to get comments on to relevant nodes
Comments<abstract>; // { lineComment | blockComment }
Directives<abstract>; // { directive }
VariableDeclarationStatement= varType Identifier "=" Expression ";" | Type Identifier [ "=" Expression ] ";";
Here I bolded the import line which will cause this parser to reference the SlangExpression parser generated by SlangExpression.xbnf (a grammar like this one)
I also bolded all the foreign symbols. These invoke a subparse when encountered
Member 12982558 wrote: Of course you can activate a number of parsers simaultaneuously on a given input (sub)string
I think maybe I wasn't clear about where the parallelization opportunity is. It's in the generation of the parser source code from the grammars. That's what I can make parallel. It means faster dev cycles for the parser because it doesn't take as long to generate. ETA: but i could parallelize the backtracking. Not sure if I would gain or lose perf doing that though
Member 12982558 wrote: Long, long time ago in one of the compilers we used a mix of bottom up and top down (recursive descent) parsers, is that (more or less) similar to what you are describing?
It sounds like it. Here's I'm assuming your parsers call other parsers like the top-down delegates to the bottom-up for some things. If so, this is like that except it's all top down, not several different algorithms.
Real programmers use butterflies
|
|
|
|
|
What's the local consensus on Blazor WebAssembly technology?
Is it worth learning? Do you think it will become important?
Blazor | Build client web apps with C# | .NET[^]
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Coming from someone who got out of web development years ago, I haven't used it yet, but I've read quite a bit about webassembly, and my feeling is just from the buzz around the related tech like blazor is it's gaining momentum. I think it will entrench itself in the web as it gets more sophisticated.
If you want to be prepared, I'd say learn it. Otherwise focus on current web technology with an eye toward maybe learning it down the road.
That's my $0.02 not having programmed with it. Offered FWIW
Real programmers use butterflies
|
|
|
|
|
Thank you. I'm experimenting with it now and it seems pretty cool. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
It's cool but what about performance? Particularly when I tried it last, the time it took to download the WebAssembly pieces into the browser was, well, unacceptable. I do not tolerate "loading page" spinny's very well.
It's awesome to write C# instead of Javascript, but how well does it integrate with third party libraries? They make claims, I'd like to see real use-case examples.
Client/server code re-use is a great idea, but last time I checked, Blazor didn't support an implementation of the latest C# language. This might have changed?
I actually loathe ASP.NET, particularly the mixing of HTML and code, server-side "compiling" of HTML pages (ie Razor), etc.
When it comes to web development, I prefer lean, mean, and performant. If that means I have to code in (preferably) TypeScript, great. It also means I am very very careful about what bloatware frameworks and libraries I add to my web applications. At the moment, Blazor is cool tech but I would never use it for a production environment. That's not Blazor's fault, I have the same attitude toward many server-side and client-side frameworks/libraries.
|
|
|
|
|
Thank you for that perspective.
As far as integrating with third party libraries, they say it supports "javascript interop" which I guess is a kind of P/Invoke for javascript.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I wonder if you might have mistaken Blazor WebAssembly with other WebAssembly demo such as UWP+WebAssembly demo...
As far as Blazor is concerned, even the WebServer mode seems reasonably fast enough!
On the other hand, the UWP+WebAssembly demo is terribly slow to initialise... 
modified 25-Jul-20 23:25pm.
|
|
|
|
|
I never looked at UWP+WebAssembly, so I'm pretty sure I talking about Blazor, but then again, it's probably been 2 years since I last gave it a spin.
|
|
|
|
|
Alright then, I am surprised...
To be honest I did search the web much for various sample, just did read the whole documentation and build provided sample locally...
I did notice at that stage it was downloading the .NET Assembly as is (the DLL) and maybe it takes time to parse the IL to WebAssembly on slow computer, but I have a fast one,so it went instant for me...
|
|
|
|
|
It depends on what you are doing and who your audience is.
I looked at Blazor and thought it looked great for 'external' users on mobile phones etc. But my users are all internal using PCs so Razor Pages was better - not as leading edge (so easier to learn) and faster response.
|
|
|
|
|
Thank you for your input. I was unaware that it could run on phones, but I'm glad to find that out.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
It is definitely designed to work on non-Windows platforms as its slowness is caused by having to write the .Net framework as WASM code to the device first; the documentation said (As far as I can recall) that it is slow for Windows as it still downloads the .Net stuff. Perhaps I interpreted non-Windows as including phones as many of them are Linux based or perhaps it actually said it. Don't trust my recollections - I could be wrong. The key message that I took was that it was inefficient for Windows and anything other than that could have gone though my 'not relevant to me' filter and not be accurate.
I've just tried a quick look on a well known search engine for 'blazor mobile development' - this produced a lot of hits (some explicitly citing iOS and Android), a very brief scan of which suggests that my memory was not playing tricks; but they don't look as though it is simple.
------------------------
<edit>
I've been looking at What's behind the hype about Blazor? - Stack Overflow Blog[^] - that says there are / will be multiple delivery mechanisms. One (web assembly) does send Mono to a device as a mini .Net download and then runs natively so it is slower to get started; but another has the browser communicating to a .Net server using SignalR which obviously has latency which could impair the user experience, but the author of the article suggests this is not normally significant. So it is definitely worth looking at and making a decision based on your actual requirements.
Oh! I've just remembered one of the pragmatic reasons why I had rejected Blazor - it needs versions of .Net Core (?) that are not supported in our environment.
modified 27-Jul-20 7:23am.
|
|
|
|
|
IMO, It would be good to have C# instead of JavaScript if it's extensible, fast and have a growing support development community. JavaScript over last few years has leaped quite ahead and it would take some time to catchup in case its promising.
With .NET5.0 around the corner (later this year), it would be good to see how entire .NET tech gets placed.
|
|
|
|
|
You have to have the green blazor version to Master Blazor.
I'd rather be phishing!
|
|
|
|
|
In general; if you need to ask then no. Spend your time on where you needn't ask.
So what's a blazor, and why should I care?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It looks useful if you have some C# code that you want to run in a web page without porting it. Except that might not work, because "APIs that aren't applicable inside of a web browser" don't work .. but it looks promising? For code that doesn't do anything crazy anyway.
I just hope it isn't like Google Web Toolkit, which pretended to be like Java but blatantly violated Java semantics, making it a portability nightmare. (if you've ever seen ~~ in "Java", this is why that silly construct exists)
|
|
|
|
|
Client side, Blazor just isn't fast enough yet. WASM will get there, but I don't think it's there yet.
|
|
|
|
|
Over the years Microsoft has tried quite a few things on the web that quite simply have had varying degrees of success:
- ActiveX (dead)
- VB6 Web-Classes (dead)
- ASP.NET WebForms (more dead than alive)
- Silverlight (dead)
- ASP.NET MVC / Razor (still-around but long in the tooth)
- Blazor (we'll see)
Everything before ASP.NET MVC, IMHO, was not in line with the way the web worked. It almost seemed as though Microsoft tried to create a Win-Forms based thinking for the web. Web-Forms attempted to place an object model around HTML which was admirable but probably quite unnecessary. With MVC one could even replace the view engine but that never *really* took off.
The web is a funny environment but I quite like it. I prefer writing web-based applications. The ecosystem is huge and as soon as you move away from it you are creating a parallel universe. When you play on the same field then you are going to find a lot of support.
This is why I don't even use Visual Studio for web-based work. I used to use WebStorm but VSCode is just great for folder-based development.
Should Blazor integrate seamlessly with any coming WebAssembly bits then it stands a chance. I don't think I'm really sold on WebAssembly yet as plain JavaScript gets the job done. I don't even bother with TypeScript although should I have to use it then fine. I'll probably like it 
For now I'll take a wait-and-see approach.
|
|
|
|
|
I dunno. I'm very very good with javascript (JQuery especially. Love that AJAX) and see no need to go to Blazor. Up to now, the main use of Web Assembly has been malware, though I guess Blazor is catching on. I've "read" articles describing weird potential vulnerabilities of it though, that if true, sound like technology killers. I've looked at it a couple of times but it clearly wasn't ready for prime time yet. I'll wait and see but why use C# (my language of choice) when javascript is a web native language?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
