"No code" does not equal "no programming". For me, programming is 90% about how I structure/organize a process, 10% is the expression of said process through code.
The “No Code” Delusion
141–150 of 334 posts
Re: The “No Code” Delusion
#142As I recall, Assembler was the first "no-code" tool. After all you could get rid of all those pesky programmers who knew all the number codes for instructions. Anyone could write "ADD R, R2". See!
Re: The “No Code” Delusion
#143anyone tried bubble?
Re: The “No Code” Delusion
#144Earlier quoted context omitted.
I don't think text is nearly as compact as people claim it to be. I dabble in graphical programming languages from time-to-time, and one feature they all share is the editing environment for code makes entire categories of syntax error impossible; 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." It's a level…
> 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 find one that makes it impossible. Certainly not in the same way that, for example, Scratch will simply refuse to let the offending blocks click together. I certainly don't advocate transitioning from text languages to Scratch, but I think there's meat on the bones of asking the question "Why, when I'm editing code in text-based languages, am I even allowed to reference a variable that is demonstrably the wrong type? What benefit is that gaining me?" Because I think the answer in a lot of cases is "No real benefit; editing, typechecking, and compilation have just historically been disjoint concerns with no feedback channel because writing those is hard."
Re: The “No Code” Delusion
#145As someone who has been managing Low Code/No Code on a large scale for a major enterprise from before this became buzzword soup, I can categorically state that the benefits are real. HN isn't the intended market here, and that disconnect is shown in the currently leading comment thread which is talking about DevOps deployment. DevOps is way beyond what this space currently targets and is working to achieve. To be cry…
I don't think the intent here was to say that LC/NC isn't "real" but that it has been oversold.
At my last company they attempted to implement a project in a low code framework and they eventually had to pull back significantly because the requirements were simply too complex for the framework to handle in a reasonable fashion.
The lesson is "use the right tool for the job."
Re: The “No Code” Delusion
#146Earlier quoted context omitted.
To play devils advocate, isn't the idea with Ansible at least that it's idempotent. The YAML should describe the final state and should be concerned with branching or lower level features like that. (It's the same with SQL, you describe what you want back rather than how its achieved. A declarative approach works fairly well there.)
What's needed is an internal data-structure that defines the state needed -- YAML declares the structure directly, but an alternative is to use either a DSL or even a general-purpose language to build that data-structure. Of course, you could write code to generate your YAML, but the tooling is _not_ going to help you with that today. Maven and Gradle are examples of each of these methods -- both build up an internal…
Of course, I meant Groovy. The keys (at least on my Dvorak keyboard) are right next to each other :P.
Re: The “No Code” Delusion
#147And using our new graphical "workbench", your business users will be able to integrate applications without placing any burden on your development teams. Sign here. . .
Re: The “No Code” Delusion
#148Robotic Process Automation (RPA) is the new "No Code". And it will fail the same way every other "No Code" fad has failed over the years, no matter how successfully McKinsey sells it for the next few years.
It will never completely disappear, but there is no future where a BA with an overhyped macro suite replaces the whole of software engineering.
Re: The “No Code” Delusion
#149I was once at a company (X) that acquired another company (Y), and Y's main product was a graphical programming tool. Y advertised that their tool could speed application development up 10x. My (nontechnical) manager asked me "why don't you use Y's tool to build the project you're currently working on?" I answered with the following metaphor: Imagine you have to pick a bike to go on a trip. You're travelling on a wel…
Reminds me of something Bruce McKinney said about Visual Basic when I was much younger and beginning to learn about computers in general, I'm paraphrasing here but the gist was "Visual Basic makes 95% of your task easy and the other 5% impossible".
Of course Bruce is a hard core programmer so he went on to show you how to do the 5% in VB using some crazy hacks or, better, do it in C/C++ using COM and glue it onto your VB code using the common MS interface of the day (pre .Net that is).
I've forgotten more of it then I remember but I do remember really enjoying reading anything Bruce wrote!
Re: The “No Code” Delusion
#150The add_domain_name code has another buffer overflow problem
const size_t size = 1024;
char *dest = malloc(size+1);
strncpy(dest, source, size);
strncat(dest, "@example.com", size);
return dest;
(heinrich5991 found a seperate problem with the strncat).
IMHO, this helps prove the point about levels of abstraction. The only reason that we argue over the idea that higher level == better is that we're programmers, and we argue over everything :-)