Live data from Hacker News

The “No Code” Delusion

alexhudson.com

181–190 of 334 posts

Re: The “No Code” Delusion

#181

There's no such thing as "no code". There's just interfaces which are more-or-less capable, and more-or-less intuitive. Any time you define a set of instructions for a computer to execute, you are creating code. We use Scratch at my Girls Who Code club. It requires students to consider branching paths, and data types, and asynchronous execution. It does not require the students to type , but thank god for that, becau…

This made me wonder: which side would other activities fall on, if event handling was the defining characteristic of "code"? Not code - Excel, SQL, HTML, CSS Code - Email inbox rules, IFTTT. Alarm clock?

Hmm, y'know what, I'm now reconsidering that part of my post.

Setting an alarm clock is definitely not coding. All the instructions are built into the clock:

    if (currentTime == alarmTime) {
        soundAlarm();
    }
All the user does is set the value of alarmTime, a single variable.

But, what if the user can choose from a set of alarm sounds? I feel like that's still not coding, but I also can't describe how it's different from IFTTT.

There's a spectrum here for sure—any time you interact with a computer, you're giving it instructions. I was thinking about this in terms of the mindset required. When I volunteer at GWC, there's a very specific skill that I see the students coming to grips with over the course of the class. I don't have a word to describe it.

Re: The “No Code” Delusion

#182
post #12

I've been hearing about "no code" or "no programmer required" business solutions for over 20 years. Cynically, I encourage this thinking because my billable rate to untangle someone else's hot mess when urgent deadlines are looming goes up. Practically speaking, if the business problems being solved are complex you might be able to pull off a low-code solution but without knowledge and practice of the essential archi…

I'm actually quite fond of some "no/low code" tools but there is a threshold of complexity beyond which if you use them then terrible abominations will result that are far more complex then the equivalent code and actually require more technical expertise then 'code' - so you end up with components that only a skilled developer can maintain in a platform that developers will hate.

Absolutely true.

There are also a large number of projects - maybe majority? - that never reach that level of complexity; and the "no/low code" solution (like Excel, Access, etc.) enabled a non-engineer to solve a business problem without hiring any engineers.

That's where these kinds of systems shine, if done right; allow a "non-engineer" who has a logical mind / the engineering tao to create solutions without having to learn traditional development toolchain.

Re: The “No Code” Delusion

#183
post #166

Why does the common non programmer need a visual UI? Why so allergic to typing text? The rest of the average office worker's job takes place through the traditional CLI known as English (or other language).

Discoverability is vastly superior in visual interfaces.

Re: The “No Code” Delusion

#184

Earlier 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…

Do you have examples of delivering actual production applications with a graphical programming language in less time than developing the same thing with a traditional text based language?

I don't, and the gap is (IMHO) wide between where the ones I've used are and where they'd need to be to compete with text input. The main hindrance is UI; keyboard is a relatively high-bandwidth input (in terms of bytes-per-second of usable signal), and most of the graphical languages I've seen are heavily mouse-centric with not enough accelerator keys to close the gap. I can generate a lot of incorrect code-per-second with a keyboard, but I can also generate a lot of code-per-second period.

I'm hoping someone can close the gap and bring us a graphical language with a robust keyboard interface to navigate through it and edit it, with the advantage of strong edit-time validation excluding invalid programs. If someone can close the gap, it'd be a hell of a thing to see.

Re: The “No Code” Delusion

#185
post #24

Earlier 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…

It's fascinating reading such a strong argument for using Lisp...and then considering anything else than Lisp.

Re: The “No Code” Delusion

#186
post #9

This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs. The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...). Especially with tools like Helm I be…

Thank god trends like Pulumi and the new AWS sdk is emerging. General purpose programing languages are getting more expressive by the day, why do we use data serialization languages instead for configs? it doesn't make any sense. Configuration is code not data.

> Configuration is code not data.

As any Lisper knows, code is data is code.

Re: The “No Code” Delusion

#187

What makes programming difficult isn't the syntax, it's the need to define the problem in an completely unambiguous and consistent manner.

You forgot a couple of things. You need to define the problem in a way that's complete (no missing corner cases) and be able to debug it when it goes wrong.

Re: The “No Code” Delusion

#188

I 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 you…

That's often the trade-off of any high-level tool or library. It will make a big chunk of related tasks easier, but won't be able to handle a small subset. Hopefully there are ways to work around the limits.

Re: The “No Code” Delusion

#190
post #4

"Low Code" is currently where it's at. Intelligent subject-matter experts who are non-programmers can build 80 to 90% of their business info capture and reporting requirements inside the walled garden of their chosen platform. Programmers are called in temporarily to complete the final 10 to 20% of the LowCode app, and integrate with external services. It's been happening since Excel, through to Wordpress and nowaday…

About 2/3 of software cost is typically maintenance, not original creation. If some RAD-ish tool makes maintenance more difficult, saving time up front doesn't mean a lot, other than maybe as practical prototyping. Maintenance costs include getting new staff familiar with a tool, and the turnover rate is typically around 4 years for developers. Self-taught programmers tend to produce spaghetti systems, in my experience. My first programs were spaghetti, I must say. I was an IT puppy. I short, consider the medium and long-term costs of RAD/code-free tools.
Post reply on HN