Why isn't there a "nocode" tool that lets you buy the full source code once your user base reaches X? (for $Y). Both problems solved? (finding the right balance in the level of abstraction for the "nocode" tool's code shouldn't be a big deal).
The “No Code” Delusion
281–290 of 334 posts
Re: The “No Code” Delusion
#282Earlier quoted context omitted.
What you need is a speed bike that lets you switch to a mountain bike when you decide you need/want to go off the trail. That is, a "no code" or graphical or whatever whizz-bang tool that lets you drop into C++ or Python or Lisp or whatever when you need to. And to do this, it needs to be better than JNI in Java. It needs to be able to have something better than a gouge-your-eyeballs-out-ugly syntax for interfacing t…
I mean, that's pretty much how I program things. I start new web apps with an MVC framework that auto-generates new pages. When I want to do something, I try to use someone else's code as much as possible. If I'm doing a simple, well contained task, someone else has already thought of it and made a library for it. If I need to send an email, I just do something like calling _emailSender.SendEmail(message). Easy peasy…
I am a lazy programmer in that way. I'd rather autogenerate and use robust libraries as much as possible.
Re: The “No Code” Delusion
#283I read somewhere a quote that stuck with me: "No tool is ever going to free us from the burden of clarifying our ideas." And that's how I view my job as a software developer: clarifying ideas. Any "No Code" tool is still going to either force you to clarify your ideas, or have a large amount of assumptions. "Idea People" and "Business" don't like that, so they'll probably end up delegating the use of "No Code" tools…
I rather disagree. I work at a large non-profit. I'm not a coder, but I'm IT literate, and know enough about database design to not do absolutely stupid things. I'm happy to document processes enjoy clarifying ideas. We use Sharepoint. In many many respects Sharepoint is detestable garbage, but I have managed to create some really quite complex automated workflows which are saving people in the organisation a lot of…
> I'm not a coder, but I'm IT literate
I'd say you're at least some kind of coder. My point is that there will always be room in an organization for people like us, who aren't afraid to go down and use our tools to the fullest extent, to save "people in the organization" enormous amounts of time. These tools can be code or something else, but the point is clarifying ideas. The exact tool you use doesn't matter.
"No Code" is not an existential threat to developers, it's just another programming language.
Re: The “No Code” Delusion
#284This says it's very either or, and I think misses the point of a lot of nocode tools.
One of the best measures of tools is their composability. Can you use this for what it's good at, and integrate that solution with another tool that's much harder to use but can solve the last 5-10% that's just too hacky or not supported directly by this tool?
For my that's where zoho creator falls down a bit. Their APIs are just web form post handlers. But it works!
We're doing a lot of stuff on webflow by dropping some custom javascript in there to hook it up to an API or do some very data-driven stuff beyond their interactions.
The point is, nocode isn't just for proofs of concepts, although it's great for that.
When evaluating nocode tools, look for integration/extension points, and think about your migration path should you need to replace it. Hopefully you're succefful enough to need that but don't build 100% of your app by hand because 10% actually needs hand-written code.
Re: The “No Code” Delusion
#285Earlier quoted context omitted.
What you need is a speed bike that lets you switch to a mountain bike when you decide you need/want to go off the trail. That is, a "no code" or graphical or whatever whizz-bang tool that lets you drop into C++ or Python or Lisp or whatever when you need to. And to do this, it needs to be better than JNI in Java. It needs to be able to have something better than a gouge-your-eyeballs-out-ugly syntax for interfacing t…
I think the abstraction layers are important, they should not be leaky. You shouldn't have to go up/down the stack. If you can't build what you want with one tool, then choose another tool.
Yeah while I think one of the hardest parts if a software developer's job (working at multiple levels of abstraction), that's literally the job. You're translating between the business and the sillicon.
By all means restrict yourself to assembly but yhe rest of us will get more done by using things at convenient levels of abstraction for those specific units.
Re: The “No Code” Delusion
#286Earlier quoted context omitted.
RPA just seems crazy... I mean, I see the golden shimmer, but why do so many enterprises refuse to actually, you know, solve the problem? I have, btw, just finished reading “the phoenix project”. Brilliant book! Having lived through pretty much that story a couple of times, the solution is just that simple. Not easy, but simple. Been around a while, at several big companies, I know most of them will do RPA (they are…
Because they can’t go straight from A to B, because there are so many audited processes that are tightly coupled to A. So they replace A with B one step at a time, and keep A in sync with B using RPA. When the whole of A is replaced, you turn it off along with the RPA. The problem comes when RPA stops being a short-term tactic, and starts being a long-term cottage industry. Unfortunately, RPA vendors have a vested in…
Well, they can’t because they usually don’t really try.
Most likely they have outsourced years ago and lost a lot of competency along the way.
They have invested heavily on in really crappy software and solving this with something like RPA seems to me like introducing a ginormous footgun/perpetual roadblock.
That RPA is not going anywhere soon... Or will it be replaced by the billion dollar, just a bit late, “phoenix project”? The ONE platform that promises speed and agility? That one? :)
Re: The “No Code” Delusion
#287I've spent a long time trying to build "No Code" solutions. Probably 3 different products, 3 different companies. But once, I tried something different. I pushed back, instead I proposed we build a domain specific language using Ruby. I already had some trust with my boss... and he was pretty convinced it was going to fail, he had zero faith these smart (but non-technical) users could successfully use it. But he was…
"A picture is worth a thousand words..." When doing presentations or writing, I make a lot of effort to visualize what I'm trying to communicate, as it really helps making sense of all the words.
I work for a low-code, no-code vendor. We usually approach new features by first defining a DSL for a need, and than have one or more visual editors for these DSL. Every part of your application is still customizable (Java, typescript, react widgets, etc), or you can just call a microservice built in another stack.
Re: The “No Code” Delusion
#288Earlier quoted context omitted.
Isn't the majority of software following this rule ? This is not specific of low/no code environment
Kinda, it sounds very similar to the 80/20 rule. The 80/20 rule says 80% of the solution takes 20% of the time. So it's not quite the same. In other words, the 80/20 rule says the last 20% takes 4x as long as the first 80%. In comparison, the above quote says the last 10% takes just as long as the first 90%. So slightly different.
Both this "90-90" and "80-20" indicate that the devil is in the detail. e.g. You can expect surprises as you're almost done, there's an inherent complexity to the solution, etc.
But saying "the first 90% takes 90% of the time" blatantly ignores these anticipatable unknowns; so it's a much more tongue-in-cheek thing to say.
Re: The “No Code” Delusion
#289Earlier quoted context omitted.
RPA just seems crazy... I mean, I see the golden shimmer, but why do so many enterprises refuse to actually, you know, solve the problem? I have, btw, just finished reading “the phoenix project”. Brilliant book! Having lived through pretty much that story a couple of times, the solution is just that simple. Not easy, but simple. Been around a while, at several big companies, I know most of them will do RPA (they are…
There is a competition between RPA and automation by Python ongoing in my workplace. We are low on devs and high on buzzword-susceptible non-technical managers. The argument that it is a lot smarter to hire a few more devs that would add a lot more value to the company, especially given that we have already made significant inroads in 'proper' automation, than pay for a proprietary tool that is essentially an overhyp…
I’m sorry to hear.
The RPA abstraction just seem so fragile and unflexible. I _had_ to build “rpa” like solutions to problems in the late 90s using tools like scriptit, and later vbscript. Crap software have no APIs...
I guess, it’s the same type of companies, still with the same type of software.
Re: The “No Code” Delusion
#290Earlier quoted context omitted.
> there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." Which is easily achieved by the first typed language that comes to hand, no?
Not without an IDE. It's still extremely possible (in all text-based languages I'm familiar with) to write the program with a typecheck error; the typechecker will gleefully catch it for you. At typecheck time. Often (depending on my toolchain) minutes after I've written the offending code and mounds of code depending on it. It's possible, with many languages, to write IDEs that will make this hard, but I've yet to f…
[deleted]