mgummelt

I try to practice the 90m on, 30m off regimen that Huberman advocates, and it's worked well. I can do that all day without burnout.

There's a big difference between checking Twitter and sitting in silence.

That's easier than writing a GET request, but the easiest would be never leaving your native application, which AFAIU, RPA lets you do in theory (though practice is a different story).

Even then, if the YAML files can only be interpreted by Power Apps, then they can't be portably deployed.

Where are you seeing that it's a standard code format? I've skimmed this: https://powerapps.microsoft.com/en-us/blog/what-is-microsoft... and it seems that it's just a simple expression language, not a standard format that an entire PowerApps app would compile down to.

Ah, I see.

I wouldn't say API orchestration is the "new RPA", though. It's rather the "old BPM", and "current IPaaS". That is, we already have tools for API orchestration. It's nothing new. RPA is something different entirely.

And it's benefit isn't just for automating legacy systems. Automating the UI they're already familiar with is a much more intuitive experience for lots of people than going out of band to integrate with APIs.

:)

While I have you here, I have to say I still don't understand the connection you're making between PowerFX and compatibility with existing deployment systems. I understand that a low-code platform that spits out an app in some sort of standard format, like source code or a docker image, would facilitate that integration, but where does PowerFX come in?

None of these terms have widely accepted precise definitions, but there are plenty of platforms considered "low-code" that still require quite a bit of traditional programming. Outsystems, for example.

Those that only offer formulas with no escape route to traditional programming, as you describe, are more commonly considered "no-code".

This distinction from wikipedia is pretty accurate:

"No-code platforms are accessible to any end-business user while low-code platforms require professional developers who can work within the platform's constraints."

That's not how I'm thinking about it.

I'm not saying integrating with UI layer isn't fragile. I'm saying it doesn't offer a "moat".

Low code just means using visual techniques to replace or augment code, so any WYSIWYG system, including VB or XAML, qualifies.

Were you creating flows in Power Automate or something else?

It's interesting that the article's thesis is almost entirely about about PowerFX, but the 140 comments here so far don't even mention it.

Visual Basic is an overloaded term that can refer to both the language and the RAD IDE. The IDE was certainly low-code.

How is legacy compatibility a moat? Any RPA engine, certainly Microsoft's is going to cover the same stack. That's one of the consequences of RPA - when you integrate at the UI layer, you get compatibility for free.

What do you mean "implement this with a service account"? Aren't service accounts just a way to authenticate to APIs?

If by "this space" you mean RPA, then no. RPA platforms integrate with the target app's UI. Zapier (which typically is considered IPaaS, not RPA) integrates with the target app's API. It provides it's own UI to facilitate this, but it doesn't integrate with the target app's UI layer.

Companies will always confuse these terms as they fight the marketing wars. UIPath, for instance, refers to any RPA solution that includes API integration as "end-to-end RPA". But the substantive difference between RPA and IPaaS is whether or not the API or the UI is the point of integration.

Can you explain some of the terms you use a bit more?

You say that Microsoft's strategy is not about enabling the development of "enterprise applications". Then you say it's about providing tools for "business process applications". What's the difference?

Then you say it's not about providing tools for "applications" but rather "API integration and orchestration". Are you trying to say that the latter is about building headless processes without a UI? Don't a lot of processes require forms and human input? Aren't those "applications"?

"We need to decide if software is a car to be driven or an essay to be written." - Alan Kay

He goes on, of course, to argue that the car analogy is the wrong one.

The novel analogy is the right one, but it works against your point. Everyone needs to write. Few need to write novels. Just like increasingly everyone needs to write software, but few need to be engineers.

You want to log an integer to the console 100,000 times? Not sure why you would, but you can do that in a React event handler or lifecycle method.

React still requires you to write HTML and forms.

Can you give an example of a problem that would take significantly longer solving with React than with DOM manipulation?

That's not what "rational" means, in economic terms.

"The only choice we seem able to make anymore is the choice not to make anything."

"American manufacturing output is larger than ever"

Which is it?

static types, native builds, cross-platform builds

> Already with the release of Go 1 it was quite clear that Go has its best fit as a Server language.

CLIs as well. Before Go, how did you build a native CLI in a garbage collected language?

> This exposed Rob Pike's lack of experience in the area (IMHO) because anyone who had done any systems programming at all knew that garbage collection made any systems language a nonstarter.

What exactly do you mean by systems programming? Many successful databases (Cassandra, Kafka, ElasticSearch) are built on the JVM.

Well, no. The lambda calculus isn't imperative.