[dsanchez97]

I agree with most the tradeoffs that were brought up with "low code" integrations tools, but I feel like none of the tradeoffs of using a general purpose program language were discussed. My viewpoint is that most organizations reach for these solutions because they provide highly available runtimes that people can quickly access.

If I am at an organization and not directly on a software development team and want to do a simple data transformation between two systems, how would I go about getting an environment to run my process? Even if I know how to write it using a general purpose language there are probably too many steps to go through to get a server environment to run my code on. With a low code solution, I can get my simple process running and automated much easier.

A little while ago there was an article about the python environment run at big banks that allow banking analysts to easily use python to solve their day to day problems. The banking python system was built to allow these people to quickly write python without much organizational overhead and therefore saw wide spread adoption among non traditional software developers.

I have been thinking about this space because I am trying to build a platform on top of serverless (FaaS) platforms that would make it easy for companies to empower workers to use general purpose programming languages to solve their business problems.

[lmm]

It's the configuration complexity clock all over again. Code errors cause outages, then we impose a bunch of process and restrictions on code deployment, then we make our code configurable so that business users can easily change the behaviour, then configuration errors cause outages.

[hoten]

The referenced article on Python in banking: https://news.ycombinator.com/item?id=29104047&p=2

[mpweiher]

> none of the tradeoffs of using a general purpose program language were discussed.

Yep. And particularly the fundamental issue of so-called "general purpose" programming languages:

  They are *not*, in fact, general purpose.

What we call general purpose languages are, in fact, DSLs for the domain of algorithms. See ALGOL, the ALGOrithmic Language. But we think they are general purpose, because that's what we use, lacking other options. And this mistaken categorisation leads us to the incorrect conclusion that things that aren't handled well by these "GPLs" must therefore be handled by DSLs. Or Domain Specific Tooling.

Which in turn leads to the problems described in the article, because it's all far too domain specific.

The answer, IMHO, is to make languages that actually are general purpose and not just algorithm-DSLs. That can handle integration without being integration-DSLs.

My stab at this is http://objective.st/

[Stranger43]

How do you get time/instances on an no code platform?

This problem was solved in 80ies on most timeshare platforms(read unix) where you would simply let users access an general purpose environment on a shared server and run processes in the background or kick up batch job using some kind of scheduler(crontab).

The old unix "shell account" should really be the benchmark for FaaS to beat and so far i dont think anyone have gotten close for small scale project.

[pjmlp]

On SaaS providers where Cloud Shell is the new telnet and the browser the X Windows replacement.

[Stranger43]

Which providers?

My experience is that my first cgi-bin script were about a order of magnitude easier to deploy that anything other then say a traditional php/mysql script. and i had the flexibility to use basically any programming language back then too.

I did not have to learn git, figure out how the cloud router used worked, i just had to place a file in a directory. For crontab it was the same dump the script to a directory edit the crontab file and it worked and it was the same no matter who i bought the service from.

Sure there were scalability issues, and the security was questionable but in terms of ease of use are we really moving forward?

[pjmlp]

Since you gave a cgi-bin script as example, assuming you have an Azure Cloud account, you can easily do it via , provided it is written in JavaScript, PowerShell, TypeScript, or C# Script.

https://docs.microsoft.com/en-us/azure/azure-functions/funct...

Here is video tutorial

https://www.youtube.com/watch?v=1A7vp3zAB9U

Or in the context of low code tools, Azure Logic Apps

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps...

[Stranger43]

And this is the equivalent for cgi-bin "vi ~/public_html/cgi-bin/hello.sh"

And the code itself did not contain 10 lines of vendor specific scaffolding to run either but were straigt onto the business logic.

Where is the platform where i can take an completely standardized scriptfile use my preffered ftp/scp client and upload it into an runtime configured to run inside of the corporate firewall?

[pjmlp]

You are missing having IT set up a UNIX server instance, with Apache or NGINX on it, configure firewall, public IP DNS entry, and then having the rights to ftp/scp into it before being able to call vi into hello.sh.

So if you want that approach then, IT would set an "static HTML web app" instance for "~/public_html" version, which you can then ssh into.

https://docs.microsoft.com/en-us/azure/app-service/configure...

or have a VSCode like experience editing directly your site files,

https://social.technet.microsoft.com/wiki/contents/articles/...