Comment by thristian | Hacker News Reader

Comment by thristian | Hacker News Reader

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.

Microsoft already has "Power Query", aka "M".

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.

Ah, the even more confusing language. Just give me C# or a decent Python experience. Power Query is terrible.

May I ask what is your issue with PowerQuery? I found it extremely useful tool for transforming the data and display it the way I want see.

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.

Power Bi is nice, but expensive.

You need a costly instance as soon as you go more advanced.

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.

Agreed. Power BI seems cheaper than Tableau or other options, but you end up having to get licenses for everyone just to let them view content.

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.

This kind of vapid triumphalism adds nothing to the conversation.

Oh, it did add something for me. It actually triggered som perspective thoughts I otherwise wouldn’t have had.

I don't find that comment to be vapid at all -- it describes a real phenomenon that has occurred in the past and seems likely to be occurring again.

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.

>> As for browser lock-in, this makes no sense - Microsoft Edge has moved to Chromium.

In practice, it absolutely makes a difference.

The Xerox PARC and VMS worlds are a much better option.

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.

You could interpret the comment as:

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.

I can’t argue with that. That was not my point.

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.

Microsoft has a lots of good stuff. Judging them by their worst offering is like judging *nix by it's worst.

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...

Reply on news.ycombinator.com