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.
Agreed. I got enthused about the Power Platform, with Power BI and Power Apps, mostly. With Power BI, you get a mix of Power Query M the DAX formula language, and then comes the power automate (flow) and power apps where you use this formula language that's still different. Too much to learn. I'm not even sure if the power automate formula language is the same as the one used in power apps. Confusing.
My firm is all-in Microsoft and I have to say it's not working. Power BI licenses are limited, Azure cloud cost are through the roof, anything you'd have run on a
proper workstation in the old days is retired 'since we have cloud' (as are tools like SAS, MATLAB and other end user modelling languages). As a non-developer but technically inclined person I've tried to find courses in non-obvious MS-software but couldn't find anything worthwhile. The pushback I receive for suggesting R or Python for modellong, stitching and automation is intense even though all juniors learn these tools in university. Microsoft lock-in is just crippling.
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.
I feel the deepest sorrow for anyone who will have to debug, troubleshoot, and extend byzantine overengineered apps. Iframes, multi-level loading spinners, piles of boilerplate code, browser lock-in, dozens of background calls to tracking, license and what-not services. The consultants paid by the hour, creating first mockups with this tool will have fun, no doubt. Non IT-savvy companies with too much cash will have an illusion that they have a working application, no doubt.
Your fears are not applicable in my experience. Model-driven PowerApps are schema and workflow driven, using one set of tools. The plumbing is all standardised. Authentication, authorisation and license management integrates directly into the M365 infrastructure that large organisations already have. As for browser lock-in, this makes no sense - Microsoft Edge has moved to Chromium. In my experience, the trend is for internal IT to use these tools directly, but it wouldn't matter even if a consultant did the work - the solutions are built on a standardised stack fully owned by the business. I wouldn't be surprised if a significant percentage of LOB applications are built on this platform in the next decade.
Because as we all know, learning the ins and outs of commands designed for teletypes with 50 years of incremental evolution, where the only common interchange format is ASCII, and all sitting atop kernels that think fork() is a good idea, is extremely pleasant.
Yes and no. Learning UNIX is a bit like learning LISP - the parentheses don't look "exteremely pleasant" but having (1) a shared serialization format (2) common programmatic interface (3) a culture of REPLs makes everything much more discoverable and gives you power you would never get where each interface is a shiny bespoke thing.
There a lot of kludges, especially around teletypes/terminals, yes. But the common interchange format being ~ASCII~ UTF-8 makes learning the ins and outs way more pleasant than if everything gets connected by COM, .dll APIs, inscrutable .inf files or whatever Microsoft thinks up at a given decade (you can notice I've stayed away for a while)...
Now Excel stands aside as as environment where learning _was_ pleasant, everything had an inspectable representation and a shared interface! Despite arrays bounds and reuse-by-copy-paste being messy, spreadsheets remain a sweet spot of bringing power to "low-code" users. I didn't look into this specific project enough to say where falls on lock-in-vs-interoperability scale, but IMHO the world needs more "spreadsheet plus" experimentation so I wish them the best...
Please share how a business user with spreadsheet-level tech skills is able to build a line of business application on *nix? Because that's what PowerApps makes possible.
To further this point, I know someone (who had little to no code exp) who at the start of this pandemic built an entire app to help his company deal with processing attendance and all the other things that suddenly appeared out of no where, using nothing but PowerApps and other O365 products.
Students, our future developers and power users, should not be locked up in their perspective, but be set free to choose the best for their future endeavors.
Sure, use the best tool. But the reality is nothing comes close to what Microsoft is building. As a consultant, when an organisation is already heavily invested in M365 then a PowerApp-based solution is a no brainer except for specialized requirements (eg low latency, complex or big data processing, etc.) The pricing model seems to be the only major issue I can see right now.
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 was not having the best time mental-health-wise anyway about 10 years ago. I was freelancing and writing an application for a doctor's surgery in C#, using some of the cool new toys they'd produced for it. Including Entity Framework. Which came with lazy loading of object properties, cool. Except I kept bumping into cases where the object hadn't lazy-loaded, and data I knew should be there, wasn't. Digging in through myriad stacks of documentation and notes, all of which said that data would be loaded if it was asked for without needing to load it, I finally bump into a small note, obviously written by an actual dev, that cheerfully pointed out something like "to ensure your data is actually loaded into the object, you'll need to call the loadData() method before using it" (I paraphrase from memory).
I lost it. I completed that project, then uninstalled Windows, installed Ubuntu, and started learning Go (I intended to also learn Rails and Python, but fell in love with Go's simplicity and haven't moved on since).
It actually helped with my mental health. Realising that at least part of my problem was that people were professionally lying to me was an insight I needed.
I'm never trusting a Microsoft technology again. It's always nice and slick on the surface, and then a twisting pile of mess underneath.
Note that the EF will not create proxies for types where there is nothing for the proxy to do.
This means that you can also avoid proxies by having types that are sealed and/or
have no virtual properties.</quote>
This is a common rookie mistake, unfortunately.
Entity Framework is an absolutely top-tier ORM (if you like ORMs). Because lazy loading is frowned upon by some purists (and DBAs), EF also support controlled/eager loading where nothing happens (lazily) behind the scene.
You can - for instance - in the query use <code>.Include(x => x.RelatedEntity)</code> to load a related entity eagerly without going back to the database server to load the related entity for each row (the so-called N+1 problem).
Because Linux is open about everything, but particularly about what works and what doesn't.
Working with Microsoft tech felt like being gaslighted by an abusive partner. Their documentation absolutely did not match what their tech actually did.
I'm really happy working in Go on Linux. Why would I want to switch back?
If the thing which would be intuitively obvious to 90% of people in your audience doesn't work, then your framework is wrong, not the people. It shouldn't take a mountain of documentation to clarify a basic feature.
There can be many "basic features" in a large framework that can't be made more intuitive without making the other features less intuitive.
Just because there are some unintuitive edge cases which you can identify in a technology doesn't mean the technology is "wrong". Pick your favourite technology and I am sure you can find many such unintuitive edge cases if you purposefully look for them.
I’ve had similar experiences with Microsoft’s documentation. My memory is fuzzy but one instance I can recall the documentation was clearly what was meant to be in the final product but most definitely was not what shipped. To make matters worse the docs as they were would often result in a configuration that worked on the first sync but subsequently failed or even caused the service to reach a permanent state of limbo where it could never finish starting. This left a lot of people thinking things were broken for other reasons.
They took ages to for them to finally update the pages. In fact it took a well known consultant, one of their mvps, writing not just documentation that worked, but also thorough instructions on how to fix the predicament Microsoft got you in. I wouldn’t be surprised if the team writing the docs were completely lost until they read his blog. The service was just one component but it was ridiculously complex for what it did. Sometimes I wonder if they crammed the service (Forefront Identity Manager) in to save the team working on it since they cancelled the standalone version of it.
Their docs can be good and are certainly improving but it does still feel like disjointed teams doing their own thing sometimes.
My assumption on this site is that most people talk from the perspective of devs. So I assume your experience with Microsoft's documentation is also on the dev side of things. I can't speak to that, I'm a sys admin so I have a different experience. And my job has me approaching technology from the opposite end. From what I have seen, Microsoft's is generally pretty good. Not the best but definitely far from the worst.
I’m afraid not. Those docs would have been used by both sides, especially for non-prod environments but they were definitely operations oriented.
I would agree they’re usually good but when they were bad, they were real bad. And bad seemed to happen a lot more outside of the “big” internal fiefdoms at the time (Desktop, Server, AD, Exchange, etc.).
They did seem to hit a rough patch during the transition but the only thing I’ve seen is gaps here and there due to what I assume is incongruity between teams. Like tools being moved from an installer and therefore the installer docs but corresponding docs for how to get those tools not being created/updated elsewhere.
I've always like C# for its multi-paradigm nature, good runtime, and excellent collections framework. It's basically what Java could/should have been.
Unfortunately the legacy tooling is infuriating to work with. It's been steadily improving for the past few years with the advent of .NET Core but in practice this doesn't mean much. If you work at a ".NET shop" then odds are that the devs that work there have been firing up Visual Studio and creating solution files for the better part of two decades; good luck getting them to use dotnet or Docker Compose, not to mention the long-lived legacy apps floating around that are still built that way and live on IIS in a corporate datacenter someplace.
Yes, C#'s greatest weakness is the tooling. There's no autoformatter, for heavens sake. (There are two in theory, but one is prettier's support for an old version of C# and one just doesn't work). And, yes, solution files and project=assembly are both absurd.
There's autoformatting tools in C# editors (VS, VSCode) and also the dotnet-format command-line tool for non-editing environments. Have you tried these?
The modern .NET tech stack has radically changed so much in the past 4 years that it's not surprising that so many folks are still having flashbacks to the old proprietary days.
Yeah but no. Linux is pretty open and honest about the twisting mess. There are years-long discussions about them. The Xorg/Wayland thing has been surfacing a few times on HN recently.
If you search for a Linux problem, you'll get 50 different people telling you 25 different ways of fixing it, most of which work.
If you search for a Microsoft problem, you'll get 50 pages of corporate bullshit that pretend everything's OK. You have to ignore those and dig further to find some unofficial blogger or random dev post that actually tells you something useful.
Also looking at you, Apple - less bullshit and more honesty in your support pages please
> If you search for a Linux problem, you'll get 50 different people telling you 25 different ways of fixing it, most of which work.
Not in my experience. They may have worked for some version of some distro, but it is almost always not the one I'm trying to fix the problem on.
> If you search for a Microsoft problem, you'll get 50 pages of corporate bullshit that pretend everything's OK. You have to ignore those and dig further to find some unofficial blogger or random dev post that actually tells you something useful.
Unfortunately that is also pretty accurate, and it has been getting worse since Windows 10, resembling more and more the problem with searching for solutions to Linux issues. Does this fix still work for 1901 or did it only work for 1607?
> You kind of just described Linux, Unix, modern Web dev, iOS dev, Android dev etc.
More devs seem to have this opinion of Microsoft technologies though. Their desktop OS is the most dreaded as a platform, and the most dreaded of any OS except for Android (by 4‰, and of course devs already killed Windows Mobile)¹. And even more relevant to the link we’re discussing, another relatively low-barrier-to-entry language they created is the single most-hated programming language there is².
That is interesting. I assume it's because corporate takes over and honest communication is no longer possible when the financial stakes of admitting error become too large. But I could be wrong.
I am pretty sure the reason Stack Overflow was created is to provide help understanding what MS code actually does vs what MS documentation says it does. They just happened to hit on a formula that was useful for other people too.
I remember participating in a Microsoft sponsored meeting when LINQ to SQL just came out. Failed to have an answer on how to reasonably implement paging.
I was always ORMphobic person and especially I afraid EF. This framework lets you think query DB is easy and you don't have to dig into details, but it always turns out you have to know how the DB works plus you have to learn how EF works internally. I am trying to stick with micro-ORMs, like Dapper or something like SQLBuiler. Raw SQL is no good too.
I've experienced similar when working with android's api. Docs say x should work, but it's just not happening. Five hacks later, and you've got a working app that feels choppy. Granted this was back in the 4.4.4 days, so things may have gotten easier since then.
To be honest I can't remember (and I'm definitely not going to look). It was pretty early in the development of EF - I understand that this problem no longer exists and lazy loading works fine now.
Which I would totally have understood and forgiven if they'd been honest about it. But all the documentation was lying, except this one tiny bit buried deep in the tech docs. That wasn't the first time I've encountered this phenomenon in Microsoft tech. It seems there's a mis-communication between the documentation team and the actual dev team, and they end up documenting what should happen instead of what actually happens.
You said yourself that the lazy loading actually did work most of the time except for these problem cases, right?
So doesn't that sound more like it might just be an unintentional bug or maybe you had your environment configured differently from what the docs were expecting?
It really sounds to me like you threw the baby out with the bathwater over a small bug, when bugs of a similar magnitude will likely be present on every other platform too (including documentation bugs)
I've never used EF or developed business apps in .NET, but I have used similar technologies like Hibernate in Java and I think you are basically describing standard caveats with any ORM. Lazy loading is often a non-obvious behavior.
If your documentation says in several places that your system does X, but it doesn't, it does Y, then that's lies.
It might be caused by a bug, and what you're documenting is intended behaviour not actual behaviour. But then you need to say that somewhere - something like "We expect the system to do X but we haven't actually tested it so it might not". Not saying that, and instead saying "the system does X" is lying.
And yeah, I stopped using ORMs too :) They just get in the way.
With this definition, every software which has undocumented bugs (i.e. every software) is lying. That doesn't seem useful to me and I don't see how the problem is solved by moving away from EF either.
No, I think there's a difference between undocumented bugs and professional documentation that very clearly documents behaviour that doesn't actually match what the system does.
As others have said, it's a problem that's particularly apparent with Microsoft - it feels disjointed. Like the documentation team read a different spec than the development team.
No, but I do have a longstanding annoyance with the general form of argument in which technologies are dismissed just because they have some weird edge cases. All substantial technologies have weird edge cases.
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.
> Everything (containers, widgets, etc.) is basically SVG's
Controversial opinion: vector-based UI widgets are the right way to do web apps. Instead of all the existing framework approaches that ultimately produce HTML, both developers and users would be better served by using HTML for the elements on a screen that correspond to documents, but the web app's "chrome" should use SVG. Most of the complications of frameworks come from a blind spot on the part of developers, who continually select a tool with a high impedance mismatch to their goal (producing an app). This blind spot on the part of developers leaves this area under-explored, and in turn there's under-investment in the specs / on the part of browser makers to eliminate pain points in the way that developers are actually using the platform for their work.
The problem is that SVG doesn't AFAIK support layout constraints - you'd have to essentially recreate flexbox and grid in JS, and God forbid you wanted to make the design responsive!
I agree with you in principle that SVG is a better match to app UIs, but we'd need a good layout story for that to happen. And I'm using SVG for much of my own application interface!
ideally, an SVG layout optimised for web app design would be somewhat more flexible than just grid and flex - such as anchoring an element to 2 other separate parents (or in other words, supporting a directed graph rather than a tree). A pure constraint system would be nice, but is probably not viable if fast rendering is important (which, it is).
I went down that road for awhile. You start running into problems when you research all of the default behavior that the built-in widgets have, and this is even before you get to accessibility issues.
I love the idea of punting on HTML and writing a ground-up SVG UI toolkit, or even a WebGL based on if you're feeling ambitious, but giving up on the built-in browser behavior and all of the automation tooling around interacting with HTML is a non-starter for most use cases.
Interesting, if SVGs make sense, then a new game-engine-like client makes more sense as a general delivery platform. Maybe Dart/Flutter/Fuchsia isn't far off.
- 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.
Ok, so, what should a software dev who hasn’t worked with power platform before look at to get up to speed on the proper way to use it with their own api’s?
I have to flip between Chrome and Firefox depending on which bugs in which product I need to avoid :-)
My favourite one is a bug in Flow where you paste a string and the entire UI goes in to an error state (can't even save) so you have to reload and lose any existing changes.
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.
I mean, yeah, great ideal, but that doesn’t appear (to my superficial look at it so far?) appear to be anything other than an ideal.
I can also aspire to build a platform which enables everyone to prototype and then also run it in production with no performance issues, where “pro developers” can just pickup where “casual developers” left off on the prototype.
...but I’m not really interested until someone actually does it, rather than just talking about it.
The power platform is a lot of PowerPoint and sales talk so far from what I’ve seen, but with what seems of actual implementation always rolling back to Q2 next year when you ask for the details...
I mean maybe you got further than me down the rabbit hole than [1], but yeah... I can modify some of the display javascript as long as I use the API and do not interact with the DOM is 100% not a killer feature.
Microsoft has a lot of history building platforms for novices to produce functional systems.
This one seems to be going in an open source direction, and building upon web standards. This gives it a much better chance of success.
Obviously it requires investment, and there is no certainty of success.
But even just a carbon copy of an existing project like Access 365, but an open source version that targets the web would be very useful. Especially if it could be extended with .NET and put into version control. Although there are competitors in that space.
Reimagining the entire Rapid Application Development model is riskier for sure.
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.
I don't see what your child comment has to do with my parent comment.
- You brought up "OnSelect" and binding "this" in JS, but they don't seem related to picking one way to propagate state through a GUI (either "push", "pull" (signals and slots), pseudo-immediate-mode and state diffing (React), FRP, property binding, ReactiveX, or something else).
- https://blog.maximeheckel.com/posts/swiftui-as-react-develop... does discuss state, but you brought it up in the context of app layout. App layout is another area with multiple choices, but it's more linked to visual design, and less to functional correctness (which is vulnerable to state-propagation bugs which I was talking about).
- Automated code updates, and test generation, are not related either.
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.
I'm sympathetic, especially given this was core infrastructure for a nationwide emergency. But, how many people do actually know the row limit? It's easy to say experts know it. But is it discoverable from within the interface? If you're a management consultant Excel jockey, is there a way you would have learned about this before tripping over it?
>IT people hate Excel because normal people can get work done
This is arguably more a business problem, but there's real issues when people coming/going and then having to get familiar with dozens-hundreds of spreadsheets. Maybe if they're good at Excel, they just pick it up easily, I dunno, but I've rarely seen stuff like confluence documentation and edit history and other supporting docs for spreadsheets that are critical to the company. It kinda feels like they rely more on tribal knowledge than devs.
Nothing about our languages or tools constrains devs to necessarily do this too, we've just got a culture of doing that stuff because we know how awful life is without it. Maybe it's different for spreadsheet people though. I could just keep the business code on a single hard drive and deploy by copy-pasting over a network share or through email, but you'd rightly call me mad.
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.
> The binary representation of a Decimal value consists of a 1-bit sign, a 96-bit integer number, and a scaling factor used to divide the 96-bit integer and specify what portion of it is a decimal fraction. The scaling factor is implicitly the number 10, raised to an exponent ranging from 0 to 28
Because Python and JS are extremely difficult to use and extremely hard to understand for most cases that a user with no training in programming would have.
Most people who have been programming a while disregard what a huge barrier to entry syntax is. Python's bizarre white-space sensitive syntax is especially bad for this kind of embedding. Another huge barrier to entry is the need for explicit iteration - the much more beginner-friendly option is to express operations in terms of their effects on the "selected" element in a list, or on the whole list, relying on the programming environment to actually handle the iteration.
Overall, I think the approach taken here, of offering a beginner-friendly programming language AND environment, which exposes the resulting code as a data structure and not an opaque script, has some of the best chances of taking a PoC built by a domain expert and actually turning it into production software. Even better, it greatly expands what a user can do without ever reaching for a programmer to do it for them.
I think your question is a good one, and one that a vast majority of times it's just people or companies wanting to invent something for the sake of inventing something. IN this case, the posted link to the repo is unfortunate because there are so many better links to the announcement.
Probably being cynical. But I wonder if the purpose of PowerApps is to create a platform that seems safe to IT managers in corporations. Using a real language makes people stress about security and maintainability. The simplicity makes people assume that the product will only be used in safe ways. Whilst semi-supported "shadow IT" types use it in unexpected ways.
They address the origins of the language. It was designed for Excel-like usage in low code apps. Presumably it’s not a “new” language but a use case expansion of the Excel stdlib and runtime targets.
I think it’s mostly about the user, in this case the 1 billion users that know Excel, and would like those same functions available for integrating the modern web.
That may be the case, but that's not the reason for this one. Read up a bit on the reasons MS had. At the very least it's not a trivial "not invented here".
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.
Because current low-code development tools boxes you in and are extremely inflexible. They are walled gardens, antithetical to general purpose computing. JavaScript and Python are ultimately not as beginner friendly as they like to claim to be [0]. Dependency management problems (Python), various footguns from the earlier days (JavaScript), difficult to rapid prototype UI and CRUD systems (both). VB and VBA are tried and tested technologies (the alternative I have considered is Lua, but Lua's ecosystem is fragmented because of the focus on embedding). Their current high popularity is in spite of Microsoft's attempts to deprecate and move users to .NET and JavaScript. They are possibly the world's most successful low-code platform.
Embarcadero Delphi has become irrelevant, SAP is not accessible to most consumers. The newer generation of platforms like Retool and Bubble are all designed with software engineers first in mind when it comes to extensability and customisation; they are very inaccessible to layman if you stray from the well-beaten path. They all force you to choose between a false dichotomy of either pure GUI and no code, or an obtuse API that requires a CS degree and five years of fullstack software engineering experience to understand.
In VB6/VBA, calling Windows DLL via COM was trivial. The entire power of the operating system was at your disposal in a few simple readable lines. I want to make a similar system for the modern web and APIs. iOS's Shortcuts may look pretty but they are a step backwards from the HyperCard days.
[0] The litmus test I use is this: Can I teach somebody from a non-STEM background how to code and more importantly get them to integrate it in their own workflow in an afternoon? With VBA/VB6, yes. Everything is a click away. They had hot reloading in 1995. It took JavaScript 20 years to reinvent the wheel. Good luck explaining even how the packaging dependency system works with Python.
Since Python is the most popular beginner language, I am also inclined to point out that their standard for "rapid prototyping" is Django. Your average Excel user is more likely to throw together a quick app in VB than study Mozilla's "Your Local Library Website" Django tutorial just to build a CRUD app.
In fact what I have learned doing a couple of consulting projects for a life sciences companies, is how many of Excel VBA powerusers eventually get IT to give them VB.NET and carry on from there.
They don't think twice about adding the DLL/COM libraries required to access the laboratory data readers for accessing cell data values.
VBA's biggest weakness is that its open source community and ecosystem is non-existent, so you always end up remaking the wheel. It's just easier making either python or javascript the default franca lingua.
imo that’s worse than python’s largely solved dependency management issues. Most people just use conda and it’s good enough. Is it as good as competing languages? No, but it’s still better than VBA’s ecosystem (including your solution) by miles. That said, I think it’s awesome that you’re still supporting VBA veterans since MS left them out in the cold.
That's a separate issue from dependency management entirely. Check out Repl.it's universal package manager if you want an idea of how we are solving the problem.
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.
I have it intergated with an on prem SQL server, no issues. When a new client is added to the SQL database a flow triggers, that creates Sharepoint folders with the clients info, also creates a planner tasks list for the intake process.
I also have a flow that brings the Planner tasks back into SQL so that I can dyanically create links to the Planner tasks list in the SQL database frontend.
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).
If the web would be sound tech instead of this steaming pile of... whatever it actually is at this point in time, these kinds of RAD tools would probably now exist for the web and be better for it instead of being forgotten. They weren't perfect and random people created ugly beasts in them, but the process was fast and the results were often good enough.
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'.
low code is just higher-level code, and that's fine. The whole point is to make the domain of programming more accessible to people who haven't made it their career.
I was thinking the same thing. Looking at this, it seems in some ways more primitive and less principled than what they were planning, but on the other hand, this is actually being shipped. Power-Fx seems to separate out the relational data from the GUI. But it has relational data and it's reactive so it's most of the way there I suppose.
OoOooOoooh, I need to read up on this. Just found the blog via this pointer, and it's in alignment with some of my thinking... just a bit different.
I believe in the power of good reactive programming as Excel is amazing, and this Power-FX is looking really cool. I'd be concerned about how it fits within the larger engineering world versus the Microsoft universe, but I built a programming language that is reactive from the get-go.
I agree. Although I do believe that the schema needs to be designed first class for writing / programming, before considering what render model and edit GUI will manipulate the schema. Making the app schema first class for writing, ensures that who ever read / writes the code can predict the app behaviour with ease.
I've seen multiple platforms do this the other way around and before as a result the GUI is in full control of the app schema and you end up with machine generated config which is hard to debug, reuse, review and edit.
While designing the app schema for Lowdefy [1], we are only implementing the app schema by coding it by hand - all the time (at least until all best good practices are established). This ensures that we always implement predictable defaults and that we make sure that developers only write the minimum config to be able to create an app. No unexplainable / magic paramaters in any the schema.
We also implemented a MongoDB like query model in the YAML (Lowdefy operators), and we are often surprised by the level of complex logic that developers construct with ease.
This Power Apps thing looks a lot like Access, reinvented for the web an mobile apps. I've always thought the world missed a lot when everything moved to the web and Access became less used. For me Access was one of the first "no code" or "low code" precursors. True, it had its quirks, but Power-Fx seems to be fixing that.
Not directly related, before I got into learning web eg. HTML/CSS/JS. I put about 6 months down into this thing MS made called Touch Develop. I was able to make apps and figure out how to do stuff but I pretty much ended up scrapping it/not proceeding further. Maybe it helped me learn in the long run... Idk it was neat though.
I've dabbled in programming for years, know some C, C++, Basic, python.. If I wanted to start to make a real useful program I'd like to start with one to configure Windows settings to my liking.. Auto login, turn off ads, net reset. Anyone have suggestions on how to start? outside of a folder of Powershell scripts?
I've built some things in Power Apps over the last few months. Not the most pleasant experience. Anyone tried to get non US date formatting to work? Please tell me if there's a simple solution.
Occasionally I'll have flashbacks to a younger me doing a similar thing in Access with VBA 15 years ago.
[herewegoagain.meme]
I feel like we've been through this with COBOL, SQL, and...well, lots of things, so I'm skeptical of a “low-code [general purpose or otherwise] programming language” even if it is “expressed in a human-friendly text.” [0]
At best, these things usually end up as decent programming languages for professionals that end-users avoid like the plague. At worst, they end up as giant dumpster fire where people are lured into a doom of unmanageable code, as it seems easy enough to build sloppily until it's overwhelming and unintelligible. The other features (declarative, functional, stro gly typed) give me some hope it's not a total disaster, but...
sorry to steal topic a little bit. I am a backend engineer and usually create an API stuff for our frontend engineers. Tried to work on my side project recently and pixel perfecting front end and adjusting it to mobile seems very time consuming task.
Are there any services I can use as a drag and drop front end builder and connect data population to my backend? checked out wix and webflow, they both seem to require storing data on their side and most of tutorials are showing how to populate that datastore with airtable or zapier, which is not an option for me.
Hey, I run Nocode.tech and can probably give some advice here - No perfect answer sadly but a few to try
First, Worth noting you can export Webflow as code and rehost it wherever you like if that’s helpful. BusyWorkHQ hasn’t launched yet I don’t believe, but it’s a backend builder for Webflow and may help you solve your problem by letting you connect a database/api thru to Webflow. @PatrickStolc on Twitter is building it
Have a look at Adalo - They have the ability to replace their backend with an external database (it’s a little bit tucked away but it’s there). The downside is that the front end parts aren’t as freeform as Webflow. They’re more focused on mobile but support web apps too
You may also be interested in React Studio, Wappler or UIBakery
> you can export Webflow as code and rehost it wherever you like if that’s helpful.
this sounds good starting point for me, I am guessing in this case I need to render HTML on server side or add some additional code to exported source code to be able to render data front end on browser side.
Yeah, you would need to use something like Pug.js to render the data.
As an alternative (and possibly easier imo), you could add custom JS code on Webflow (it has an embed function) to hook onto its dynamic list functionality and add your own data inside.
In other words, create a list on Webflow with one item in it designed the way you want the final data to look. Then use JS code to override the data on that page with your own data source and to duplicate the list item as many times as you need for your data source
damn, MSFT Compiler & Programming Languages & Research Teams seems like dream place to work
those people seems to be unparalleled when it comes to programming languages, I'm not sure about compilers and runtime because JVM/GraalVM are impressive as hell, but I think Roslyn stands
Sweet. How do I connect it to data lake on autoscaling self-healing cluster? Also I would like to lock the app to work on Edge on Windows 10 only, where is a checkbox for it?
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.