Ask HN: "No code" works well for making games but not general software. Why?

If you're interested in more visual scripting, I think there's definitely still pockets of the industry where it's useful. Blender has a fantastic node-based shader programming environment, which is both simple to use and wickedly powerful. As for "general software" analogs, I think Docker/Kubernetes has really abstracted all of that problem space away. People seldom need simplified interfaces to modify their tools, most users will just want a "road warrior", set-and-forget option that works ad-infinitum, and containers fit the bill. For better or worse, statefulness and good automation options often seem to be at-odds with each other.

The hardest part of any software project is getting people to know what they want.

Nocode tools won't save you unless you build a Nocode tool that correctly assesses business requirements.

Some good discussion here

https://news.ycombinator.com/item?id=30937201

One thing to keep in mind is that it’s not actually “no code”

I’ve worked at a big studio and if something was pretty complicated, performance critical, or just not supported by the engine it would be written in C++ and exposed via a new “block” that can be dropped in.

So one reason it works is because most projects you still have programmers on hand to abstract the hard stuff

I had similar experiences with LabVIEW 12+ years ago, it was effective for what we were using it for which, similarly, boiled down to a dataflow-style program and decision tables pulling from various data sources and pushing to various data sinks.

The biggest challenge I faced working on a team with things like this was that scaling to more complex systems only works if your design is reasonably modular. If it's not, then it's hard to simplify the current presentation sufficiently to make it comprehensible above a certain size of diagram. Of course text-based programs have the same problem (the 10k SLOC function with the same 100 lines repeated throughout but in slightly different orderings and with different variable names), but most programmers are more familiar with that situation and can either slog through it or know how to refactor it to get out of the mess.

I don’t think you can make wow in dreamweaver

  1. Merging visual code is basically impossible in my experience. 
  2. Likewise for refactoring.
  3. Likewise for finding all references, etc.

  1. Games often are released and that's it (though this has changed significantly) this puts less emphasis on maintenance.
  2. In my experience there were way fewer non-technical people involved with the enterprise product. There were designers and PMs, but not so many. In contrast a game is extremely content heavy which means many artists, game designers, sound designers, etc. Visual coding empowers these people.
  3. Non-game stuff often has very basic interactive elements/art. Like, you can get away with the system's UI toolkit. Games are the opposite, everything is bespoke because it all has to connect to the game's artistic vision. Visual tools such as shader graphs make this easier.
  4. Iteration in games is essential. It's the engine that drives quality. Visual tools empower this. In my experience normal software iterates less or at least differently.

It works well where the underlying technical "problem" is fairly stable and can be represented through a relatively small vocabulary of elements and relationships.

So it works for some games because a lot of game engine concepts and even many popular game mechanics are established. The expressivity for those games is in the art and narrative layers above the technical layer. But even then, high-production value games and deeply innovate games can't make do with it, because they're pushing on the technical problem and need more expressivity.

Likewise, it actually does work well for a variety of "normal" software domains and is used regularly. It's just the boundaries of these domains are narrow.

Visual programming will always be around and will make stable domains more easily programmable, but there will also always be value in the greater expressivity of coding.

--

That said: games also have special opportunity for being an art form, so doing something interesting within the constraints (as of a limited technical expressivity, modern pixel graphics, new games for old platforms, etc) is itself an artistic work to be appreciated. That extra benefit doesn't apply to plainly commercial projects.

The world runs on a visual low code scripting system called Excel.

The "no code" for building games is for building games. If you wanted a no code platform for building, say, embedded software, it would be a different no code platform. For building GUIs? Another different platform.

There actually is (or was, 15 years ago) a "no code" platform for embedded systems. It basically builds a state machine, plus tables of structs that look a lot like SQL tables (not how you access them, but the style of how data is organized into tables). It had the ability to run snippets of actual code when entering or exiting states. It was not generally used, though. The main thing it brought to the table was the ability to test the code (or at least the model of the code) on the desktop.

What I miss is RAD tools, the power and development speed of tools like Borland Delphi, Borland C++ Builder, Windows Forms. They made a breeze adding a GUI to an app.

Doing GUIs only in code is tedious and boring.

Personally I think something technical turns to spaghetti far faster than text(from looking at such systems). The editors are also severely locked down with DRM (software you can usually choose to shove raw text files into the compiler if you want to).

In either case, you had drag/drop GUI elements, property inspectors, and easy ways to call methods on all the relevant events. You simply designed your GUI forms, then wrote code to connect up the pieces.

You didn't have to figure out how to build call back handlers, or much of the grief of a main event loop in Win32.

When those assumptions don’t hold you tend to prefer code. Most well designed games on unreal will use both.

It isn't that farfetched to believe that at some point, language models are going to be trained on things like complete front end generation, database setup, cloud infrastructure, at which point you will be able to create software through simple language with a few visual tools

That said, they are very good and powerful, and open up a lot of flexibility to tech artists.

For business software the thing the nocode can’t do can completely make it infeasible to build the thing in the nocode tool.

It’s React based web app where you can build mobile apps from drag’n’drop UI components, and also define application’s logic in visual way.

The end result is React Native application that can be targeted for Mobile, Tablet and TV.

There are few enterprise apps built with it. Although those are quite simple apps, nevertheless they’re real commercial products.

I see that this “no code” stuff is quite natural progress and will get extended to lot more places. I mean how many standard website today was hand coded? It’s taken for granted now that you can build nice standard websites without knowing any HTML or CSS. Most websites have almost identical structure and functionality anyways so it’s not very hard to create such tools.

And now you can create standard business app without knowing Swift, React Native, Flutter or whatever is out there. It’s only starting now. You could say that AppGyver is at Wordpress 1.0 state.

Also these visual tools can be replaced with other UI systems. Like soon you can talk to computer and describe what kind of app or website you would like to have and watch live preview as it’s coming into existence.

It works great if you understand it's limitations and it's strong points. It works particularly well for data intensive applications - think moving a complex spreadsheet to an app with users, roles and authorizations.

It is more difficult to style it any which way you want - that that is also mostly due to the skill set of developers using and building with it. For example, in my case the biggest uses are business analysts using it to build internal applications and dashboards. They use it effectively to process data but don't have the design chops to make it look impressive - so it looks like modern design with rough edges.

But overall I feel that it still still has multiple uses for easy to prototype data driven applications.