4 ms·

We’re building lowdefy: https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy A low-code tool that let’s you build web apps using yaml. In v4,

We’re building lowdefy: https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy A low-code tool that let’s you build web apps using yaml. In v4, you config is run in a lightweight nextjs app, so should scale as well as nextjs for the most part. A lot of the issues that people are talking about in this thread have been address, mostly because with lowdefy we’ve focused on making the schema easy to read, write and understand. Currently we write all our apps by hard coding the yaml, and it’s scaling really well in our team. For writing apps in yaml, you get advantages like: - Apps follow a structured schema, thus easy to pick up where others left off. - Nothing is hidden in a GUI. You can copy, paste, find, replace, review changes, duplicate repos, etc. - Create and manage apps with code, develop scripts, like automating app updates. - YAML / JSON files work with all dev tools, devs are more efficient when they use their favourite tools. With Lowdefy v4 you can extend blocks, operators, actions, connections, adapters and providers with plugins, because sometimes custom code is the right solution. We’ve built enterprise level CRM and MRP systems using Lowdefy and our clients love how fast we ship features that they need in their business processes. It's really working well for our small team!

GrumpyNl 4y ago
There will always be that edge case where the low-code is not sufficient, that's where the problems start.
mhitza 4y ago
Greenspun's tenth rule seems applicable here [0] > Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I write a lot of Ansible playbooks (yaml as well), been doing that for almost 10 years and I still have to jump to the reference manual. YAML DSLs are a pain to work with. Jetbrains software might have a plugin for GitHub Actions, Ansible(, and what have you), etc but that only makes slightly bearable. I think you might be to close to the core of the project to see that YAML without some autocomplete (intelisense) support is a though environment to work in. [0] https://github.com/lowdefy/lowdefy-example-case-management/blob/main/requests/fetch_tickets.yaml https://github.com/lowdefy/lowdefy-example-case-management/b...
- mbrodersen 4y ago
  > Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I call BS on that “rule”. 25+ years of experience here working on very large C/C++ code bases used by large commercial companies. And I have never ever seen this happen in practice. I know that the often cited “rule” makes some Lisp fans feel all smug and superior. But it doesn’t seem to be based on reality.
  - jasim 4y ago
    The rule, for a YAML-based no-code tool, would be: "Any sufficiently complicated descriptive-declarative programming language contains an ad hoc, informally-specified, bug-ridden, slow implementation of a Turing-complete programming language". In Concepts, Techniques, and Models of Computer Programming, Roy and Haridi define descriptive-declarative programming as: "The declarative 'program' just defines a data structure. This language can only define records! For example, defining graphical user interfaces. Other examples are a formatting language like HTML (Hypertext Markup Language), which gives the structure of a document without telling how to do the formatting, or an information exchange language like XML (Extensible Markup Language), which is used to exchange information in an open format that is easily readable by all. The descriptive level is too weak to write general programs. So why is it interesting? Because it consists of data structures that are easy to calculate with. HTML and XML documents, and declarative user interfaces can all be created and transformed easily by a program."
  - mhitza 4y ago
    I find that quote true regarding the linked example yaml. Applying it globally might as well be BS. Where I've seen it in practice is in software that allows end-user configuration. At the intersection of classic directive oriented configuration and the dynamic configuration file, but not quite an embedded language. Another example is when you allow users to input rules, or have rule builder systems. You're going to build something similar to a lispy evaluator fir those rules.
    - mbrodersen 4y ago

GrumpyNl 4y ago

There will always be that edge case where the low-code is not sufficient, that's where the problems start.

mhitza 4y ago

Greenspun's tenth rule seems applicable here [0] > Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I write a lot of Ansible playbooks (yaml as well), been doing that for almost 10 years and I still have to jump to the reference manual. YAML DSLs are a pain to work with. Jetbrains software might have a plugin for GitHub Actions, Ansible(, and what have you), etc but that only makes slightly bearable. I think you might be to close to the core of the project to see that YAML without some autocomplete (intelisense) support is a though environment to work in. [0] https://github.com/lowdefy/lowdefy-example-case-management/blob/main/requests/fetch_tickets.yaml https://github.com/lowdefy/lowdefy-example-case-management/b...

mbrodersen 4y ago
> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I call BS on that “rule”. 25+ years of experience here working on very large C/C++ code bases used by large commercial companies. And I have never ever seen this happen in practice. I know that the often cited “rule” makes some Lisp fans feel all smug and superior. But it doesn’t seem to be based on reality.
- jasim 4y ago
  The rule, for a YAML-based no-code tool, would be: "Any sufficiently complicated descriptive-declarative programming language contains an ad hoc, informally-specified, bug-ridden, slow implementation of a Turing-complete programming language". In Concepts, Techniques, and Models of Computer Programming, Roy and Haridi define descriptive-declarative programming as: "The declarative 'program' just defines a data structure. This language can only define records! For example, defining graphical user interfaces. Other examples are a formatting language like HTML (Hypertext Markup Language), which gives the structure of a document without telling how to do the formatting, or an information exchange language like XML (Extensible Markup Language), which is used to exchange information in an open format that is easily readable by all. The descriptive level is too weak to write general programs. So why is it interesting? Because it consists of data structures that are easy to calculate with. HTML and XML documents, and declarative user interfaces can all be created and transformed easily by a program."
- mhitza 4y ago
  I find that quote true regarding the linked example yaml. Applying it globally might as well be BS. Where I've seen it in practice is in software that allows end-user configuration. At the intersection of classic directive oriented configuration and the dynamic configuration file, but not quite an embedded language. Another example is when you allow users to input rules, or have rule builder systems. You're going to build something similar to a lispy evaluator fir those rules.
  - mbrodersen 4y ago