Ask HN: "No code" works well for making games but not general software. Why?
38 comments
Some more reasons (as an erstwhile enterprise dev turned gamedev who has embraced visual coding):
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.Visual programming fundamentally lacks the technical expressivity of code.
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.
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.
I'll add that this doesn't just apply to code. With the arrival of legible text generators like GPT-3, you can imagine someone writing pulp novels visually they do games. Pull in a detective, a victim, a murder weapon, set the tone to Doyle, and drag the slider to where you how long you want the chapter to be: voila, a new mystery suitable for the people who eat up 10 a day.
But there'll still be room for authors who hand-craft new works that challenge or reject those pulp formulas, and readers who are bored by identifiable formula will be looking for them.
But there'll still be room for authors who hand-craft new works that challenge or reject those pulp formulas, and readers who are bored by identifiable formula will be looking for them.
I asked the same thing a while back
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
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
AppGyver has done pretty good job.
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’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.
I don't feel the need of "visual scripting" in mainstream software.
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.
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.
I miss RAD tools too. Visual Basic was hugely popular two decades ago. The ease of building GUIs was unparalleled. That experience carried over to some extent with Windows Forms, WPF, Adobe Flex, etc., but not quite the same.
A decent blend of RAD and visual programming is the Max/MSP that ships with Ableton Live. It's fairly straightforward to build little audio/MIDI devices, then switch to visual programming for the implementation (objects/patchcords/control in Max terms).
> Doing GUIs only in code is tedious and boring.
Totally. But given that most GUI software these days involves client/server, I'm not sure if there's a simpler solution.
I work on Nitro[1] these days, and it's an attempt to make GUI development simpler and less tedious, primarily by trying to abstract away client/server programming and opting for a simpler way to program UIs without dealing with callbacks or event-handlers.
[1] https://github.com/h2oai/nitro
A decent blend of RAD and visual programming is the Max/MSP that ships with Ableton Live. It's fairly straightforward to build little audio/MIDI devices, then switch to visual programming for the implementation (objects/patchcords/control in Max terms).
> Doing GUIs only in code is tedious and boring.
Totally. But given that most GUI software these days involves client/server, I'm not sure if there's a simpler solution.
I work on Nitro[1] these days, and it's an attempt to make GUI development simpler and less tedious, primarily by trying to abstract away client/server programming and opting for a simpler way to program UIs without dealing with callbacks or event-handlers.
[1] https://github.com/h2oai/nitro
"General," specifically enterprise, software has to deal with changing requirements, external integrations, and multiple stakeholders, whereas games are relatively static, have a single stakeholder type, and have limited and defined external integrations. To put it another way, LOCNOC tools work great for things that are largely isolated and don't need to change much over time; they're a disaster otherwise, to the point that I've literally never seen a successful LOCNOC project, despite literally millions of dollars of project investments in them.
It did take off... Delphi and Visual Basic 6 were immensely popular.
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.
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.
That is not really nocode and there is definitely a limit before you need to concern yourself with architecture, structuring code, dealing with complexity etc.
I remember those old visual tool where you could even drag on DB connections. But soon as you have a complex requirement like joining two tables or something then boom you are in yescode.
I remember those old visual tool where you could even drag on DB connections. But soon as you have a complex requirement like joining two tables or something then boom you are in yescode.
Microsoft Access 2000 was great at doing table joins in a visual way. It automatically enforced relationships between tables without having to write any SQL.
It is possible to go all the way to writing programs with no actual text source, but the "cognitive impedance match" has to be reasonable. In theory, you could just take MIT's SCRATCH and hook it to a compiler... but it's not the right tool for managing that complexity.
My current feeling is that something like literate programming, with rich source, both declarative and imperative functional code is the way to go for optimal productivity. The front ends that handle GUIs and events match that part of the problem in a profoundly productive manner.
It is possible to go all the way to writing programs with no actual text source, but the "cognitive impedance match" has to be reasonable. In theory, you could just take MIT's SCRATCH and hook it to a compiler... but it's not the right tool for managing that complexity.
My current feeling is that something like literate programming, with rich source, both declarative and imperative functional code is the way to go for optimal productivity. The front ends that handle GUIs and events match that part of the problem in a profoundly productive manner.
Key word being "were". I'm not aware of widely used similar tools for modern WFEs (which arguably makes up most user facing software these days).
I did use something like it back in early ASP days, which were mostly server-side web apps.
The core technology at the heart of both VB6 and Delphi were the Win32 Common Controls, a set of native code GUI elements that are still present in windows. They offered a consistent toolkit across all windows versions. At the time, this was most GUIs.
It is unlikely that any one set of native GUI elements and library calls will ever be applied across all GUIs ever again. The constant churn of languages, the web stack, the vast size range of displays all combine to a situation where GUI application development receded from a high water mark, and it's all downhill from here.
The tools are worse than they were, and are unlikely to recover.
It is unlikely that any one set of native GUI elements and library calls will ever be applied across all GUIs ever again. The constant churn of languages, the web stack, the vast size range of displays all combine to a situation where GUI application development receded from a high water mark, and it's all downhill from here.
The tools are worse than they were, and are unlikely to recover.
What you can show/build with HTML/CSS/JS hasn't really changed that hugely in the last few years.
There are RAD tools for React apparently (retool?) and I don't doubt they wouldn't be appropriate for all uses, but there's plenty of cases where you just need to throw together something quickly where being able to "build" the page layout visually would be extremely helpful. I sometimes get the impression many React-based sites you just get whatever layout happens to be the default (based on HTML5/CSS specs, and whatever libraries/out-of-the-box stylesheets you might use), even if the exact outcome doesn't really match what's been asked for by the UI/UX designer (who almost certainly did use a WYSIWYG tool to come up with the wireframes/static mocks etc).
BPMN and BPMN-based or related tooling is pretty popular within businesses for, well, business process automation. It offers a no/low-code way of moving manual processes to an automated form and can work well. But these are relatively simple programs that often boil down to a dataflow-style + decision tables. The diagrams are desirable for communicating the process to non-programmers anyways so it's handy that you can (more or less) use them to at least describe the flow of the system, if not all actions (like you may write code for some of the actions, but overall you can accomplish most things with the diagrams and tables and built-in tools for your particular BPMN service).
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 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.
Could take a look at ladder programming/diagrams that electrical engineers use for PLC programming. Works well enough for a lot of people there.
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).
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).
Visual scripting makes sense because game logic is fairly simple (eg. when $POINTS > 100: $TEAM wins), but their data structures (teams, players, stats, scores, state, etc) are not. Video games are one of the few places where object-orientation isn't a matter of diminishing returns, and it pays dividends in places like this.
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.
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.
Some other verticals where visual programming is effective: Education, such as the excellent Microsoft MakeCode[0] that lets the user switch between visual blocks and written Typescript. Synthesizers, such as Reaktor[1], that are programmed visually and with code blocks. And scientific instruments, which can be programmed visually with LabView[2].
[0] https://www.microsoft.com/en-us/makecode
[1] https://www.native-instruments.com/en/products/komplete/synt...
[2] https://www.ni.com/en-us/shop/labview.html
[0] https://www.microsoft.com/en-us/makecode
[1] https://www.native-instruments.com/en/products/komplete/synt...
[2] https://www.ni.com/en-us/shop/labview.html
I have been working with no code solutions for almost a decade.
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.
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.
From a cynical economic perspective, there’s a financial benefit from dividing labour into “expensive engine tech” and “less expensive game designer”.
The shortest answer is that the "hard part" of software development is not syntax, but logic and architecture. These parts get harder the more complex the app becomes. Hundreds of years of human history have shown that text is the easiest and most readable/writable way to represent complex logic and algorithms, so this leads to the need for text-based languages and text editing tools for working with most general purpose software of any non-trivial complexity.
> text is the easiest and most readable/writable way
I love this part. What else could be more readable/writable than texts :)
I love this part. What else could be more readable/writable than texts :)
I wouldn't say it works well for games. The "no-code" solutions like blueprints or shader graph are more of a visual configuration for technical artists to use, but built on pretty well defined code-heavy systems. You might use a visual system to configure something like a AI Behavior Tree, but you wouldn't be able to build a whole new type of system with it.
That said, they are very good and powerful, and open up a lot of flexibility to tech artists.
That said, they are very good and powerful, and open up a lot of flexibility to tech artists.
Requirements.
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.
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.
I wrote a lengthy reply in the thread arduinomancer gave but I’ll simplify it here. Game code is largely about making API calls to the engine. You use a relatively small number of blocks to build things. It tends to be object oriented. You tend to use a lot of void functions. You don’t write a lot of algorithms.
When those assumptions don’t hold you tend to prefer code. Most well designed games on unreal will use both.
When those assumptions don’t hold you tend to prefer code. Most well designed games on unreal will use both.
I think it's because you need a stable "meta" of functions to be able to build a graphical user interface and with general software, there's just so many unique problems you're sometimes solving for the first time or solving in a novel way, it would be hard to build something that stays useful.
"General" software contains too much variability.
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.
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.
Whenever this is posted it always sounds like it comes from someone who has never worked outside of engineering.
The world runs on a visual low code scripting system called Excel.
The world runs on a visual low code scripting system called Excel.
This. Excel is (kind-of) No Code way for creating general purpose software for masses by masses. But it really depends on skillset of user. I saw a guy who wrote DB system in Excel, I witnessed employee putting data into Excel and then working them out via calculator and putting results in the Excel manually.
Said employee with the calculator might have been smarter than you think: https://docs.microsoft.com/en-us/office/troubleshoot/excel/f...
Point taken that floating point arithmetic might be broken in Excel, but most use cases of Excel are calculation without floating point numbers.
No code" works well for making games but not general software... yet
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
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
Probably because a game just has to entertain. If there is something the platform can’t do then no biggie.
For business software the thing the nocode can’t do can completely make it infeasible to build the thing in the nocode tool.
For business software the thing the nocode can’t do can completely make it infeasible to build the thing in the nocode tool.
Because most of them have no notion of a lambda, which has all the same knock on effects you get in normal code.
What is a "visual scripting system" and how is it different from a programming language?
I think it’s simply because we are lacking a good no code platform for modern general software.
Define games.
I don’t think you can make wow in dreamweaver
I don’t think you can make wow in dreamweaver
You could. It'd just be extremely slow and an utter nightmare to write.
I mean, with the addition of socket functions, you could write it in BASIC if you were so inclined.
I mean, with the addition of socket functions, you could write it in BASIC if you were so inclined.
I'm curious as to why. What in the nature of "normal" software makes visual scripting inconvenient compared to games.