The ETL system we work in, as is obvious from my earlier comments I guess, is also not a code generator - it’s a runtime that loads and executes jobs (sequentially executed steps) and transformations (steps running in parallel, processing a flow of data) from XML definitions.
Elixir, on the contrary, IS a code generator (BEAM bytecode)… That’s ALSO being executed in a runtime… Any other high-level programming language is one, or both, of the above. The more useful distinction is probably if you can do debugging, introspection etc in terms of the language / model itself, rather than the generated code.
With regards to pros and cons, I’ll say that even a fairly complex ETL job in our environment can be understood at least on a higher level in just a few minutes. Humans ARE visual beings. That’s why I’d love to have a good DSL with round-trip conversion, so that you could get the best of both worlds.
I know that, but I mean no elixir code is generated. During compilation compiled code is generated, but I’m not talking about that. The contrast was explained here Low-Code Application Development Platform | Mendix. Posted the link already a couple of times to make it clear.
My 2 cents. The idea of visual programming is not new at all. You could make a reasonable argument that it goes back to at least HyperCard on the Mac.
It’s also pretty much every workflow tool out there these days.
I think it can be very successful, but only within a limited domain. You need to really understand the task the user is attempting to accomplish and the user needs to understand the tasks they are attempting to accomplish. (ie. pretty much like regular software. )
I don’t buy the “configuration is not code” argument. If it controls the flow of execution, it’s code.
What is hidden in all this is the cost of making the backend software so robust that errors in that code are never/rarely exposed to the user. The backend needs to be extremely robust to make all this workable. Bug free code is very expensive. These systems require an economy of scale to make that investment worthwhile.
Maybe Elixir has an entry point here in that it can reduce the cost of building a robust backend for these systems.
That is what I mean. The language in which the backend of a “low code” framework is written counts. All the sellingpoints of elixir.
Moreover it is not all or nothing. If you see return of investment for a part you could build only a rules engine f.e. (lots of rules in your application? do they often change? a need to make them visible / comprehensible for customers?). You can find open source frontends that help. Or a form builder. I’m looking at this one at the moment: http://codepen.io/travist/full/xVyMjo/ (I do not like angular, but the tool looks promising) . The form is persisted in json.
the difference between code and configuration file can be fuzzy especially in high level declarative programming languages. Remember the central idea of LISP: code=data !
As stated above, I would be interested in how these new low-code platforms avoid or overcome problems of the past. And it looks like Gomix wouldn’t make it into Forrester’s study because it is not enterprise-focused but rather individual-focused. It reminds me of the days of Tripod and Angelfire but with modern API connectivity.
That said, I think these low-code platforms can be a strong solution for complex business processes as seen at financial, insurance, and government institutions. Speed to a working prototype is important for these types of organizations because they are so risk-adverse. It’s more worthwhile to throw together an app using one of these platforms to see if it’s even worthwhile building a full application. Indeed, project directors must understand the drawbacks of keeping one of these drag-and-drop apps in production.
As stated above (The rise of low code platforms - #24 by StefanHoutzager you can start small. Even very small. For example with a formbuilder / renderer. Why not. Here the form is persisted as json and runtime rendered via the json that is bound to a websocket (channels).
This is exactly where these kinds of things go south. You are thinking as a programmer not a user.
Users do not care about forms, if you give them forms you’ll end up in the trash bin along with the rest.
Users care about tasks, actions, etc… You have to build a tool that allows them to chain tasks, actions.
The idea is reasonably good. But almost all the implementations of it are terrible, because programmers in general are terrible at knowing what users want. Starting “small” is a recipe for disaster, eventually you just build a really crappy IDE or even worse some kind of dreadful Excel plugin.
Sorry, I did not mean that as personal in any way. My apologies. All those statements apply to me as well.
I have just seem so many terrible implementations of this idea and very few good ones.When it works it’s a big productivity boost, but it so rarely works. Good luck and prove us all wrong.
Ok, but in the meantime you could prove yourself some things if ever you are interested. You could even start much smaller than this formbuilder. I do not feel the need to prove much, besides who are “us” in here:
(
For the rest I do not take these kind of messages serious. Sorry.
