As someone who's heavily used Blueprints, I can tell you they really work. You have no need to write a single line of code to program the behaviour of an entire game including physics.
You do need C++ though if you're going to write stuff like A* pathfinding, complex scene setup like hex based 3D platforms. Again it's all doable in Blueprint and I'd often do it first in BP and then rewrite it in C++ for perf sakes.
So visual programming isn't broken and it works, and not necessarily at DSL level. The UX of the editor has to be fantastic though, for noobs as well as experts. That means good support for quickly producing nodes, finding existing code, refactoring support and Git support. You may think it's tedious but with habits and patterns, with a few key stroke I could program an entire component's behaviour in no time.
One thing that was magical is that with a heavy code base of visual nodes, the brain can find entire sections very quickly, a bit like that cave analogy in the article. You could group nodes with coloured rectangle etc. and the way they were laid out you'd have instant recollection of its internal workings. By seeing a vague layout of nodes I knew this was about joystick controller, player controller, shader, etc. It's a massive advantage and takes less strain on the brain to "READ" again the code. It makes code re-discovery so much easier. If I had some gnarly behaviour it would instantly show in the pattern of nodes as how they were laid out.
I'm convinced that if we had "as good" editor for web technologies, we could produce microservices and front-end code in the exact same fashion without writing a single line of code. It's just such a massive investment to _do it well_ I don't see it happen any time soon.
I've put together a POC which allows NodeRed to run on iphones/android phones and allow visual programming on the device: https://github.com/alexisread/noreml
What's missing there is a table component to really finish off being able to create a more general-purpose UI.
Exactly, that's what I tried to explain – brains are incredibly good at navigation in spatial environments. There are tricks to use this for memorization – "memory palaces" [1], for example, and there is an increasing evidence that some layers of cortex contain so called "grid cells" [2] that solely responsible for the spatial information encoding.
I never used Blueprints myself, and get the idea of experience from Youtube tutorials. It definitely "works" for the specific tasks, but still, Blueprints from Hell [3] exists for a reason.
Absolutely agree on the UX part of the editor. To make people switch from A to B, B should be twice as cheaper and 10x as good.
Mandatory shout out to: https://luna-lang.org, which tries to take a Blueprints-like approach to the next level, making it possible to write general-purpose code both visually or textually, and insta-translate it back and forth between visual and textual representation. While being fully open-source.
I’ve been working on something similar to a blueprint for TypeScript. You can point the editor at typescript files and it will parse them and generate nodes. You can then hook the nodes up in the editor and build programs. You can also build nodes out of other nodes.
I’m still pre launch. Hoping to turn this into an MVP by the end of the year.
> One thing that was magical is that with a heavy code base of visual nodes, the brain can find entire sections very quickly, a bit like that cave analogy in the article. You could group nodes with coloured rectangle etc. and the way they were laid out you'd have instant recollection of its internal workings. By seeing a vague layout of nodes I knew this was about joystick controller, player controller, shader, etc. It's a massive advantage and takes less strain on the brain to "READ" again the code. It makes code re-discovery so much easier. If I had some gnarly behaviour it would instantly show in the pattern of nodes as how they were laid out.
This works if you did the grouping and layout. How well does it work if someone else did that, and the way they think doesn't match how you think?
On the other hand, that may be no different than if someone else did the directory structure, the grouping of data in objects, the naming of variables, and so on.
So taking a devil's advocate approach on this... What would you think about text if you instead organized your code into logically partitioned submodules and followed a very easy to understand organization?
In my opinion, when working with a codebase that is well organized, it feels like reading a blueprint just by the folder and file structures. So the question from the devil's advocate, are we really in need of visual methods for programming? or do we just need to get better at organizing code?
Edit: Assume that good organization lends to easy copying/generation of submodules for use elsewhere
The "enterprise pockets" requirement usually ends up with (practically) nobody learning it themselves, nobody knowing about it, nobody knowing how to use it and nobody considering using it.
Any programming tool your average joe programmer cannot try for themselves in their own computer might as well not exists nowadays and at this point it'd only rely on how good the marketing drones of the development company are at convincing non-programmers of other companies that they should use that tool, which in turns means that the tool doesn't really have a need for actually being good, just give that feel to whoever makes the decision to get it.
If a developer cannot use these tools themselves they wont know them, in turn they wont promote them to others, they wont propose them to companies, the companies wont need them and they wont seek developers with knowledge of those tools and as a result knowledge of those tools wont be "tasty" to many companies.
The only way to break this dependency loop is to convince non-developers (executives, etc) to use those tools but at that point the incentive shifts from making those tools good for use by developers to making those tools good in convincing non-developers to buy them.
The only "big buys club" i see working on here is one of people who couldn't learn something else.
You should already have seen this with Turbo Pascal and Delphi and how these products moved from cheap $50-$100 products even students could afford and focused providing a simple yet comprehensive package to grossly priced overbloated, hype-driven, bullet-point executive-presentation-friendly monsters with tons of bugs and an over-reliance on bundling 3rd party components. And how this sort of move made their products instead of being widely known and loved by developers to become relics that only stay alive because their owners are preying on those who at the past chose them (because they were good at the time) and cannot move off.
I have used OutSystems for almost a year, I think it is almost the best in this area. But I still don’t like it in many ways. Its normal paradigm is simple imperative programming, and usually over abstraction. Some simple logic flow just easier to be read in text.
I can conclude OutSystems is not a completed solution for general purpose development, it is just a platform which provides simple template, components, programming. For systems which are data entry (what they call digital transformation), it is ok with an crazy license. However, if you want to implement some business logic, you are better to implement them in general programming language.
The components system really show what is leaky abstraction. For some plugin I have to understand what is doing behind. For native Cordova plugin, it is crazy to debug.
In a short run, it saves time, however, in a long run, it don’t have any advantages due to two reason: Its development speed will not able to catch up with technology trend, therefore, sometimes of its advantage is no longer an advantage, for example it have components, but frontend framework also have many components.
(Its component framework just copied from the open source, it is hard to find the documentation of the embedded version)
The eco-system just sucks, very few plugins because its plugins are not easy to make, and many of them are not supported by the Outsystems so most likely the plugin author will answer your question on the forum.
True I have seen it happen with Turbo Pacal/Delphi, but the biggest issue there was Borland almost going broke and continuous change of hands, which destroyed the trust on the product.
There aren't "toy" versions of Cisco, Oracle, DB2, SQL Server OLAP, Sitecore, AEM, LifeRay, WebSphere, SAP, Hybris, PTC, Aicas, Ricoh JVM, Gemalto M2M, ....
And yet there are plenty of projects available to work on with those stacks, including green field projects in companies adopting them.
Borland was going broke because they abandoned their core target market for chasing after the enterprise - and that was during a time before open source even got its name and developers expecting tools for free was a thing.
And have you seen the reputation these systems you mention have among developers (assuming they know about them, after all my original point was that the "enterprise pockets" requirements lead to obscurity - with the obvious exception of those that have been around for a very long time) and how clunky they are? Turbo Pascal and early Delphi never had the reputation that Oracle has nowadays.
And sure, you can find works with them but these systems are a minority and when they are used they are practically never chosen by developers themselves.
You do need C++ though if you're going to write stuff like A* pathfinding, complex scene setup like hex based 3D platforms. Again it's all doable in Blueprint and I'd often do it first in BP and then rewrite it in C++ for perf sakes.
So visual programming isn't broken and it works, and not necessarily at DSL level. The UX of the editor has to be fantastic though, for noobs as well as experts. That means good support for quickly producing nodes, finding existing code, refactoring support and Git support. You may think it's tedious but with habits and patterns, with a few key stroke I could program an entire component's behaviour in no time.
One thing that was magical is that with a heavy code base of visual nodes, the brain can find entire sections very quickly, a bit like that cave analogy in the article. You could group nodes with coloured rectangle etc. and the way they were laid out you'd have instant recollection of its internal workings. By seeing a vague layout of nodes I knew this was about joystick controller, player controller, shader, etc. It's a massive advantage and takes less strain on the brain to "READ" again the code. It makes code re-discovery so much easier. If I had some gnarly behaviour it would instantly show in the pattern of nodes as how they were laid out.
I'm convinced that if we had "as good" editor for web technologies, we could produce microservices and front-end code in the exact same fashion without writing a single line of code. It's just such a massive investment to _do it well_ I don't see it happen any time soon.