I spent the first years of my career writing "no code" signal processing platform. It had it's ups and downs. We indeed had a lot of non-coder users and it made prototyping simple to moderately complex pipelines quickly. However relatively soon for anything actually useful we had to write more components, some of which were not really reusable because it's non trivial to hide the complexity. At some point most workflows ended up in a "python script executor", because in the end code is always more expressive.
Also, no version control. Or, in our case since we used XML for output: poor version control. Reading horror stories about Excel also confirm this, it is hard to do correct complex programs in visual environments.
I run a no-code agency, and my conclusions match yours: no-code tools are great for getting up and running, and for involving less technical people in process development. But sooner or later you'll need to do something that is outside the boundaries of the no-code platform's feature set, at which point extending it becomes a huge mess, because you then are forced to write code and hook it up to the no-code process in very strange and awkward ways.
Like you say, lack of source control is the biggest pain point.
> Also, no version control. Or, in our case since we used XML for output: poor version control. Reading horror stories about Excel also confirm this, it is hard to do correct complex programs in visual environments.
Just because some visual systems don’t have version control doesn’t mean they can’t exist. It isn’t like text-based diffing just poofed into existence. Someone had to build them, and even then they aren’t all created equal. For example, I use P4Merge to diff and merge from Git instead of using the poor UX of the built-in terminal tools.
I would argue that visual programming languages are much more ready to be diffed and merged than text since they usually already represent a graph.
Going to guess GNURadio based on calling it a Python script executor that outputs xml. If that's true, I'd that it really starts to break down when the desired logic breaks from the "apply sequential steps to a stream of contiguous data" paradigm.
I worked for a startup that built a no code platform. The experience you had, was the same experience that the majority of our customers had. Its a general problem with low code. We tried to make the software easily extendable so that developers could refactor away the complexity, by easily adding new tools to the design surface. The approach worked quite well for internal projects, but was at odds with the marketing approach to the product, so it was never pushed to clients. Clients were sold a utopia of business analysts dropping some components onto a designer and hey presto. Low code can work, but in the same way as traditional dev, where code should be refactored into components that's are easy to reason about. The problem is that this is hard to sell. There is a very nice balance to be had with combining low code with traditional dev. Its just very hard to find that balance. Its far easier to write good code in a traditional language that in a low code environment. If you add to that the expectations created from low code demos, its mostly a recipe for disaster.
Difficulty in version control and testing is one of the reasons I don't think I could ever work in a no-code environment. It's an issue that I'm sure many people don't care much about but it's also a big reason I doubt no-code will ever overtake custom code solutions.
I have a similar experience as you. I worked on a Neuroscience/BCI focused signal processing platform, and also came up with the idea of having a "Python script executor". We used YAML though to store the pipelines. Seems like a very recurring problem.
I started building "no code" tools since 2004. I am also the author of codeflow - a not yet open sourced visual programming platform. I wish no code distinguishes between frontend no code(webflow, wix etc), backend no code(codeflow, mulesoft etc) and full stack no code(outflow, mendix etc). First of all this "no code" is being used for decades in fortune 500 companies and many of their major backend services are run on yesteryear no code. In fact it wouldn't be wrong if to state that all big financial companies use no code as part of their major backend stack (its called in different names such as middleware/soa/integration/etl etc), but they are all visual, drag-and-drop backend/business logic builders that would have required complex coding without them.
In my decades of experience there are of course many ups in no code, but as with any paradigm, the downs are highlighted the most and especially when you want to disrupt the text-based programming world that existed for almost a century now.
The major complaints about visual programming environment (backend) are:
1. Code is more expressive for experienced devs
Its true that code is much more expressive than generic graphical programming platforms for writing algorithms.. But how many of us write algorithms on daily basis?. What all of us do is glue various reusable pieces together to build the business logic. And for gluing graphical programming is actually superior - you can discover easily, dependent fields can be expressed easily etc. You need to use code in a properly designed no code system, but it's only 5% of the project. Now coming back to code being more expressive, if you look at algorithmic visual programming platforms designed for expressive coding like DRAKON (https://en.wikipedia.org/wiki/DRAKON), you can see that they are equally good or even better than coding.
2. No or degraded version control experience.
This is true as visual programs are still written to file as xml or json and there is disconnect between committing that vs seeing actual programs as graphs. This is a difficult problem to solve.
3. Incompatible or poor tooling
This is related to above point. Because visual programming tools need to distribute with a custom made IDE, the common tooling and CLI other available for generic text based programs can be lacking.
4. Hitting a wall
This is one of the biggest drawback I have heard from the devs so far. To be honest which programming platform have not made you hit a wall? In node.js you hit the multi-thread wall, in Java you hit the thread safety/performance(high memory usage) wall. In python you hit the performance wall. How do you solve it? Well in python you solve it using C or ASM libraries - and expose it to python. but you seldom hear a cry from python devs saying they reverted to C because python is slow or lacking.. Cos you learn to use the right tool for the right purpose. Similarly a well designed visual tool will let you do few things extremely well, but like no single programming platform can do everything extremely well, same is with no code or visual tools - for e.g. see DRAKON for writing expressive or algorithmic code.
5. Performance not on par.
Most of visual programs tend to not focus on performance as the priority is different. However this can be solved with compiling the graphs to native code.
When we built Codeflow, we tried to solve 4 and 5 and in our opinion we succeeded to good extend. 2 and 3 requires more effort from the vendor and the community (which is hard because every visual tool is unique). and 1 is possible but require more research.
One way to think about visual programming is this way - imagine a world where graphical vector image editing tools evolved without mouse - i mean you literally have to code everything - right from the pixel you need to edit, the selection - everything. Smart designers (or more of coders) became experts in it and they can produce some great quality images. The tooling is also great as the tool existed for decades with hundreds of libraries and ecosystem surrounding it. Now you come up with a new paradigm where you can use mouse and make it easy for novice designers to use it - there are two benefits you tout - More artists as opposed to coders can now create images - its much more easy to build the images. The coders on the other hand are not in favour of the new tool both subconsciously and consciously. Consciously because the new tool, while better in many aspects are no where near the previous precise tool in expressing the image - and tooling as well (version control, transformations, plugins etc). Subconsciously because somewhere they feel their decades of experience is not relevant anymore.. this is controversial but i have felt it when interacting with senior devs. (Similar to how many don't want to move away from vi/m to vs code for e.g).
On Mac, Apple apps and other "Mac-native" programs save revisions automatically in the background. At any point, the user can select "Show Revision History" and scroll through a timeline of changes. I'm not sure if this works with Excel, but it does with iWork/Numbers, and I use it all the time.
Now, Apple's implementation is just a simple timeline—there's no equivalent of version tagging, or git blame. But all of that could be done within a graphical environment similar to Apple's. It wouldn't be as advanced as Git, but I bet it could do what 95% of people actually use Git for.
My experience with visual programming is that, as the required complexity of the tasks grows even just minimally, it frustrates skilled users without really empowering unskilled ones.
That's because the unskilled stays unskilled for a reason: they can't or won't dedicate the amount of focus necessary to learn a technology to any meaningful degree. They will do the minimum they are (very explicitly) trained to do, and that's it. Basic scripting is not hard; if you cannot (or will not) do it, chances are you cannot (or will not) formalize even slightly-complex tasks in a visual environment either.
And of course, visual environments are a productivity killer for the skilled, who then feel frustrated and eventually drop back into textual modes. This is self-evident.
Sadly, it's a marketing dream, so it keeps popping up in all companies in my niche. "If only we build a no-code graphical UI, accountants will become programmers!" - no they will not. If they were really interested in automating tasks and modelling problems, they would have already learnt VBA, which is very simple - smart accountants do it already. People capable of doing advanced math are capable of programming if they really want. Accountants who won't learn VBA will not meaningfully engage with visual paradigms either, because they are simply not interested in these activities. What really needs to happen is to empower smart accountants to be productive without involving IT. That doesn't need visual programming, it just needs a powerful set of VBA apis unshackled from "enterprise" permission systems.
> That's because the unskilled stays unskilled for a reason: they can't or won't dedicate the amount of focus necessary to learn a technology to any meaningful degree.
The entire history of computers and software betrays this argument.
Every time we transitioned from a blank, text-command driven UI, to a visual one, we dramatically increased the percentage of the general population able to use something.
Think the transition from MS-DOS to Windows, UNIX to OSX, etc. By representing concepts visually, humans find them easier to understand.
In fact, I’d argue, most software innovation today is just making visual UI’s better. Think the single doc mode (photoshop) to artboard mode (sketch, figma). Single purpose (excel, word) to multipurpose (notion). Etc.
Notion is blowing up with 13 year old kids on Tiktok because it’s an easier UI to do spreadsheets and create documents and websites with. Which are fundamentally valuable things. In software, what is valuable, will be made easier over time.
Most B2B Saas tools are just crud apps. Not only is there no reason coding these apps has to stay complicated, but there’s economic incentive in making it easier.
Unfortunately, many people have a vested interest in keeping things complicated. Like people who get paid to create CRUD apps.
As the saying goes, it is difficult to get a man to understand something when his salary depends on his not understanding it.
That sounds like the trite old University Professor that says to 4/5ths of their students that didnt get an A: "You lack the passion and maybe you are not made for this".
@murukesh_s post wrote the retourt to that. Pointers and Windows had a substantial impact on shaping the reality we live in now.
Putting all the responsibillity on the users shoulders and their "intelligence in math" is way to ego focused IMO.
When I started my last job, I thought I was going to be writing a lot of Python and C. It turned out that the position had a lot more React and TypeScript than I expected, and at first I was annoyed and afraid. I wasn't a frontend developer---or worse, a designer---but I didn't have much of a choice, so I dug in and learned the stack.
At first I resisted every change. What good is VS Code when I have Vim? Why would I learn TypeScript when vanilla JS has "worked" for me for so long? What's a Webpack config?
Once I began using the tools that my coworkers recommended, I started treading water and even swimming with purpose in the ocean of Web UI technology. I still have a lot to learn, but I probably would have kept on avoiding this area if my situation hadn't forced me into it. Letting my guard down and following the trends in my group helped a lot in this case.
The best lessons I learned during that period are that learning can't kill me and using good tools doesn't make you a bad engineer.
I'm glad that you had such a positive experience! After years of web development I'm just burnt out by the tooling.
Layers upon layers, just make debugging so unnecessarily hard.
The tooling is brittle and buggy.
I've seen typescript compiler bugs, webpack segfaults, and whatnot.
I've started to ban typescript and jsx from all future projects, and it's better, but still a nightmare.
I hate to be the guy who say back in my day... but back in the 90's there was a tool by Borland (anyone remember them?) who created a no-code, low-code tool called Delphi. It was awesome, I used it on a few front end projects and it active data source tools made laying out complex UI's so painless.
Of course this was back before Rest APIs and the internet for most part. But it kicked some serious ass.
Speaking as a once professional Delphi programmer, I can assure you that Delphi programs have lots of textual code in them. The IDE generates empty functions for event handlers, but you have to write textual code to do the actual handling.
Unless I have stumbled across something different it appears as if this is still being developed. I have no idea if what I have linked is even remotely close to what you remember it being.
Visual BASIC is even older than Delphi and was the benchmark for low/no code app development. We called them RAD tools, "rapid application development". If you really wanna go back, hypercard on Macintosh was kinda the original that inspired them all (and even inspired the web we have today).
There’s also Clarion, whose platform is intended to generate code for you and you input your own custom programming and business logic if needed for a basic B2B CRUD desktop app.
Pretty much all of the examples you used of codeless tooling (drag 'n' drop programming, visual state machines and graph editors, database FK diagrams, etc) still still require an undergrad-level CS education - or considerable experience - to understand and use correctly - to that extent they're just time-saving tools that use a graphical UI to hand-wave away tedium in software development (not to denigrate them: time-saving tools and eliminating tedium is important!)- but I argue it's a disservice to everyone to let the uninitiated use these easy-to-use tools for production systems without necessary formal introduction (of course they're still a fantastic didactical aid).
A great example of GUI winning over code or the command-line is a UI to allow people to arbitrarily reorder items: a drag-the-grab-handle UI is a hundred-fold better than manually entering new sort-orders for each item in a command-line array or other UI. This is, at least, the very kinds of things that visual tooling should be used for by everyone from Scratch-lang kids to SV elites.
Another example you gave is of "visual interface editing" - but while you acknowledge the problems that FrontPage and Dreamweaver had decades ago, WYSIWYG is still dead, having retreated back to its origins in print-media design. The old VB6-era "drag controls from the toolbox onto the form surface" is dead because one cannot easily express any kind of non-trivial layout logic using that approach: things like CSS' flexbox, CSS grid (with auto-placement and auto-flow) and @media queries absolutely require one to grok CSS' visual formatting model, which in-turn implies someone will already be more expressive by writing CSS by hand instead of using a mouse to choose from some predefined options (I appreciate XCode's Interface Builder and constraints model is very nice and shows how it can be done right, but explaining how the constraints system works and how it should be used ends up with me having to redo the work of the designer on my team. Ugh.
Another issue with visual-tooling is that unless the tooling vendor happens to control the spec that it's generating code for then the tooling will invariably and inevitably fall-behind and have limited value for more advanced users (e.g. TopStyle) - or if the tooling is meant to abstract-away multiple different backends then the tooling is doomed to support only a common denominator and won't be taken seriously by too many people (e.g. MS Word's Save-for-Web) - we've seen both of these happen with visual tooling for the web, especially with Chrome's rapid frequent releases and the everchanging spec for CSS. Web-design is now even more inaccessible as it was in the late-1990s (and is no-longer the butt of jokes: turns out the CEO's 12 year-old nephew can't apply CSS selector specificity rules - which, I note, is another angle of CSS that visual tooling just can't accommodate).
I've had a lot of frustrations with "APIs are eating the world" over the last two years.
1. "No code" interacts badly with "infrastructure as code." Instead of a client library, you get a web admin console. If you want your configurations to be reproducible, durable, and auditable, you now have to build a client yourself or use a third-party client. Case in point: Snowflake directing users to a buggy third-party Terraform provider built by some random organization that's always several versions behind.
2. "No code" is much harder to test. You have to deploy changes to see them. You don't have the tools to mock them out. There is no local testing. At best, you can have a test environment. But to do end-to-end testing within it, you need to rebuild basically a mirror image of prod, since you can't mock any API boundaries nearly as easily anymore. As a result, a lot of "testing" ends up being done by pushing to prod and trying to roll back when needed.
3. "No code" often means surprise upgrades and feature changes that are out of your control. Some vendors (e.g., Databricks) mercifully display a toast in the GUI prompting you to update. Many just post some release notes somewhere and call it a day.
So, using Unreal Engine you can literally make an entire 3D game with full next-gen graphics without dropping a line of code.
Now, shipping it to console will most definitely require some C++ and so would Steam I think.
But "Blueprints" are a visual programming language that seriously kicks ass. I believe the end product even compiles down to C++ classes so you don't lose much performance in release mode.
The only thing where it makes no sense is algorithms like A* Path finding, which are far more suited to be written in code than a gezillion nodes linked to each other in a screen of Spaghetti.
I do work in the Salesforce ecosystem, and they really push "citizen developers" and "administrators can write apps with low-code tools" and they push their low-code tool, Flow, as much as they can.
I hate the clicky-draggy-droppy so much that I'm learning Racket to make a DSL that will write the XML's that Flow code is when you download it locally.
I definitely feel that. The number of weird database issues that come up with flows (SOQL limits that non-developers don't think of) is mind numbing.
My take away is you can't mix custom (APEX) code with flows without a lot of effort. At that point, giving people a database and an excel license seems the more honest route.
When I started with Salesforce 6 years ago,I looked at Flow, I thought 'screw this' and went on learning Apex instead. Even. after all these years I barely touched it.
Isn’t this all on the same spectrum as all programming? Every programmer is using someone else’s code at all times. Even if you are writing in assembly, you are still relying on a compiler to turn your written words into machine code.
Still not sure what distinguishes "no code" from pretty much every other software. Isn't Excel or Blogger "no code" tools? Why are these newish GUI based applications in this "new" category?
What you want is "low code". Or less rhymey but more accurate: "minimal code".
Historically visual programming tools did not create this. In fact they generated very bloated code. So visual programming tools got a bad rap.
But there's no inherent reason why they need to generate bloated code. And if well done they can indeed generate minimal code (and program synthesis advancements will help a lot here).
We worked on this from ~2010 at Nudge and we eventually solved it with the discovery of Tree Notation.
I don't get it. The descriptions are pretty wild and make little sense to me:
> Tree Notation is like a 2-dimensional binary and could be used at the lowest levels of computing.
But in practice, we have:
- Tree Notation, both data structure and a textual data format. A data structure only has one datatype, which is string value + a list of children. A textual format uses significant whitespace both in the beginning of the line and between the values. It seems to really hate punctuation for some reason, there are no quoting mechanisms or even quotes.
- Tree Language, a parser/lexer combo which generates AST in Tree Notation format. It allows embedding Javascript in the generated output.
- A bunch of examples made using the parser above -- there is some plotting tool for web data, HTML generator, and few toy DSLs?
Overall, I don't see anything particularly unusual about it. I see no advantage of Tree Notation data structure compared to usual string/int/list/dict core types most languages have. I see no advantage of Tree Notation textual format compared to others -- while it may be OK for very simple cases, I have a feeling that the lack of quoting and inability to wrap lines would get annoying fast. The Tree Language grammar does not seem very elegant either, it certainly seems harder to read than BNF variants.
What you want is "low code". Or less rhymey but more accurate: "minimal code".
Kind of. What I really want is something that can round-trip to a textual representation and is heavily visual with the possibility of adding custom actions. I guess a BizTalk Orchestration built from the start to be a programming tool. I often think in my retirement I am going to take a crack at doing Excel as graph of tables and components.
I feel like I'm effectively writing a "no code" tool at the moment; it's a GUI whose user inputs will eventually be output as a configuration file that is fed into our core system (mobile network signal processing, in the broadest sense of the word).
In theory, end-users and operators could work in the configuration files directly themselves (it's a combination of XML templates and files, and .ini-like config files). The GUI is there to prevent footguns and add convenience.
Anyway it's not very visual, it's a lot of forms and pop-up segments with more forms, but still, one could argue it's a no-code environment. I should look into the area.
Mind you, I'm working on a rebuild and at the current rate it'll take me years to even start thinking of doing anything more advanced than replacing the existing forms.
[personal rant[ I'm not sure if I want to spend the next years at this company either; they're doing well enough financially but it's a slow burner. They're hiring, but the wages are stagnant and dare I say below market rate. I'll have to review in 6 months or end of year.
But I can see the lure for masses, driven by the startup subculture, but the truth is that if you can master something like bubble, the transition to actual coding would be seamless and often very liberating.
I could only stand Bubble for a day or two before it became too restrictive and yet complex for doing very basic stuff. Buffer suffers from the same issues as other no-code solutions but also has a subpar UI.
There is a place for code, no code and eveything in between. Code is more expressive. No code is generally faster (in the limited domain for which it is intended).
The big mistake comes when no code tools are overhyped, as happens so often. No code tools are only ever going to be applicable to relatively narrow domains. Trying to make them completely general, like a general coding language, is invariably a bad idea.
My https://www.easydatatransform.com/ tool is primarily a visual drag and drop tool for transforming data (join, filter, pivot etc). But one of the 50 transforms is a Javascript transform, so you can drop down and do some coding if you have a really obscure data transformation. That seems like the best of both worlds to me.
[+] [-] yoz-y|5 years ago|reply
Also, no version control. Or, in our case since we used XML for output: poor version control. Reading horror stories about Excel also confirm this, it is hard to do correct complex programs in visual environments.
[+] [-] enraged_camel|5 years ago|reply
Like you say, lack of source control is the biggest pain point.
[+] [-] bmitc|5 years ago|reply
Just because some visual systems don’t have version control doesn’t mean they can’t exist. It isn’t like text-based diffing just poofed into existence. Someone had to build them, and even then they aren’t all created equal. For example, I use P4Merge to diff and merge from Git instead of using the poor UX of the built-in terminal tools.
I would argue that visual programming languages are much more ready to be diffed and merged than text since they usually already represent a graph.
[+] [-] apcragg|5 years ago|reply
[+] [-] rajinl|5 years ago|reply
[+] [-] xmprt|5 years ago|reply
[+] [-] ktta|5 years ago|reply
[+] [-] treeman79|5 years ago|reply
Almost everyone that agreed are still there.
Great way to kill a career.
[+] [-] murukesh_s|5 years ago|reply
In my decades of experience there are of course many ups in no code, but as with any paradigm, the downs are highlighted the most and especially when you want to disrupt the text-based programming world that existed for almost a century now.
The major complaints about visual programming environment (backend) are:
1. Code is more expressive for experienced devs
Its true that code is much more expressive than generic graphical programming platforms for writing algorithms.. But how many of us write algorithms on daily basis?. What all of us do is glue various reusable pieces together to build the business logic. And for gluing graphical programming is actually superior - you can discover easily, dependent fields can be expressed easily etc. You need to use code in a properly designed no code system, but it's only 5% of the project. Now coming back to code being more expressive, if you look at algorithmic visual programming platforms designed for expressive coding like DRAKON (https://en.wikipedia.org/wiki/DRAKON), you can see that they are equally good or even better than coding.
2. No or degraded version control experience.
This is true as visual programs are still written to file as xml or json and there is disconnect between committing that vs seeing actual programs as graphs. This is a difficult problem to solve.
3. Incompatible or poor tooling
This is related to above point. Because visual programming tools need to distribute with a custom made IDE, the common tooling and CLI other available for generic text based programs can be lacking.
4. Hitting a wall
This is one of the biggest drawback I have heard from the devs so far. To be honest which programming platform have not made you hit a wall? In node.js you hit the multi-thread wall, in Java you hit the thread safety/performance(high memory usage) wall. In python you hit the performance wall. How do you solve it? Well in python you solve it using C or ASM libraries - and expose it to python. but you seldom hear a cry from python devs saying they reverted to C because python is slow or lacking.. Cos you learn to use the right tool for the right purpose. Similarly a well designed visual tool will let you do few things extremely well, but like no single programming platform can do everything extremely well, same is with no code or visual tools - for e.g. see DRAKON for writing expressive or algorithmic code.
5. Performance not on par.
Most of visual programs tend to not focus on performance as the priority is different. However this can be solved with compiling the graphs to native code.
When we built Codeflow, we tried to solve 4 and 5 and in our opinion we succeeded to good extend. 2 and 3 requires more effort from the vendor and the community (which is hard because every visual tool is unique). and 1 is possible but require more research.
One way to think about visual programming is this way - imagine a world where graphical vector image editing tools evolved without mouse - i mean you literally have to code everything - right from the pixel you need to edit, the selection - everything. Smart designers (or more of coders) became experts in it and they can produce some great quality images. The tooling is also great as the tool existed for decades with hundreds of libraries and ecosystem surrounding it. Now you come up with a new paradigm where you can use mouse and make it easy for novice designers to use it - there are two benefits you tout - More artists as opposed to coders can now create images - its much more easy to build the images. The coders on the other hand are not in favour of the new tool both subconsciously and consciously. Consciously because the new tool, while better in many aspects are no where near the previous precise tool in expressing the image - and tooling as well (version control, transformations, plugins etc). Subconsciously because somewhere they feel their decades of experience is not relevant anymore.. this is controversial but i have felt it when interacting with senior devs. (Similar to how many don't want to move away from vi/m to vs code for e.g).
[+] [-] Wowfunhappy|5 years ago|reply
On Mac, Apple apps and other "Mac-native" programs save revisions automatically in the background. At any point, the user can select "Show Revision History" and scroll through a timeline of changes. I'm not sure if this works with Excel, but it does with iWork/Numbers, and I use it all the time.
Now, Apple's implementation is just a simple timeline—there's no equivalent of version tagging, or git blame. But all of that could be done within a graphical environment similar to Apple's. It wouldn't be as advanced as Git, but I bet it could do what 95% of people actually use Git for.
[+] [-] toyg|5 years ago|reply
That's because the unskilled stays unskilled for a reason: they can't or won't dedicate the amount of focus necessary to learn a technology to any meaningful degree. They will do the minimum they are (very explicitly) trained to do, and that's it. Basic scripting is not hard; if you cannot (or will not) do it, chances are you cannot (or will not) formalize even slightly-complex tasks in a visual environment either.
And of course, visual environments are a productivity killer for the skilled, who then feel frustrated and eventually drop back into textual modes. This is self-evident.
Sadly, it's a marketing dream, so it keeps popping up in all companies in my niche. "If only we build a no-code graphical UI, accountants will become programmers!" - no they will not. If they were really interested in automating tasks and modelling problems, they would have already learnt VBA, which is very simple - smart accountants do it already. People capable of doing advanced math are capable of programming if they really want. Accountants who won't learn VBA will not meaningfully engage with visual paradigms either, because they are simply not interested in these activities. What really needs to happen is to empower smart accountants to be productive without involving IT. That doesn't need visual programming, it just needs a powerful set of VBA apis unshackled from "enterprise" permission systems.
[+] [-] pembrook|5 years ago|reply
The entire history of computers and software betrays this argument.
Every time we transitioned from a blank, text-command driven UI, to a visual one, we dramatically increased the percentage of the general population able to use something.
Think the transition from MS-DOS to Windows, UNIX to OSX, etc. By representing concepts visually, humans find them easier to understand.
In fact, I’d argue, most software innovation today is just making visual UI’s better. Think the single doc mode (photoshop) to artboard mode (sketch, figma). Single purpose (excel, word) to multipurpose (notion). Etc.
Notion is blowing up with 13 year old kids on Tiktok because it’s an easier UI to do spreadsheets and create documents and websites with. Which are fundamentally valuable things. In software, what is valuable, will be made easier over time.
Most B2B Saas tools are just crud apps. Not only is there no reason coding these apps has to stay complicated, but there’s economic incentive in making it easier.
Unfortunately, many people have a vested interest in keeping things complicated. Like people who get paid to create CRUD apps.
As the saying goes, it is difficult to get a man to understand something when his salary depends on his not understanding it.
[+] [-] mightyRodri|5 years ago|reply
@murukesh_s post wrote the retourt to that. Pointers and Windows had a substantial impact on shaping the reality we live in now. Putting all the responsibillity on the users shoulders and their "intelligence in math" is way to ego focused IMO.
[+] [-] bmgxyz|5 years ago|reply
At first I resisted every change. What good is VS Code when I have Vim? Why would I learn TypeScript when vanilla JS has "worked" for me for so long? What's a Webpack config?
Once I began using the tools that my coworkers recommended, I started treading water and even swimming with purpose in the ocean of Web UI technology. I still have a lot to learn, but I probably would have kept on avoiding this area if my situation hadn't forced me into it. Letting my guard down and following the trends in my group helped a lot in this case.
The best lessons I learned during that period are that learning can't kill me and using good tools doesn't make you a bad engineer.
[+] [-] j-pb|5 years ago|reply
Layers upon layers, just make debugging so unnecessarily hard. The tooling is brittle and buggy.
I've seen typescript compiler bugs, webpack segfaults, and whatnot. I've started to ban typescript and jsx from all future projects, and it's better, but still a nightmare.
[+] [-] BatFastard|5 years ago|reply
[+] [-] zabzonk|5 years ago|reply
[+] [-] adjagu|5 years ago|reply
https://en.wikipedia.org/wiki/Delphi_(software)
https://en.wikipedia.org/wiki/History_of_Delphi_(software)
[+] [-] ekianjo|5 years ago|reply
[+] [-] wormik|5 years ago|reply
[+] [-] qbasic_forever|5 years ago|reply
[+] [-] acwan93|5 years ago|reply
I guess like history, SW dev trends also rhyme.
[+] [-] ant6n|5 years ago|reply
[+] [-] sels|5 years ago|reply
[+] [-] swyx|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] DaiPlusPlus|5 years ago|reply
A great example of GUI winning over code or the command-line is a UI to allow people to arbitrarily reorder items: a drag-the-grab-handle UI is a hundred-fold better than manually entering new sort-orders for each item in a command-line array or other UI. This is, at least, the very kinds of things that visual tooling should be used for by everyone from Scratch-lang kids to SV elites.
Another example you gave is of "visual interface editing" - but while you acknowledge the problems that FrontPage and Dreamweaver had decades ago, WYSIWYG is still dead, having retreated back to its origins in print-media design. The old VB6-era "drag controls from the toolbox onto the form surface" is dead because one cannot easily express any kind of non-trivial layout logic using that approach: things like CSS' flexbox, CSS grid (with auto-placement and auto-flow) and @media queries absolutely require one to grok CSS' visual formatting model, which in-turn implies someone will already be more expressive by writing CSS by hand instead of using a mouse to choose from some predefined options (I appreciate XCode's Interface Builder and constraints model is very nice and shows how it can be done right, but explaining how the constraints system works and how it should be used ends up with me having to redo the work of the designer on my team. Ugh.
Another issue with visual-tooling is that unless the tooling vendor happens to control the spec that it's generating code for then the tooling will invariably and inevitably fall-behind and have limited value for more advanced users (e.g. TopStyle) - or if the tooling is meant to abstract-away multiple different backends then the tooling is doomed to support only a common denominator and won't be taken seriously by too many people (e.g. MS Word's Save-for-Web) - we've seen both of these happen with visual tooling for the web, especially with Chrome's rapid frequent releases and the everchanging spec for CSS. Web-design is now even more inaccessible as it was in the late-1990s (and is no-longer the butt of jokes: turns out the CEO's 12 year-old nephew can't apply CSS selector specificity rules - which, I note, is another angle of CSS that visual tooling just can't accommodate).
[+] [-] legerdemain|5 years ago|reply
1. "No code" interacts badly with "infrastructure as code." Instead of a client library, you get a web admin console. If you want your configurations to be reproducible, durable, and auditable, you now have to build a client yourself or use a third-party client. Case in point: Snowflake directing users to a buggy third-party Terraform provider built by some random organization that's always several versions behind.
2. "No code" is much harder to test. You have to deploy changes to see them. You don't have the tools to mock them out. There is no local testing. At best, you can have a test environment. But to do end-to-end testing within it, you need to rebuild basically a mirror image of prod, since you can't mock any API boundaries nearly as easily anymore. As a result, a lot of "testing" ends up being done by pushing to prod and trying to roll back when needed.
3. "No code" often means surprise upgrades and feature changes that are out of your control. Some vendors (e.g., Databricks) mercifully display a toast in the GUI prompting you to update. Many just post some release notes somewhere and call it a day.
[+] [-] keyle|5 years ago|reply
Now, shipping it to console will most definitely require some C++ and so would Steam I think.
But "Blueprints" are a visual programming language that seriously kicks ass. I believe the end product even compiles down to C++ classes so you don't lose much performance in release mode.
The only thing where it makes no sense is algorithms like A* Path finding, which are far more suited to be written in code than a gezillion nodes linked to each other in a screen of Spaghetti.
[+] [-] ralphc|5 years ago|reply
[+] [-] jbm|5 years ago|reply
My take away is you can't mix custom (APEX) code with flows without a lot of effort. At that point, giving people a database and an excel license seems the more honest route.
[+] [-] cosmodisk|5 years ago|reply
[+] [-] littlecranky67|5 years ago|reply
But I also hear "future rewrite by a contracted professional after MVP validation" which I like.
[+] [-] cortesoft|5 years ago|reply
[+] [-] boh|5 years ago|reply
[+] [-] breck|5 years ago|reply
Historically visual programming tools did not create this. In fact they generated very bloated code. So visual programming tools got a bad rap.
But there's no inherent reason why they need to generate bloated code. And if well done they can indeed generate minimal code (and program synthesis advancements will help a lot here).
We worked on this from ~2010 at Nudge and we eventually solved it with the discovery of Tree Notation.
[+] [-] theamk|5 years ago|reply
I don't get it. The descriptions are pretty wild and make little sense to me:
> Tree Notation is like a 2-dimensional binary and could be used at the lowest levels of computing.
But in practice, we have:
- Tree Notation, both data structure and a textual data format. A data structure only has one datatype, which is string value + a list of children. A textual format uses significant whitespace both in the beginning of the line and between the values. It seems to really hate punctuation for some reason, there are no quoting mechanisms or even quotes.
- Tree Language, a parser/lexer combo which generates AST in Tree Notation format. It allows embedding Javascript in the generated output.
- A bunch of examples made using the parser above -- there is some plotting tool for web data, HTML generator, and few toy DSLs?
Overall, I don't see anything particularly unusual about it. I see no advantage of Tree Notation data structure compared to usual string/int/list/dict core types most languages have. I see no advantage of Tree Notation textual format compared to others -- while it may be OK for very simple cases, I have a feeling that the lack of quoting and inability to wrap lines would get annoying fast. The Tree Language grammar does not seem very elegant either, it certainly seems harder to read than BNF variants.
[+] [-] k__|5 years ago|reply
If I can use a library or a framework that saves me from writing thousands of LoC, that's low-code too.
[+] [-] protomyth|5 years ago|reply
Kind of. What I really want is something that can round-trip to a textual representation and is heavily visual with the possibility of adding custom actions. I guess a BizTalk Orchestration built from the start to be a programming tool. I often think in my retirement I am going to take a crack at doing Excel as graph of tables and components.
[+] [-] auggierose|5 years ago|reply
[+] [-] Cthulhu_|5 years ago|reply
In theory, end-users and operators could work in the configuration files directly themselves (it's a combination of XML templates and files, and .ini-like config files). The GUI is there to prevent footguns and add convenience.
Anyway it's not very visual, it's a lot of forms and pop-up segments with more forms, but still, one could argue it's a no-code environment. I should look into the area.
Mind you, I'm working on a rebuild and at the current rate it'll take me years to even start thinking of doing anything more advanced than replacing the existing forms.
[personal rant[ I'm not sure if I want to spend the next years at this company either; they're doing well enough financially but it's a slow burner. They're hiring, but the wages are stagnant and dare I say below market rate. I'll have to review in 6 months or end of year.
[+] [-] zed88|5 years ago|reply
https://bubble.io/
But I can see the lure for masses, driven by the startup subculture, but the truth is that if you can master something like bubble, the transition to actual coding would be seamless and often very liberating.
[+] [-] arkitaip|5 years ago|reply
[+] [-] hermitcrab|5 years ago|reply
The big mistake comes when no code tools are overhyped, as happens so often. No code tools are only ever going to be applicable to relatively narrow domains. Trying to make them completely general, like a general coding language, is invariably a bad idea.
My https://www.easydatatransform.com/ tool is primarily a visual drag and drop tool for transforming data (join, filter, pivot etc). But one of the 50 transforms is a Javascript transform, so you can drop down and do some coding if you have a really obscure data transformation. That seems like the best of both worlds to me.
[+] [-] jackrowelle|5 years ago|reply
[+] [-] anotherevan|5 years ago|reply
[+] [-] wwww4all|5 years ago|reply
As the saying goes, “What has happened before, will happen again”.
Soon enough, there will be a new scripting language to simplify managing all no code services from the terminal. NoBash.