4 ms·
No-code has been the "future" for 20 years, but no no-code framework has never reached close parity with code ecosystems, and always require someone doing code
by guilhas 5y ago
No-code has been the "future" for 20 years, but no no-code framework has never reached close parity with code ecosystems, and always require someone doing code for each no-code component
- version_five 5y agoI read the other day (but failed to really verify) that COBOL is so verbose in part because it was designed as a "no code" language that at least could be understood, and possibly written by "business people". I have yet to meet anybody in this magical category that knows how to program except for the syntax, and if only they were given a way to draw their vision as a picture or write it in English, instead of have to stoop to "code" they'd be able to cut out software developers and go straight to their vision. But I assume as long as software is sold to "leadership" there will be a niche for these products - just not one in which they are actually used for anything.
- throw_m239339 5y ago> I read the other day (but failed to really verify) that COBOL is so verbose in part because it was designed as a "no code" language that at least could be understood, and possibly written by "business people". So was ADA, allegedly. I don't find it more readable than C or C++, just more verbose. The issue is that, syntax doesn't matter when one still has to understand concepts BEHIND that syntax. Visual programming may help learning though. I learned OOP via Flash, learned SQL via some SQL editor, and learned basic ASP classic via Dreamweaver. But it's just a step, like ridding a bike with training wheels.
- zozbot234 5y agoAda's verbose syntax was a workaround for primitive terminals with limited character sets. (That's also why it's case insensitive.) It was never intended to be especially English-like, or easy to survey for non-technical users - while both of these were goals for COBOL.
- Smeevy 5y agoThe problem with these tools is that they invariably have solutions to their own design problems that conflict with the system you need to build. One of my old customers went with Tibco as a replacement for an internally developed system and have had no end of troubles with it. They were over 2 years late in their roll-out and the unforeseen limitations/lack of understanding of their tool have basically made them re-create their old C# application in Tibco in its entirety, thereby reducing Tibco to a second-rate cluster manager. I'm sure they did a number of things wrong in that effort, but that's an expensive lesson that they relearn every year when their gigantic Tibco invoice arrives. I'm also in the process in migrating a system from the Versata business rules engine/ORM application that is hands-down the worst system I've ever seen in over 30 years of writing software. This is another client with their own set of problems, but I have literally been able to replace thousands of lines of bizarro-world copypasta a single SQL query running on top of a normalized database. That's not to say that Tibco or these new cloud-centric tools aren't impressive and useful, but I haven't seen any of these tools that I would ever recommend for anything other than the absolute simplest glue code service. Additionally, I probably replace that service with something boring as soon as it gives me any backtalk at all.