I just read the overview document (docs/overview.md in that repo), and I have to say I'm blown away.
Excel is one of the world's most popular programming environments, because it has such a low barrier to entry, but it's limited: the input is always a grid of numbers, and the output is always a grid of numbers, which limits how useful it can be to people outside number-crunching professions.
Visual Basic (especially the original, pre-.NET incarnation) let you create Real Windows Apps with all the inputs and outputs that entails (images, copy/paste, files, sliders, textboxes, databases) and let you use a fairly simple and forgiving language to wire them together... but the barrier-to-entry was still a lot higher than Excel, even if it was lower than C++, or even Visual Basic.NET.
This PowerApps thing seems like an elegant middle-ground between the two - rich inputs and outputs (images, sliders, text-boxes, databases), with a simple, predictable language to wire them together. The inputs and outputs aren't quite as rich as Visual Basic, but the shift from native apps to web apps has changed people's expectations since the days of VB6, so that's probably an advantage.
And another 5 years of students will have a new layer of Microsoft obfuscation to muddle through until they sort out that the *nix world is the better alternative.
We recently tried to build a relatively simple PowerApps application - under the assumption it would save time over pumping out a React boilerplate form. Never again.
We wanted it to be able to integrate with our backend which lives outside the MS ecosystem. No problem we thought - that's what custom connectors are for. Except they don't work with any of the automated form generation functionality. So we pretty much have to build the form entirely manually.
Low code becomes high code all of a sudden - except it's worse than just coding and learning a new framework. You can't just input your code anywhere you want, or import your dependencies, etc... You have to hunt around in a zillion different (laggy as all hell) interfaces to find the right location where that code can live. Or maybe it's not code - but a toggle somewhere... OMG... kill me.
Good luck if you are trying to learn the lower level aspects... since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource - and that your connector actually works as advertised.
If you can code - and your stack doesn't already entirely consist of the MS ecosystem. Just roll your own.
> You have to hunt around in a zillion different (laggy as all hell) interfaces to find the right location where that code can live. Or maybe it's not code - but a toggle somewhere... OMG... kill me.
> since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource
If you have to troubleshoot software advertised and explained by happy smilling people dragging and dropping things, code automagically appearing from snippets, claiming that "it's easy" - RUN AWAY. Your mental health is at stake.
I cannot agree with you enough. Our company hired a new manager that had a background "familiarity" with PowerApps. He requested that I (a software developer) create a PowerApp that would be used by the company, essentially a ticketing system. I figured with my ~decade experience in developing complex web applications from the ground up, this would be a piece of cake.
What an abysmal way of developing applications. Everything (containers, widgets, etc.) is basically SVG's and your application looks like your designers couldn't use anything but MS Paint. Creating more complicated interactions with buttons and other UI elements was a pain to develop and making the UI responsive was a nightmare. The generated HTML was insanely ugly and the application was very slow/sluggish feeling. After fighting for a couple weeks, I began to (behind the scenes) build out a quick web application alternative to pitch. Long story short, he LOVED the web app version and that is what we are still using today company wide.
- Canvas apps: worth it only for very simple applications that interact with another MS datastore (Sharepoint, CDS/Dataverse) and services. If you mostly need to interact with custom APIs, a simple custom webapp is probably a safer choice.
- Power Automate: stick to very simple flows, take advantage of the connectors but avoid at all cost complex business logic within the flow itself
- Model-driven apps: more interesting in my opinion. They effectively are mini-instances of Dynamics CRM, and you get A LOT of functionality out of the box. You can't tune the UI much, but you get the benefit to build an "interactive database" very quickly, with support for RBAC system, OData REST APIs, Views, Workflows, C# plugins, dashboards. If you need an internal application, used only by a few people (licensing), where you need an interactive data-store without complex requirements on business logic and custom UIs, then I think Model-driven apps can be terribly effective. Now, if only the licensing wasn't so damn complicated...
I'm Power Platform architect, I have been working with Dynamics for more than 10 years. Your post feels more like you were thrown on a project where you didn't know the stack.
I've seen those projects where I'm brought in to fix some internal project gone wrong because they took internal softdev with no knowledge of a platform that exist for more than 15 years.
Meanwhile, I shipped whole systems in half the time you took to "roll your own".
Just try to roll your own ERP/CRM, we saw plenty of time how that goes.
I was curious about PowerApps when it first came out and the past year or two is the first time I’ve ever seen one.
We have a handful of PowerApps at our company and they’re really just forms hosted on Sharepoint sites. Type in some info, select some drop downs and hit enter. I still haven’t experienced PowerApps from the development side, but I’ve been pretty unimpressed with the work I’ve seen from it.
Flipside we rolled out over a dozen powerapps and they work great. Our Engineers can now focus on solving bigger/tougher problems instead of being tasked with making simple crud apps 24/7
I had a very similar experience. Also, the interfaces are hideous and static - even though this was an internal product, the client wasn’t happy. If I’m going to have to customize it so much to make it look decent, we’re back to hi-code.
> Microsoft Power Fx is the low-code language that will be used across the Microsoft Power Platform.
The emphasized part above is all you need to know to understand that Microsoft Power Fx is NOT a low-code general purpose programming language, as is mistakenly stated in the README document. It might be general purpose in the Power Apps context, but it's a moot point from the larger perspective. Generally, Microsoft Power Platform and, thus, its subset Power Apps, present a much stronger lock-in risk than Azure and some other products and services.
> We are in the process of extracting the language from that product so that we can use it in more Microsoft Power Platform products and make it available here for you to use. That's going to take some time and we will report on our progress here and on the Power Apps blog.
I think more interesting than "low code" is the stated goal of enabling "the full spectrum of development from 'no code' to 'pro code' with no cliffs in between."
"Pro code" means you can edit the source with Visual Studio and use source control.
This is indeed a killer feature. You would never be able to load a Microsoft Access ACCDB file into version control and extend it in any way beyond the limitations of the Access runtime.
This provides a path to convert a rapid prototype into a real app.
Power-Fx's formulas seem to be equivalent to property binding or functional reactive programming (as opposed to ReactiveX). The difference is that property binding and FRP are generally used in a precompiled GUI to automatically propagate changes made by users across program state, whereas Power-Fx seems to be more an integrated system with Smalltalk-style editable live programs, or low-code for makers rather than just developers. I hope Power-Fx makes property binding or FRP more mainstream.
Well, the animation under "Basic usage" at https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps... highlights how the bar along the top changes based on what which button or control is selected. In turn, you can pick properties or events by name on the left (like "OnSelect" for when the button is clicked) and then type in a function that should run on the right, such as Notify(). You might think OnSelect is an odd name for an "OnClick" but it makes sense when you look at how many different types of controls could conceivably use "OnSelect" as a "primary action" of a control: https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps...
By comparison, with React or ReactiveX, you can do very similar things, but by default, complications creep in because of how the language works. In JavaScript, for instance, you have to worry about binding "this" for example: https://reactjs.org/docs/faq-functions.html In ReactiveX, you have to think about how you're going to structure your code, and maybe even occasionally draw flow graphs.
I would also compare this to SwiftUI or Flutter, but more from the app layout perspective, where both platforms are much more mature than when they started. Here's an example comparing React and SwiftUI: https://blog.maximeheckel.com/posts/swiftui-as-react-develop... One could imagine a meta-article that compares Power-Fx to SwiftUI to Flutter, etc. Actually ... I went hunting for how state works in Flutter, and it's remarkably complicated, showing perhaps that languages which are free to evolve can maybe iterate to better solutions faster: https://flutter.dev/docs/get-started/flutter-for/react-nativ...
To that end, I'd look forward to seeing more projects and languages adopt the "automatic code upgrade" approaches widely seen in Xcode, React/JS codemods, and here, in Power-Fx. The idea that somebody has mapped a conversion from "the old way of doing things" to "the new way" is really convenient when the language can support it.
I'd be interested to see if Power-Fx might expand to automated test cases -- wait, apparently that's a thing for Power Apps: https://powerapps.microsoft.com/en-us/blog/introducing-test-... It maybe needs a bit more usability improvement. It would be amazing if it behaved like Redux such that you could scroll through your test playback and maybe even view or add assertions at different steps or if it supported automatic "snapshots" of visual appearance or view state, perhaps like Jest. Theoretically, you could run a test step twice (or more, such as when fuzzing) and if its output changes, mark that section visibly as dynamic or "to be ignored/fixed later" (kind of how Bazel can warn on non-deterministic build steps). If a function loads remote data, maybe it could also be a suggested snapshot for the test, and once you've a snapshot of loaded data, you could experiment with automatic fuzzing. There's a lot of potential in testing functional UI that could improve apps and even inspire tools for other, more traditional languages and frameworks...
Thinking about testing tools, I suddenly had other ideas: What if you gave Power-Fx an input, an output, and then had it suggest what combinations of functions might produce that result? I'd imagine it would be more of a learning tool, but it could be interesting. Similarly, for education or understanding complicated functions, maybe there's a "debugger" mode where you could hover over any part of the function and it would tell you the value of that part of the function, given the view's current state/input, kind of like how Excel highlights cells that store data? Or to automatically convert a function into an English text representation that might be 5-10 sentences but would use existing data/context to explain itself? That way you could follow the flow of the function the way some regular expressions tools help you understand what's going on in a complicated regex expression/function, for example.
It may be unfair, but as an academic, when I read "not Javascript" I thought, "oh yeah, seems cool, surely anything is better than Javascript" and then it hit me that they were gonna base it on EXCEL. The nightmare platform to end all nightmares. The software that's responsible for austerity [1] and for people dying of Covid [2].
OK, I'm sure this is unfair. Maybe Excel's underlying design is a great computing platform? Comments from domain experts?
Excel has a known row limit. Anyone blaming the row limit is trying to dodge blame. I have the exact same respect for those folks as I do for folks that misuse a hammer. I have written Perl scripts that dump the results of SQL queries into a spreadsheet and do additional tabs when the row limit is reached. The tool didn't do the damage, the tool using the tool did.
IT people hate Excel because normal people can get work done, much like HyperCard and Flash before it. Perhaps someone will write a more IT friendly Excel without losing the users.
Eh. Most Excel horror stories have to do with putting it "into production". Excel is really a prototyping tool -- and it has enabled countless millions upon millions that were just not going to read SICP (and get all stakeholders to read SICP) to attack business problems.
Now, if programmers are unable to understand the logic behind Excel models to "productionize it", then we have a problem with the education of programmers.
I heard about the excel length issue, but I thought that just meant their tracking numbers were off. I didn't realize that it affected tracing and quarantining!
>The study’s most conservative estimates suggest that the failure to contact trace is associated with more than 125,000 additional infections and more than 1500 deaths.
> By Calc Intelligence, we mean the research goal of bringing intelligence to end-user programming. The spreadsheet of the future is a trustworthy collaborator and teacher.
> In December 2020, we announced LAMBDA, which allows users to define new functions written in Excel’s own formula language, directly addressing our second challenge. These newly defined functions can call other LAMBDA-defined functions, to arbitrary depth, even recursively. With LAMBDA, Excel has become Turing-complete. You can now, in principle, write any computation in the Excel formula language.
Possibly worth noting: the title of that blog post ("Lambda: the ultimate Excel worksheet function") is a reference to a famous series of papers (https://en.wikisource.org/wiki/Lambda_Papers) by Guy Steele and Gerald Jay Sussman with titles of the form "Lambda: the ultimate X", with X = Imperative, Declarative, GOTO, Opcode. (These also gave their name to a programming-languages blog: http://lambda-the-ultimate.org/.)
There are so many things I like about this - leaning in to the idea that spreadsheet formulas are a functional programming language, and enhancing that with inferred static types, plain-text persistence, (semi-)structural editing.
And then they go and re-enact Tony Hoare's billion dollar mistake, for no good reason that I can see:
> Some language such as JavaScript uses the concept of an "undefined" value for uninitialized variables or missing property. For simplicity's purpose, we have avoided this concept, treating instances that would be undefined elsewhere as either an error or a blank value. For example, all uninitialized variables start with a blank value. All data types can take on the value of blank.
This is the same spurious "simplicity" seen in Go, and I don't understand the appeal - especially coming from a team that clearly "gets it" when it comes to the importance of expressive types.
yeah it drives me wild that so many strongly typed languages (graphQL and typescript immediately come to mind) allow null/undefined values by default. I should have to opt-in to make a value optional! At least then both the compiler and I are aware of where I need to test for nullsy values.
I've been working heavily in what I've dubbed the POWERStack for the past 13 months for a consulting client. Front end = power apps, back end = power automate + some cloud powershell (azure automation runbooks), database = sharepoint lists, sql (for initializing/iterating on complex lists) = local powershell.
As for Power Fx, in one particularly fun PowerAutomate flow I crafted for them, I wrote the following one liner to display a "percent complete" value for a given employee with regards to trainings they'd taken vs. trainings they were expected to have taken for OSHA compliance purposes. Parsing it is left as an exercise for the reader:
Overall, I rate the POWERStack 8/10. It's not perfect, but it's fairly robust, not too difficult to reason about, and there are more than enough enterprise clients married to Microsoft to keep me in business for the foreseeable future. My only requests are to let me code Power Apps and Power Automate Flows fully in code-behind. I get that they're low-code tools by design, but in practice, they make things more difficult than they need to be for those of us who are quite happy to live in code, and I'd like to be able to build tools for automating the process for updating/adding functionalities to existing powerapps for those stakeholders that are on the absolutely-not-a-single-line-of-code-ever end of the development skill tree. Otherwise my business (in the Microsoft space) will remain bottlenecked by my time, and I'll have to dig elsewhere for my "set it and forget it" income stream.
If you need help building things with these tools/in this environment, feel free to reach out.
At some point, when Sciter (https://sciter.com) was young it was named HTMLayout - pure HTML/CSS engine without script. At some point I've decided to add a bit of scriptability/formulas directly into CSS so you might say (in CSS) for example this:
C++ developers (initial users) were excited of such level of configurability that allowed to add logic without writing "real" code. And I've started getting requests for conditionals like if-then-else, functions and other stuff like that.
So CSSS! (css script) was born: https://sciter.com/docs/core/csss!.htm - it was even more powerful than Microsoft Power Fx - you can even define functions in it and operate with all data types of CSS.
The excitement ended when I've got a bug report with HTML/CSS document where one of focus!: ... handlers in that CSSS! spanned more than a page of printed and ugly text. So I've said to myself: it is time for scripting - anything, even JS, but with regular code flows and organization.
The lack of a real Number type (just IEEE 64-bit floats here) is a real disappointment considering all the talk about business logic in the documentation. Something with Excel heritage aimed at businesses should be able to at least handle 64-bit integers, instead of silently dropping precision on your revenue calculations. .NET had "Decimal" (high precision base 10 floating point) from the very beginning because of this.
I worry that a year or two down the road there will be production Power Fx applications hitting all sorts of problems that would have been prevented if there was a proper numeric type from the beginning. Computers are fast now, the average application can handle burning a few extra cycles on addition operations when updating a textfield if the alternative is a customer's account balance getting miscomputed.
I suppose this is as good a time as any to mention that we are working on an open source interpreter compatible with VB6/VBA that can run on the web. We didn't plan to make the announcement today but since Microsoft is releasing their news, I might as well let HN know about ours. We are planning to do a proper launch and release during the summer since currently our editor (which integrates collaborative editing and version control) and the other parts of our platform are not ready yet. For now only the core language interpreter and some basic widgets are usable. As for the UI issue, responsiveness is indeed a big problem for traditional absolute positioning desktop apps versus the modern flexbox standard. However, it is not a very challenging problem to tackle if your widgets are standardized and that the UI builder supports easy testing of the three major screen sizes. In other words, as long as you don't need tremendous control over how every pixel of the UI looks, the drag-and-drop style GUI building transfers quite well over to the web.
Huh, interesting. Reminds of an "enterprise" version of Apple's Automator tool. I always wished Apple had taken the premise of Automator and blended it with the UI of Quartz Composer.
It looks like Microsoft is a few steps closer to that kind of thing with Power Automate.
I find it buggy when you’re not on the main commercial cloud. For example, simple operations related to finding unique values in Excel just don’t work.
Why did you have to translate VB app to Java? To enable web? In VB if i wanted to display a database table, even as a newbie, I could do it in 2 minutes. Despite having a decade of experience, I struggle to display a paginated, reactive database table in Java over a week. Not saying Java is bad, but VB was amazing in its time for building desktop business apps and nothing came closer to that (other than other RAD tools).
It's low-code, not no code. Salesforce has been in this market for about 20 years with significant success.
Power Apps are irrelevant to you unless you're heavily integrated with O365. And if you are, chances are that you're in a large organization. And if that's true, you hire a certified MS partner to handle maintenance, you don't leave it to non-technical staff.
At best, like MS Excel, staff can use the tool to prototype something, and then let the consultants figure out how to create a working solution that works across the whole org.
I just ran into Power Automate for the first time yesterday. The UI looks glitzy. I think many users are going to be vastly underwhelmed and frustrated when they start interacting with third-party software by way of hand-puppeting the Windows UI, though. The quantity of brittleness and sensitive dependence on runtime conditions that this tool is going to generate will be supreme.
A Customer (who frequently creates macro-laden Excel contraptions and byzantine nests of "linked" workbooks) was trying to automate some workflow between a third-party application and Excel.
The third-party application is a bit of a "platform" (a "let's re-invent Microsoft Access" data roach motel type application) and uses lots of owner-drawn controls masquerading as common controls (with no keyboard shortcuts). He was struggling to get the UI automation functionality to do what he wanted.
Having spent a "former life" writing VBScript automation code using "SendKeys", etc (and using various other macro automation tools) I explained that he was descending into the hell that is other people's Windows UI behavior, and that it often ends in frustration.
I expect that this platform will end up, like so many before it, being used to create inscrutable edifice in many companies. That edifice will be abandoned when the knowledgeable party leaves a company and nobody new wants (or knows how) to figure out how the junk works, or will become wildly mission-critical and have massive amounts of money poured into it to keep it working, lest civilization collapse (e.g. "The Machine Stops").
I gave it a try and used a simple Excel file (with tables) to create a PowerApp. Customization wasn't too painful. However when more than one person needed to use it, it was locked because the Excel data source could not be accessed by more than one user at the same time :-(. I should have used Sharepoint lists instead. So, the simple thing of working with familiar apps like Excel and creating a form entry on top of it was disappointing.
I think the thing that this still misses is that there really needs to be a good story for the evolution out of a low code tool and into a framework and only-code tool. If the low-code tools are successful, they inevitably need an in depth integration into the rest of an engineering codebase. I think this is the gap that needs to be crossed, power apps and zaps are already plausibly useful for most new users, but are challenging to evolve out of.
People have been selling 'low-code' for decades now. Whether it's indented outlines, natural language-ish DSLs, drawing flow charts or UML, YOU ARE STILL WRITING CODE. So, the details that you sometimes need to know and/or change are hidden.
The only one that I have used that seemed any good was Labview, and even that is not really 'low code', just 'different code'.
[+] [-] thristian|5 years ago|reply
Excel is one of the world's most popular programming environments, because it has such a low barrier to entry, but it's limited: the input is always a grid of numbers, and the output is always a grid of numbers, which limits how useful it can be to people outside number-crunching professions.
Visual Basic (especially the original, pre-.NET incarnation) let you create Real Windows Apps with all the inputs and outputs that entails (images, copy/paste, files, sliders, textboxes, databases) and let you use a fairly simple and forgiving language to wire them together... but the barrier-to-entry was still a lot higher than Excel, even if it was lower than C++, or even Visual Basic.NET.
This PowerApps thing seems like an elegant middle-ground between the two - rich inputs and outputs (images, sliders, text-boxes, databases), with a simple, predictable language to wire them together. The inputs and outputs aren't quite as rich as Visual Basic, but the shift from native apps to web apps has changed people's expectations since the days of VB6, so that's probably an advantage.
[+] [-] otabdeveloper4|5 years ago|reply
This thing seems like more or less the same, except slightly different.
Low (or even negative) value for the users but probably high value for the managers and programmers who hope to get a promotion out of this thing.
Microsoft should just stick to Power Query and make it a real standard instead.
[+] [-] killjoywashere|5 years ago|reply
[+] [-] oraphalous|5 years ago|reply
We wanted it to be able to integrate with our backend which lives outside the MS ecosystem. No problem we thought - that's what custom connectors are for. Except they don't work with any of the automated form generation functionality. So we pretty much have to build the form entirely manually.
Low code becomes high code all of a sudden - except it's worse than just coding and learning a new framework. You can't just input your code anywhere you want, or import your dependencies, etc... You have to hunt around in a zillion different (laggy as all hell) interfaces to find the right location where that code can live. Or maybe it's not code - but a toggle somewhere... OMG... kill me.
Good luck if you are trying to learn the lower level aspects... since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource - and that your connector actually works as advertised.
If you can code - and your stack doesn't already entirely consist of the MS ecosystem. Just roll your own.
[+] [-] durnygbur|5 years ago|reply
> since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource
If you have to troubleshoot software advertised and explained by happy smilling people dragging and dropping things, code automagically appearing from snippets, claiming that "it's easy" - RUN AWAY. Your mental health is at stake.
[+] [-] Phillips126|5 years ago|reply
What an abysmal way of developing applications. Everything (containers, widgets, etc.) is basically SVG's and your application looks like your designers couldn't use anything but MS Paint. Creating more complicated interactions with buttons and other UI elements was a pain to develop and making the UI responsive was a nightmare. The generated HTML was insanely ugly and the application was very slow/sluggish feeling. After fighting for a couple weeks, I began to (behind the scenes) build out a quick web application alternative to pitch. Long story short, he LOVED the web app version and that is what we are still using today company wide.
[+] [-] lvice|5 years ago|reply
- Canvas apps: worth it only for very simple applications that interact with another MS datastore (Sharepoint, CDS/Dataverse) and services. If you mostly need to interact with custom APIs, a simple custom webapp is probably a safer choice.
- Power Automate: stick to very simple flows, take advantage of the connectors but avoid at all cost complex business logic within the flow itself
- Model-driven apps: more interesting in my opinion. They effectively are mini-instances of Dynamics CRM, and you get A LOT of functionality out of the box. You can't tune the UI much, but you get the benefit to build an "interactive database" very quickly, with support for RBAC system, OData REST APIs, Views, Workflows, C# plugins, dashboards. If you need an internal application, used only by a few people (licensing), where you need an interactive data-store without complex requirements on business logic and custom UIs, then I think Model-driven apps can be terribly effective. Now, if only the licensing wasn't so damn complicated...
[+] [-] niutech|5 years ago|reply
[+] [-] Demoneeri|5 years ago|reply
I've seen those projects where I'm brought in to fix some internal project gone wrong because they took internal softdev with no knowledge of a platform that exist for more than 15 years.
Meanwhile, I shipped whole systems in half the time you took to "roll your own".
Just try to roll your own ERP/CRM, we saw plenty of time how that goes.
[+] [-] switch007|5 years ago|reply
Pretty much this. Use MS Power platform exclusively for reading/writing from MS things and you should be OK. Venture beyond that and it's painful.
A lot of stuff seems to have grown out of (or is just layered upon) Sharepoint and Dynamics, so there is a lot of synergy there.
[+] [-] the_only_law|5 years ago|reply
We have a handful of PowerApps at our company and they’re really just forms hosted on Sharepoint sites. Type in some info, select some drop downs and hit enter. I still haven’t experienced PowerApps from the development side, but I’ve been pretty unimpressed with the work I’ve seen from it.
[+] [-] nojito|5 years ago|reply
[+] [-] alexfromapex|5 years ago|reply
[+] [-] arcturus17|5 years ago|reply
[+] [-] dfxm12|5 years ago|reply
It sounds like your app was not so simple.
[+] [-] gnud|5 years ago|reply
[+] [-] dustinmoris|5 years ago|reply
[+] [-] ablekh|5 years ago|reply
> Microsoft Power Fx is the low-code language that will be used across the Microsoft Power Platform.
The emphasized part above is all you need to know to understand that Microsoft Power Fx is NOT a low-code general purpose programming language, as is mistakenly stated in the README document. It might be general purpose in the Power Apps context, but it's a moot point from the larger perspective. Generally, Microsoft Power Platform and, thus, its subset Power Apps, present a much stronger lock-in risk than Azure and some other products and services.
[+] [-] Brendinooo|5 years ago|reply
> We are in the process of extracting the language from that product so that we can use it in more Microsoft Power Platform products and make it available here for you to use. That's going to take some time and we will report on our progress here and on the Power Apps blog.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] Zanni|5 years ago|reply
I think more interesting than "low code" is the stated goal of enabling "the full spectrum of development from 'no code' to 'pro code' with no cliffs in between."
"Pro code" means you can edit the source with Visual Studio and use source control.
[+] [-] nwah1|5 years ago|reply
This provides a path to convert a rapid prototype into a real app.
[+] [-] nyanpasu64|5 years ago|reply
- https://doc-snapshots.qt.io/qt6-dev/qproperty.html
- https://github.com/Logicalshift/flo_binding
- https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
- https://raphlinus.github.io/rust/druid/2020/09/25/principled...
Does anyone know how properties/FRP/Power-Fx compare to FRP frameworks, or ReactiveX, or MobX, or Svelte (JS)?
[+] [-] lstamour|5 years ago|reply
By comparison, with React or ReactiveX, you can do very similar things, but by default, complications creep in because of how the language works. In JavaScript, for instance, you have to worry about binding "this" for example: https://reactjs.org/docs/faq-functions.html In ReactiveX, you have to think about how you're going to structure your code, and maybe even occasionally draw flow graphs.
I would also compare this to SwiftUI or Flutter, but more from the app layout perspective, where both platforms are much more mature than when they started. Here's an example comparing React and SwiftUI: https://blog.maximeheckel.com/posts/swiftui-as-react-develop... One could imagine a meta-article that compares Power-Fx to SwiftUI to Flutter, etc. Actually ... I went hunting for how state works in Flutter, and it's remarkably complicated, showing perhaps that languages which are free to evolve can maybe iterate to better solutions faster: https://flutter.dev/docs/get-started/flutter-for/react-nativ...
To that end, I'd look forward to seeing more projects and languages adopt the "automatic code upgrade" approaches widely seen in Xcode, React/JS codemods, and here, in Power-Fx. The idea that somebody has mapped a conversion from "the old way of doing things" to "the new way" is really convenient when the language can support it.
I'd be interested to see if Power-Fx might expand to automated test cases -- wait, apparently that's a thing for Power Apps: https://powerapps.microsoft.com/en-us/blog/introducing-test-... It maybe needs a bit more usability improvement. It would be amazing if it behaved like Redux such that you could scroll through your test playback and maybe even view or add assertions at different steps or if it supported automatic "snapshots" of visual appearance or view state, perhaps like Jest. Theoretically, you could run a test step twice (or more, such as when fuzzing) and if its output changes, mark that section visibly as dynamic or "to be ignored/fixed later" (kind of how Bazel can warn on non-deterministic build steps). If a function loads remote data, maybe it could also be a suggested snapshot for the test, and once you've a snapshot of loaded data, you could experiment with automatic fuzzing. There's a lot of potential in testing functional UI that could improve apps and even inspire tools for other, more traditional languages and frameworks...
Thinking about testing tools, I suddenly had other ideas: What if you gave Power-Fx an input, an output, and then had it suggest what combinations of functions might produce that result? I'd imagine it would be more of a learning tool, but it could be interesting. Similarly, for education or understanding complicated functions, maybe there's a "debugger" mode where you could hover over any part of the function and it would tell you the value of that part of the function, given the view's current state/input, kind of like how Excel highlights cells that store data? Or to automatically convert a function into an English text representation that might be 5-10 sentences but would use existing data/context to explain itself? That way you could follow the flow of the function the way some regular expressions tools help you understand what's going on in a complicated regex expression/function, for example.
[+] [-] dash2|5 years ago|reply
It may be unfair, but as an academic, when I read "not Javascript" I thought, "oh yeah, seems cool, surely anything is better than Javascript" and then it hit me that they were gonna base it on EXCEL. The nightmare platform to end all nightmares. The software that's responsible for austerity [1] and for people dying of Covid [2].
OK, I'm sure this is unfair. Maybe Excel's underlying design is a great computing platform? Comments from domain experts?
[1] https://www.washingtonpost.com/news/wonk/wp/2013/04/16/is-th...
[2] https://warwick.ac.uk/fac/soc/economics/research/centres/cag...
[+] [-] protomyth|5 years ago|reply
IT people hate Excel because normal people can get work done, much like HyperCard and Flash before it. Perhaps someone will write a more IT friendly Excel without losing the users.
[+] [-] prionassembly|5 years ago|reply
Now, if programmers are unable to understand the logic behind Excel models to "productionize it", then we have a problem with the education of programmers.
[+] [-] voiper1|5 years ago|reply
>The study’s most conservative estimates suggest that the failure to contact trace is associated with more than 125,000 additional infections and more than 1500 deaths.
[+] [-] spawarotti|5 years ago|reply
https://www.microsoft.com/en-us/research/blog/lambda-the-ult...
> By Calc Intelligence, we mean the research goal of bringing intelligence to end-user programming. The spreadsheet of the future is a trustworthy collaborator and teacher.
> In December 2020, we announced LAMBDA, which allows users to define new functions written in Excel’s own formula language, directly addressing our second challenge. These newly defined functions can call other LAMBDA-defined functions, to arbitrary depth, even recursively. With LAMBDA, Excel has become Turing-complete. You can now, in principle, write any computation in the Excel formula language.
[+] [-] gjm11|5 years ago|reply
[+] [-] _dwt|5 years ago|reply
And then they go and re-enact Tony Hoare's billion dollar mistake, for no good reason that I can see:
> Some language such as JavaScript uses the concept of an "undefined" value for uninitialized variables or missing property. For simplicity's purpose, we have avoided this concept, treating instances that would be undefined elsewhere as either an error or a blank value. For example, all uninitialized variables start with a blank value. All data types can take on the value of blank.
This is the same spurious "simplicity" seen in Go, and I don't understand the appeal - especially coming from a team that clearly "gets it" when it comes to the importance of expressive types.
[+] [-] beaconstudios|5 years ago|reply
[+] [-] Mobleysoft|5 years ago|reply
As for Power Fx, in one particularly fun PowerAutomate flow I crafted for them, I wrote the following one liner to display a "percent complete" value for a given employee with regards to trainings they'd taken vs. trainings they were expected to have taken for OSHA compliance purposes. Parsing it is left as an exercise for the reader:
formatNumber(add(mul(float(div(sub( length(variables('TrainingsConducted')) , sub(length(split(variables('IncompleteTrainings'),';')),1)),float(length(variables('TrainingsConducted'))))),float(100)),float(0.5)),'##')
Low code, indeed.
Overall, I rate the POWERStack 8/10. It's not perfect, but it's fairly robust, not too difficult to reason about, and there are more than enough enterprise clients married to Microsoft to keep me in business for the foreseeable future. My only requests are to let me code Power Apps and Power Automate Flows fully in code-behind. I get that they're low-code tools by design, but in practice, they make things more difficult than they need to be for those of us who are quite happy to live in code, and I'd like to be able to build tools for automating the process for updating/adding functionalities to existing powerapps for those stakeholders that are on the absolutely-not-a-single-line-of-code-ever end of the development skill tree. Otherwise my business (in the Microsoft space) will remain bottlenecked by my time, and I'll have to dig elsewhere for my "set it and forget it" income stream.
If you need help building things with these tools/in this environment, feel free to reach out.
[+] [-] rowland66|5 years ago|reply
[+] [-] c-smile|5 years ago|reply
At some point, when Sciter (https://sciter.com) was young it was named HTMLayout - pure HTML/CSS engine without script. At some point I've decided to add a bit of scriptability/formulas directly into CSS so you might say (in CSS) for example this:
C++ developers (initial users) were excited of such level of configurability that allowed to add logic without writing "real" code. And I've started getting requests for conditionals like if-then-else, functions and other stuff like that.So CSSS! (css script) was born: https://sciter.com/docs/core/csss!.htm - it was even more powerful than Microsoft Power Fx - you can even define functions in it and operate with all data types of CSS.
The excitement ended when I've got a bug report with HTML/CSS document where one of focus!: ... handlers in that CSSS! spanned more than a page of printed and ugly text. So I've said to myself: it is time for scripting - anything, even JS, but with regular code flows and organization.
[+] [-] kevingadd|5 years ago|reply
I worry that a year or two down the road there will be production Power Fx applications hitting all sorts of problems that would have been prevented if there was a proper numeric type from the beginning. Computers are fast now, the average application can handle burning a few extra cycles on addition operations when updating a textfield if the alternative is a customer's account balance getting miscomputed.
[+] [-] nathanaldensr|5 years ago|reply
[+] [-] vsskanth|5 years ago|reply
Also why isn't python or a subset of js used for low code app building ? Why does it always need to be a new language ? Genuinely curious
[+] [-] hypermachine|5 years ago|reply
[+] [-] joenathanone|5 years ago|reply
[+] [-] im_down_w_otp|5 years ago|reply
It looks like Microsoft is a few steps closer to that kind of thing with Power Automate.
[+] [-] chaostheory|5 years ago|reply
[+] [-] mrbonner|5 years ago|reply
[+] [-] murukesh_s|5 years ago|reply
[+] [-] teddyh|5 years ago|reply
[+] [-] rchaud|5 years ago|reply
Power Apps are irrelevant to you unless you're heavily integrated with O365. And if you are, chances are that you're in a large organization. And if that's true, you hire a certified MS partner to handle maintenance, you don't leave it to non-technical staff.
At best, like MS Excel, staff can use the tool to prototype something, and then let the consultants figure out how to create a working solution that works across the whole org.
[+] [-] EvanAnderson|5 years ago|reply
A Customer (who frequently creates macro-laden Excel contraptions and byzantine nests of "linked" workbooks) was trying to automate some workflow between a third-party application and Excel.
The third-party application is a bit of a "platform" (a "let's re-invent Microsoft Access" data roach motel type application) and uses lots of owner-drawn controls masquerading as common controls (with no keyboard shortcuts). He was struggling to get the UI automation functionality to do what he wanted.
Having spent a "former life" writing VBScript automation code using "SendKeys", etc (and using various other macro automation tools) I explained that he was descending into the hell that is other people's Windows UI behavior, and that it often ends in frustration.
I expect that this platform will end up, like so many before it, being used to create inscrutable edifice in many companies. That edifice will be abandoned when the knowledgeable party leaves a company and nobody new wants (or knows how) to figure out how the junk works, or will become wildly mission-critical and have massive amounts of money poured into it to keep it working, lest civilization collapse (e.g. "The Machine Stops").
[+] [-] silvershell|5 years ago|reply
[+] [-] estsauver|5 years ago|reply
[+] [-] mring33621|5 years ago|reply
The only one that I have used that seemed any good was Labview, and even that is not really 'low code', just 'different code'.