3 ms·

I'm not a professional programmer, or even a good one I suppose, but I would never use this approach. Ignoring the fact this is clearly an advertisement for a

I'm not a professional programmer, or even a good one I suppose, but I would never use this approach. Ignoring the fact this is clearly an advertisement for a company product; this type of thing would need to be opensource and not tied to one company for it to succeed otherwise you're just stuck on a single platform at the mercy of the company managing it. Vendor lock in doesn't quite do it justice. I think my main issue though is the abstraction involved in this. Because whilst moving from machine language to assembly, to C, to Python (or whatever higher level language route you want) these abstractions makes sense (at least to me though I'm always curious about what's going on under the hood) I'm not convinced about this abstraction. It doesn't seem helpful. I could program in scratch if I want...

semicolon_storm 5y ago
>this type of this would need to be opensource and not tied to one company for it to succeed otherwise you're just stuck on a single platform at the mercy of the company managing it. Vendor lock in doesn't quite do it justice. In the low-code/no-code space, this is a feature not a bug. Some members of upper management at the company I work for have bought into the no-code hype. The sellers of no-code solutions rephrase vendor lock in as their "walled garden", evoking images of Apple's ecosystem and all the success they've had. Of course, people who haven't drank the no-code koolaid can see it's just a way to get you locked in and paying a huge cloud services bill to the vendor every month.