Excel-lent: Microsoft debuts low-code Power Fx language... but it is not really new Microsoft today introduced Power Fx, a low-code language for its Power Platform, but it is not altogether new, being extracted from the existing formula language for what the company calls canvas apps. The company has long been in search of some equivalent to Visual Basic for the cloud, that would allow non-programmers to …
This looks both exciting and terrifying all at once. rather than persuading businesses hooked on spreadsheets to move to properly defined structures, instead hand out tools to connect together wobbly ill defined structures.
Spreadsheets absolutely have their place but I can see this becoming an incomprehensible mountain only too easily.
VB was an excellent way to write event driven Windows applications. Always seen as inferior to C++ and C# so MS kept improving the language. That introduced complexity so VB was no longer useful as lesser devs such as myself just crossed to C'#.
Both BASIC and Pascal are excellent languages to use when you want to illustrate an algorithm or calculation because you don't have to be an expert programmer to understand the code.
"First, solve the problem. Then, write the code." - John Johnson
the canvas apps. The report server already was a... well... not all that convenient thing, the "language" used not that consistent nor convenient, especially when constantly changing between the SSRS projects and SQL. Power apps are even worse, and feel really dumbed down. A lot. The results might please the pie (and worse: donut) chart crowd, but these graphs are mostly management eye candy, not for serious use.
I guess I'll start anew with R, php, LaTeX, etc. to just create PDF reports....
> I'm ready to welcome anything that has the potential to reduce the number of spreadsheets being used to store data. This has that potential.
I applaud your sentiment and optimism. The reality, I suspect, will be that users learn just enough to be able to extract data into a spreadsheet...
I'll admit I've not dug into the low/no code stuff so am slightly commenting from a position of ignorance but from the blurb it mostly reminds me of the MDD/round trip engineering voodoo that had a bit of a hypebubble in the late 90s. IIRC Visual Cafe did a not completely horrible implementation of it; draw your UML and it generated the code for you.
Obviously that fell to pieces when you had to do anything even moderately complicated. As soon as the logic gets a bit involved it turns out it's easier to understand code than it is to follow a diagram. I thought that had killed it off a fair while back.
Anyone out there who knows a bit more than me (low bar to clear) care to point out why this is so very different?
Rosie
Nothing much has changed in the tools, low-code generally will not provide benefits to teams of professional developers implementing enterprise software.
There are two (separate) things that low-code can potentially help with. One is pushing organizations that see agile as "something IT does" to adopt better agile practices by having real users get more involved in the development process. Low-code tools allow people not familiar with software development to do some productive work around layouts and flows, and it looks a lot less scary than screens full of <programming language of the week> so they are more likely to agree to take an active role. The net result of this is that you are more likely to solve the right problem first time, rather than what the developers think the problem is, based on what they were told while being kept at arms length from anyone who actually uses the application.
Secondly, (a different set of) low-code platforms provide an alternative to all the excel spreadsheets and access DBs that get emailed around/sit on shared drives. In theory there is a big advantage here that if IT own the low code platform, they can see who is doing what with it, and step in when they identify something that presents a risk, or an opportunity to provide a better solution.
There isn't really any new secret sauce here that wasn't around 10 years ago, but what there is, is a better understanding that the end-users should be involved in software development, and low-code makes that less "scary" for the end-users.
Who remembers "The Last One" (circa early 1980s?) Would make programming obsolete? - 40 years later and I'm still coding away!
I'm not sure about low code/no code: but code generators and frameworks do have a definite place. I used them on various mainframe applications in the good old days - something called TELON to generate COBOL frameworks and an online system for CICS called UFO. They saved a lot of time, as the skilled prcoder could concentrate on the application logic, and not worry too much about making sure someone had fitted the wheels to the car.
It's nice to have a cloud native excel-like for small teams to use together. I can think of a few simpler things I've coded in the past that would have been much better on a system like this.
However, complexity is where the dark arts lie. I fear that people not used to controlling code will keep adding to their apps, build towering monstrosities that will be very hard to maintain, version and control.
Within its limits, I think this will be a boon for those that need it, though.
I've really tried to get into PowerApps, being the sort of target user it's after, but it's really too annoying and hard work. Everybody likes automating Excel, because they are well practiced in its interface and that exposes lots of virtual "modules" that they can fiddle with via VBA. I like the idea of protecting tables of data via PowerApps, and hence less problems with accidental spreadsheet destruction, but just try setting up the default filtering and sorting available in an Excel table via a PowerApps gallery - it's absolutely infuriating and not even possible for some things. I also recently tried the responsive design elements and found them confusing. I'm more likely to invest my brainpower shifting to the "future of Excel automation", which someone told me was Typescript.
IT support team: goes off and cries for when it totally breaks for the end user.
We already have plenty of cottage industries internally, which are fine until it breaks and you realise a critical piece of code was written by an intern who has since left.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
