4 ms·

I notice you've used two different programming languages to express application logic. A the high-level, you have automations, which are simple but look very li

I notice you've used two different programming languages to express application logic. A the high-level, you have automations, which are simple but look very limited in terms of capabilities (i haven't studied this part in great detail, but does its support things like looping, arbitrary conditional expressions, and an abstraction mechanism like user-defined functions?). At the low level, you have JavaScript to do fine-grained data manipulation, which is often necessary to take care of details like computing summaries of data or transforming between different formats. I've seen this approach used in a lot of different workflow systems over the years, and it's always struck be as awkward. Have you considered designing the automation language in such a way that it is sufficiently expressive to cover the full range of needs for apps, from the high-level aspects to the low-level details? The approach I prefer to use is to pick a suitably generic language (generally based on a formal process calculus and extended with useful primitives). I'm on my second round of doing this now (first as an academic research project, now in industry) and in both cases it's been based on lambda calculus (and in the industry project, based on Scheme). The language constructs and model of computation are identical whether you're implementing high-level aspects of the workflow logic (a sequence of steps, with optional conditional branches, looping etc) and low-level aspects (iterating through a list of numbers to compute the sum). One language + interpreter takes care of both. I discuss this approach in Chapters 2 and 3 of https://www.pmkelly.net/publications/thesis.pdf https://www.pmkelly.net/publications/thesis.pdf.

shogunpurple 5y ago
Hi Peter, Automations are simple by design - the general automation steps are kept simple so they are easy to configure and create. We do however have a JS and a bash automation block. These blocks let you perform looping, iteration and logic using either JavaScript or bash. The reason we use JavaScript is simple. Most software engineers can write or at least express simple constructs in JavaScript. Being a C family language, this makes it easy to pick up for engineers who have been exposed to other languages like Java, for example. The problems you are describing are actually something that we have felt before, when budibase did not have JS support, we had users reporting that the templating/handlebars syntax was not good for logic, and was new to them. It was esoteric and required in depth knowledge for advanced use cases. Using an off-the-shelf high level or more specific expressive language has some serious drawbacks, especially if you create it yourself. The first is education - writing extensive docs around how to write and use that language. The next is maintenance - maintaining your own custom PEG grammar or programming language is a huge project in itself, not even including the research required to execute it well. By using JavaScript, we can leverage the already existing plumbing for executing JavaScript, and provide something that has much for familiarity to the general user.
- claytongulick 5y ago
  I'm currently evaluating this for use at our healthcare company, and I can tell you that 100% of the reason why I'm even willing to consider a low code platform like this is because of the excellent job you've done with open source, and the fact that it fits in seamlessly to our existing nodejs and javascript environment and skill set. Had you guys made the decision to create your own grammar/DSL, it's very unlikely that I would be seriously considering using it.
gervwyk 5y ago
I’ve read your abstract and it looks very interesting! I’ll be diving into the rest as I find time over the next few weeks thanks for sharing! And well done on this piece of work! It was interesting to me that you mentioned “functional programming as a model for data-oriented workflow languages”. I find it interesting because we are building Lowdefy [0] with which you can express feature rich apps in yaml / json, and have been considering how to implement DAG type stuff in future versions. We’ve taken a lot of inspiration from Mongodb aggression query language and as a result built a json / yaml parser which evaluates functions (operators) to implement logic throughout the app. This proved to be extremely flexible, easy to use for data manipulation, and surprisingly performant as we can actually evaluate the expressions during the render loop. Going to read more parts of your thesis. [0] - https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy
- claytongulick 5y ago
  > Mongodb aggression query language I think this is my favorite typo/autocomplete of the year.
shrimpx 5y ago
Why not use a full blown programming language? The higher level workflow stuff can be a library.

shogunpurple 5y ago

Hi Peter, Automations are simple by design - the general automation steps are kept simple so they are easy to configure and create. We do however have a JS and a bash automation block. These blocks let you perform looping, iteration and logic using either JavaScript or bash. The reason we use JavaScript is simple. Most software engineers can write or at least express simple constructs in JavaScript. Being a C family language, this makes it easy to pick up for engineers who have been exposed to other languages like Java, for example. The problems you are describing are actually something that we have felt before, when budibase did not have JS support, we had users reporting that the templating/handlebars syntax was not good for logic, and was new to them. It was esoteric and required in depth knowledge for advanced use cases. Using an off-the-shelf high level or more specific expressive language has some serious drawbacks, especially if you create it yourself. The first is education - writing extensive docs around how to write and use that language. The next is maintenance - maintaining your own custom PEG grammar or programming language is a huge project in itself, not even including the research required to execute it well. By using JavaScript, we can leverage the already existing plumbing for executing JavaScript, and provide something that has much for familiarity to the general user.

claytongulick 5y ago
I'm currently evaluating this for use at our healthcare company, and I can tell you that 100% of the reason why I'm even willing to consider a low code platform like this is because of the excellent job you've done with open source, and the fact that it fits in seamlessly to our existing nodejs and javascript environment and skill set. Had you guys made the decision to create your own grammar/DSL, it's very unlikely that I would be seriously considering using it.

gervwyk 5y ago

I’ve read your abstract and it looks very interesting! I’ll be diving into the rest as I find time over the next few weeks thanks for sharing! And well done on this piece of work! It was interesting to me that you mentioned “functional programming as a model for data-oriented workflow languages”. I find it interesting because we are building Lowdefy [0] with which you can express feature rich apps in yaml / json, and have been considering how to implement DAG type stuff in future versions. We’ve taken a lot of inspiration from Mongodb aggression query language and as a result built a json / yaml parser which evaluates functions (operators) to implement logic throughout the app. This proved to be extremely flexible, easy to use for data manipulation, and surprisingly performant as we can actually evaluate the expressions during the render loop. Going to read more parts of your thesis. [0] - https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy

claytongulick 5y ago
> Mongodb aggression query language I think this is my favorite typo/autocomplete of the year.

shrimpx 5y ago

Why not use a full blown programming language? The higher level workflow stuff can be a library.