Welcome to the Lounge

PIEBALDconsult6-Jan-23 6:19

PIEBALDconsult

6-Jan-23 6:19

Software development isn't a contest.

honey the codewitch6-Jan-23 6:21

honey the codewitch

6-Jan-23 6:21

Uh oh. Someone has clearly hacked my profile and put all these fake contest wins in it.

honey the codewitch - Professional Profile[^]

Who do I talk to about that?

PS: I didn't say software development was a contest. You strongly implied I said that. There's a rather large difference between those two things.

To err is human. Fortune favors the monsters.

Jeremy Falcon6-Jan-23 8:51

Jeremy Falcon

6-Jan-23 8:51

honey the codewitch wrote:
PS: I didn't say software development was a contest. You strongly implied I said that

Yeah, but this is the Internet. We're not supposed to read the posts we reply to.

Jeremy Falcon

jochance6-Feb-23 9:24

jochance

6-Feb-23 9:24

tl;dr

0x01AA6-Jan-23 8:23

0x01AA

6-Jan-23 8:23

Looks like it is related to this, the chief was in holiday: Bugs and Suggestions[^] Laugh | :laugh:

honey the codewitch6-Jan-23 8:25

honey the codewitch

6-Jan-23 8:25

Chris going on holiday? We can't have that! Laugh | :laugh:

To err is human. Fortune favors the monsters.

Sean Ewington6-Jan-23 8:55

Sean Ewington

6-Jan-23 8:55

If you mean the monthly competition, I didn't think it was fair to articles submitted late December for the contest to start Jan 2.

Thanks,
Sean Ewington
CodeProject

Microsoft Power Apps

Single Step Debugger6-Jan-23 5:26

Single Step Debugger

6-Jan-23 5:26

Microsoft is pushing on us this system as an alternative (instead of .net core and Blazor) of rewriting some big old order and data processing applications. Anybody with any experience on this? At first glance I'm genuinely scared.

Advertise here – minimum three posts per day are guaranteed.

Marc Clifton6-Jan-23 6:07

Marc Clifton

6-Jan-23 6:07

Yet another no code attempt. Of course Microsoft has to jump on the bandwagon. Nothing to get scared about. Laugh | :laugh:

Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain

PIEBALDconsult6-Jan-23 6:23

PIEBALDconsult

6-Jan-23 6:23

And I doubt they'll eat this dog food.

Single Step Debugger6-Jan-23 7:24

Single Step Debugger

6-Jan-23 7:24

Thanks. What I'm scared of is that we will put a lot of effort in this conversion and at the end it will become clear that there are "too many exceptions" and the project will be scraped. Or the end result will be unusable mess.

Advertise here – minimum three posts per day are guaranteed.

Marc Clifton6-Jan-23 8:41

Marc Clifton

6-Jan-23 8:41

I would never look at a no/low code solution for a project - you will inevitably encounter something that the no/low code can't do.

Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain

jochance6-Feb-23 9:39

jochance

6-Feb-23 9:39

At the end of the day the thing low code cannot do is "be a developer" I think.

What happens in low code if you make, with its help, an error of intent instead of function?
That is, "it worked as designed" but the design was wrong?

When you have developers, you say "Oh, you guys got the design wrong. We meant <x>." (Kidding, mostly)

You (as a developer) go do data-doctoring and maybe take care of some other adhoc processes that need to spin off and happen as a result of the issue.

In low code? Do you just start pursuing creating those tasks in low code? How do you even know the need exists?

The Risc V push is fascinating to me

englebart6-Jan-23 15:54

englebart

6-Jan-23 15:54

Do a head to head eval based on Gartner magic quadrant for low code. There are at least three products I would recommend ahead of MS power apps.

My memories of power apps demos/POCs:

Trying to write a simple formula to enable/disable a button based on a few other fields was barely writable and unintelligible.

Good luck writing the logic to prevent users from double clicking a button and submitting the form twice!

honey the codewitch5-Jan-23 22:53

honey the codewitch

5-Jan-23 22:53

I read here somewhere recently that Google is pushing to make Risc V de riguer for Android phones.

In addition Espressif has IoT MCUs based on Risc V processors, and appears to be moving to Risc V for their new projects.

This tells me Risc V is suitable for CPUs with a wide range of capabilities.

It's about damned time they standardized a CPU architecture in a practical way that could be leveraged across the tech industry.

I'm really interested in this technology, and although I'm not a fan of Espressif's current Risc V offerings, which are low power, but kind of anemic, they have a soon to be released offering

The ESP32P4

Triple core (2x400MHz, 1xULP40MHz), 768kB of SRAM, 50 GPIO, wireless connectivity for days, all Risc V based.

And if Android primarily adopts it, how long before Windows follows suit?

To err is human. Fortune favors the monsters.

obermd6-Jan-23 8:07

obermd

6-Jan-23 8:07

Microsoft is too embedded in the x86/64 architecture. This was one of the problems with the AlphaServer versions of Windows NT - emulation was far too slow.

trønderen6-Jan-23 8:54

trønderen

6-Jan-23 8:54

Doesn't dotNet change that?

In dotNet, there is no emulation; each assembly is JIT compiled to native code. I believe that even available instruction set extensions are considered, to avoid runtime testing - all JIT compilation is done on the target machine (but don't quote me as a source on that). (This is obviously when the code is distributed as dotNet assemblies; you can generate a complete, statically linked executable file for distribution; then the code must test for instruction set extensions at run time!)

I also believe that the structure of the Windows kernel has been significantly changed since the NT days, in the direction of a much more well defined hardware abstraction layer that handles different architectures, leaving the higher layers unaffected. With a HAL definition, they are not talking about any sort of emulation, but true native code - think of the HAL as the code generation part of compilation! (If you like: The JIT part of dotNet compilation.) Historically, Windows has been running on i860, Alpha, Itanium, MIPS, PowerPC, ARM, ARM64, IA-32 and x86-64 - that provides quite a background for defining a HAL suitable for a multitude of CPU architectures (including Risc V).

Another problem with the Alpha was that the processor itself flopped. It made a good cooking plate for frying your lunch meal, though. I have been working with the Alpha for just a couple years: We bought it to teach the tech. college students Unix, so it was running DECs own Ultrix. I can assure you: Performance problems was not limited to Window NT! The vendor doubled the amount of RAM installed, at no cost to the college, in an attempt to make it perform as promised in the contract, but even after that, it didn't "run" - at most, it walked, dragging its feet along the ground.

My impression is that DEC had problems with context switching performance when working in a small format. Running a single process could show impressive results, but switching among 20 user front ends (running X11 servers) didn't work out. It reminded me of the early VAX days: The company of a friend of mine bought a VAX 730, and benchmarked process switches to take 100 ms - one tenth of a second! They had to rewrite their DBMS from three to two main processes, so that fewer process switches was needed, to get acceptable performance.

trønderen6-Jan-23 9:20

trønderen

6-Jan-23 9:20

honey the codewitch wrote:
It's about damned time they standardized a CPU architecture in a practical way that could be leveraged across the tech industry.

Keep dreaming! It has happened! Look at the x86 desktop architecture. Many years earlier, it was the IBM 360 architecture. For smartphones, the ARM architecture has been a de facto standard CPU architecture for quite a few years.

The problem is that lots of developers discover that there is something new, which makes them reject the estabished, accepted, respected and honored standards - they want to throw them out. Look at yourself: What makes you think that ARM is not "a CPU architecture that could be leveraged across the tech industry"? You have found that RISC V has some advantages that makes it a better alternative. If we switch horses from ARM to RISC V, it won't take long before someone come up with yet another architecture that has advantages over the RISC V.

Over the years, I have lost all kinds of trust in "Strangler jeans: One size fits all!" You must be prepared to handle alternate solutions. Monoculture is never good. (My t-shirt that states "Stereotypes are real time savers" is sort of true, but obviously ironic.)

So make yourself a hardware abstraction layer, and implement that on all the different CPUs that you come to work on.

(Regarding RISC V: I 'discovered' it in my last job. The company makes IoT chips externally looking as two core ARM chips. Under the cover, there are several other cores, managing various parts of the hardware asynchronously with the two main ARM chips. One of these 'secret' cores is a RISC V.)