Throughout my career in computing I have heard people claim that the solution to the software problem is automatic programming. All that one has to do is write the specifications for the software, and the computer will find a program [...]
The oldest paper known to me that discusses automatic programming was written in the 1940s by Saul Gorn when he was working at the Aberdeen Proving Ground. This paper, entitled “Is Automatic Programming Feasible?” was classified for a while. It answered the question positively.
At that time, programs were fed into computers on paper tapes. The programmer worked the punch directly and actually looked at the holes in the tape. I have seen programmers “patch” programs by literally patching the paper tape.
The automatic programming system considered by Gorn in that paper was an assembler in today’s terminology. All that one would have to do with his automatic programming system would be to write a code such as CLA, and the computer would automatically punch the proper holes in the tape. In this way, the programmer’s task would be performed automatically by the computer.
In later years the phrase was used to refer to program generation from languages such as IT, FORTRAN, and ALGOL. In each case, the programmer entered a specification of what he wanted, and the computer produced the program in the language of the machine. In short, automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer. Research in automatic programming is simply research in the implementation of higher-level programming languages.
And it seems to me that progress is going in the opposite direction than "they" want. Every time you move up the abstraction stack, you're surrendering some decision-making to the lower levels. If the underlying technologies guess right every time, you have no need to understand what they're doing. The first time they guess wrong, you have to spend a lot of time understanding not only how the lower layers work, and not only why they did the "wrong" thing in this one instance, but how to fiddle correctly with the layer you're operating at to get the lower layers to behave properly. You can work quickly with the high-level abstractions only as long as you understand the lower levels reasonably well.
Optimal machine learning requires a good understanding of memory cache hierarchies, parallel instructions and complexity theory - not to mention the statistics and calculus that it's formed on. And "optimal" isn't some trivial "save a few seconds" but often "return an answer within the lifetime of the universe".
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
If you're fine with lower performance (which is reasonable for a lot of application cases, so I almost entirely agree with you), you certainly don't have to deal with this.
e.g. ad-hoc exceptions -> errors as plain values, but with "railway-oriented programming" techniques that make them as easy to work with as exceptions
e.g. runtime-managed garbage collection -> rust-style borrow checker ad-hoc in the compiler -> haskell/idris-style linearity in the type system
e.g. "magic" green-threading -> explicit-but-easy async/await
e.g. behind-the-scenes MVCC in databases -> explicit event sourcing
SQL in a nutshell.
With the years and postmortems gone by it has grown half-assed attempts at version control, code review, unit testing, deployment pipelines, etc. Now it’s very obviously just a shitty, hobbled software development environment. It’s used primarily because the team that owns it is aggressive about blocking design reviews for “duplication of effort” if you propose to use normal software development tools anywhere near its domain.
This is absolutely one of my biggest pain-points with "no-code" solutions. Even trying to track revisions to something relatively simple like a word document over time is a big pain compared to tracking revisions to source code or a configuration file. Trying to get a grip on how people are fiddling with a no-code product from the audit logs is incredibly difficult, never mind trying to track down a change from 1 year ago. Often changes won't appear on audit logs at all or they won't be explained in enough detail and the format of the logs will have little resemblance to how things are actually configured. You can use some no-code solution to modify a SQL query under the hood and the audit log will just say "THIS USER CHANGED THIS QUERY" and that's all the detail you get! It's frequently difficult to explain to your peers how you're going to change a system without showing them a bunch of screenshots and going "Well I'm going to tick this box and move the green rectangle over here and link it to the orange oval". Rolling back changes can often be impossible without rolling back EVERY change between now and when the first incorrect change was made.
I use code, and these problems just don't happen! It's only when people are using some wonderful "user-friendly" solution that things get so jacked up.
Especially when it is anything involving finances, even tangentially.
Making it easy for non-engineers to change business rules on the fly without a code deploy sounds nice in theory, until you think about it for a few more minutes.
The other thing is there may be no way for me to, say, get a list of all the forms associated with a certain table and the fields they contain in some programmatic way (without browser automation, which is something I use not infrequently with a no-code system) and APIs that are almost complete but not quite.
<for list="a,b,c,d,e" param="letter">
<sequential>
<echo>Letter @{letter}</echo>
</sequential>
</for>
Let's just say that it was a more brutal age, and we were more accustomed to such horrors. :)
Inductive progamming is very much a branch of machine learning and that's the reason most haven't heard of it (i.e. it's machine learning that is not deep learning). The main approaches are Inductive Functional Programming (IFP) and Inductive Logic Programming (ILP, which I study for my PhD). IFP systems learn programs in functional programming languages, like Haskell, and ILP systems learn progarms in logic programming languages like Prolog. And that is why neither is used in industry.
That is to say, both approaches work just fine - but they're not going to be adopted anytime soon (if I may be a bit of a pessimist) because most programmers lack the background to understand them and they can't be replaced by a large dataset.
A quick introduction to Inductive Programming is on the wikipedia articles:
https://en.wikipedia.org/wiki/Inductive_programming
I suggest to follow the links to the article's sources and to search for IFP and ILP systems separately. Two prominent representatives are Magic Haskeller (IFP) and Aleph (ILP):
http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.ht...
https://www.cs.ox.ac.uk/activities/programinduction/Aleph/al...
More can be found on the inductive-programming.org website:
https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.590...
...and we call that specification a computer program.
Just imagine a world when we have these programming languages to help us encode the specifications for our software. Wild! :)
r such that r * r = x
print "Hello, World!"
fn (*) :: Num -> Num -> Num
fn (a * b) = [machine code goes here]
un (_ * d) n = n/d
un (d * _) n = n/d
un (_ * _) n = sqrt(n)
Also "anyway" a specification is always incomplete. It's part of the programmers' job to fill the gaps with something sensible, and when they have no idea what to do, to point out that some corner case was overlooked.
This is where programmers sometimes start to feel like Lieutenant Columbo: at first everyone is nice, but people become more and more irritated as the pesky cop asks more and more embarrassing questions.
You just summed up about 20% of my job
I suspect that "code" will just keep on getting higher and higher level.
This means that humans will be able to express themselves and have an outlet to automate this.
Maybe the real question will be at what point will people say the specification "is not code".
and what will it be? English? Mathematical notation? doxygen? A notebook? Latin?
So then what do we actually mean by "no-code" these days? I think "no-code", today, has the unspoken implication of "graphical". Okay, so why are "graphical coding" systems (languages?) mostly unsuccessful? There are some clear exceptions like Unreal Engine's Blueprints and certain WYSIWYG web editors like Squarespace, but the great majority of programming is still done in what comes down to, at the end of the day, text files. There may be more and more elaborate editors built atop these text files, but the "bones" of the code is always available, and never too far out of reach.
My pet theory is that this last bit is the differentiator. In a totally graphical programming environment, the programmer never has to be exposed to the underlying format directly. This perhaps encourages proprietary stacks, where the GUI is all that's known and the substance of the "code" itself may never even be made available to those who seek it out.
Maybe this arrangement keeps these "languages" siloed, and therefore keeps them from gaining real traction. It's hard for a thriving ecosystem to evolve around a closed format. Competing tools, editors, compilers, open transfer via regular files, translation, etc are all stifled. You end up totally dependent on one company for all of your needs. For some projects the value-proposition still works out; for most it doesn't.
If so, here's my proposal: instead of focusing on all-in-one no-code environments, focus on creating graphical tooling for existing languages. Or even, creating new (text-based!) programming languages that are designed from the get-go with advanced (graphical?) tooling in mind, while still having that real, open, core source-of-truth underneath it.
We've seen echoes of this already: Rust's features would make it nearly unusable without its (excellent) user-friendly tooling. Design apps like Sketch can output React source code. Pure-functional languages like Clojure really thrive with an editor that has inline-eval. I think if "no-code" is ever going to catch on for real, it needs to be less afraid of code.
On the other hand: is the value-add really the graphical interface, or is it the "height" of the language?
In the latter case, maybe it's more important that we explore even-higher-level languages, and set aside the graphical part as a distraction. Or, maybe we combine the two goals: create higher-level-languages that also lend themselves to graphical UIs, but are still grounded in formalized text underneath.
Every time we go to some other way of describing a document we lose all that text editing infrastructure, which is such a huge setback that no alternate solution has yet hit a widespread critical mass, only specific niches in specific domains.
Which doesn't make text good, it makes it worse-is-better!
As I see it, the probable way forward would not be in language design, but in formats and editors. Breaking through the dependency will be a slow process.
People on HN seem to think programming languages should be designed for a text editor as the primary way of editing, and I think that's a mistake that holds programming culture back (and is why we see these "graphical" languages go too far in the other direction, because the only way to get people to take a proper language editor seriously is to make a language that's impossible to edit in a text editor). Having a canonical plain text representation is important. Having good diff/merge is important. Editor customizability is important. But if you embrace the IDE and build an IDE-first language, without abandoning those parts, you can get a much better editing experience.
These kinds of full-featured IDEs tend to lead to knowledge gaps, in my experience. I'm not really a Java programmer, but I've helped more than one Java developer (usually junior ones, to be fair) with build issues. This is because when I use Java, I write it using vim and either `javac`and a Makefile, or else the command line interface of a Java build tool (ant, maven, gradle, etc). That has given me a good understanding of the Java build process, that I've found many users of Eclipse or IntelliJ do not have.
As such, I think your proposal may have legs, because it could allow less technical users access to the programming environment, while retaining a text-based interface for more expert users.
Where visual tools help is in UI building and layouts. That's exactly what I built Slashdiv for: create a UI and output React code.
Also, this must be where “patching” code came from. Earlier in my career, I never understood the reference when they said they released a new patch.
Macromedia Dreamweaver was the big inflection point because the results could be deployed on the web, for anyone to see, regardless of what box they were running.
The problem I have is that it devalues the worth of actual programmers by making everyone think what we do is easy. It isn't. I see this all the time with do-gooder charities on TV "We're teaching kids to code, and next week they'll all be billionaires!" The present themselves as if a week in a makeshift classroom is all it takes to compile and deploy a Swift app.
I've thought about this since the early part of this year when a middle manager in my company's Communications department dismissively told me that she could do my job because, "I know code." What does that even mean?
It's a signal to look for a better position somewhere else.
Sounds like you work at a company that considers tech to be "the easy part" or a cost center...
Frustrating. And I know how to read and write, but it doesn’t mean I could write a decent novel.
What a lot of people don’t understand about software development is that for any non-trivial project, “coding” is the easy part, the real challenge is in the managing of complexity.
Sure, that's not true. But they will gain a better understanding of how to organize and process information. This understanding will help them even if they don't end up in a software engineering career.
Even if it were, that'd still be a far cry from becoming a billionaire from nil in a week.
Yes, and: you understate the downside.
While No Code (nee Visual Programming, CASE Tools, whatever) may handle 90% of the use cases, the remaining 10% become dramatically harder. Because now you're fighting the framework. Which is an angry 800lb gorilla sitting between you and your work.
Faced with the same challenge, I went in the opposite direction.
Typical strategy of BizTalk, Talend, SeeBeyond, many many others is some kind of patch cord flow chart style programming, with Access VBA style event hooks for script extensions.
I created a stupid simple framework and API optimized for our domain (medical records). Think serverless computing and awesome DOMs for HL7 and adjacent data formats.
Onboarding for our SeeBeyond-based projects was 3 to 6 months. Using my stack was 1 to 2 weeks. (One of the weeks was teaching healthcare domain experts some Java, Eclipse IDE, and version control.)
Further, in my experience, none of these No Code solutions have useful exception handling, logging, fault/error recovery, and other misc devops type stuff. So are an absolute nightmare to support in production.
That is a great point. Whenever I've tried a no-code solution I end up dropping it and going back to code. Some insurmountable roadblock appears that if I had started with code I won't be in this mess.
I've also made the mistake of recommending no-code solutions to my business - trying to reach for the golden ring of self-sufficiency. Seems great at first and then you end up trying to "debug" a no-code framework that you have little of no insight into.
Unless carefully planned out to be modular, you end up with a giant pile of technical debt that is
(a) pretty opaque in its error messages
(b) has poor error handling systems
(c) is brittle in its ability to handle changing file formats or business needs
(d) can only be tested end-to-end, with no space for small unit tests to act as guide rails
(e) makes it very easy to hide business logic all throughout the ETL process
Upside to this tool: It seems to be handling a lot of simple parallelization speedups behind the scenes for you, and catches most type-conversion errors.
Which, inevitably, starts to include things like macros, include files, looping constructs and eventually bits of perl or TCL.
Code is data, but the converse of that is that a sufficiently complex configuration file is just a piece of executable code.
I'd stay as far away from all of these tools as possible.
All I can think of is how Windows used to be administered almost entirely through the GUI but eventually PowerShell was invented and its popularity grows year over year. How is that even possible when the "no-code" way to administer Windows must clearly be better and more accessible and user friendly and coding is old fashioned and borderline obsolete? Every company with their heads on straight would fire anybody who uses PowerShell and replace all their admins with unskilled high school graduates. There is not enough room in town for both no-code and code solutions, so I expect Microsoft to remove PowerShell in it's next update.
if you stop there though, you're missing out on the business opportunity. you can dunk on things on HN all you want but if these businesses are right and the demand for software has massively outstripped the availability of engineers then you're gonna make money in no code tools.
If it were easier to use a visual interface than code, then devs would figure it out and we'd all start doing it.
The "no code" revolution is probably more accurately the Microsoft Access replacement for our generation. Sleeker, cooler, more professional. But like Access, you have to replace it with real software when it starts getting complex.
1. Hide parts of the program (e.g. hidden cells on a spreadsheet; attributes of nodes in a visual programming environment)
2. Switch to text for the higher information density.
I think the burden of #1 quickly surpasses the burden of learning to work with #2.
Epigram 93, Alan Perlis
Once it grows to any reasonable level of complexity it becomes more of a hindrance than a help.
Access was actually a great tool for allowing semi-technical people make quick apps, but almost every shop I've been in has needed to convert Access to grown-up software.
But the real fix is to simplify web stacks for smaller projects. We don't need Rube Goldberg routing engines/URL-prettifiers, ORM organics, Bootcrap organics (UI), Async/Await bloat, etc. We want our app track some local e-paper-work, not be Netflix. A Learjet will do, don't gear it for Jumbo Jets. Time for a KISS web stack to become a de-facto standard.
> But the real fix is to simplify web stacks for smaller projects
We've already done that. RoR, Django, ASP.NET MVC, etc. etc. It's super easy to get something working out of the box. But at some point, you still need to understand what your database is doing and optimize for it. Some level of complexity is inescapable.
And you could probably argue that as back-end has gotten simpler, complexity has just expanded to fill the void. Now we expect fancy JS interfaces on top of them, too. And phone apps.
I have no doubt all of the things I mentioned will get simpler, but I can't foresee anything that will make software devs irrelevant in on the immediate horizon. I suppose at some point BAs/PMs (people who gather requirements and draw wireframes) will be able to write code, and we'll start to compete more with skilled BAs. But that's still not the end of the entire profession. Gathering requirements is still hard.
For instance, I've done some work with node-based editors like Node Red and Max MXP, and while they are nice for simple cases, invariably they reach a tipping point where you end up with a giant graph which is far less navigable and comprehensible than a set of source files.
There's no escaping complexity.
Yes. Also CASE tools, those with a code generation feature.
https://en.m.wikipedia.org/wiki/Computer-aided_software_engi...
Pun unintended :)
However, I do think that you still need a dev mindset, with dev experience, to use it well. Principles like DRY, loose coupling, code organisation, consistent and informative naming, concise logic, etc adhere just as well. Those hard to transfer skills you build up over time. Although a junior may get things working very quickly, keeping things maintainable and extendable is just as hard, or even harder.
So like you said; I believe you still need to be a dev to deliver with these systems; 'end user programming' is not close outside Excel. People who know nothing about programming will generally make complete monsters with these systems, even after training (I saw it a lot with Outsystems when I click open a business flow).
Real enduser development revolutions we won't see this low-code wave, maybe the next somewhere around 2030?
Right. And that probably applies to many, if not all frameworks, by virtue (vice?) of their design. I don't know Mendix, but I've worked on programming frameworks like Rails, Flask and others, including some in-house company proprietary ones. You sometimes have to work around their limitations with custom code, awkwardly, even Rube Goldberg style at times.
And there can be instances or even categories of apps that can't be done using the framework at all.
The framework giveth and the framework taketh away.
This is true for all of us - it's just that the level of abstraction each of us is comfortable with is different.
Not sure why people don't understand the value of raising the level of abstraction for more people to participate in software creation. It seems like an obviously valuable and worthwhile objective, even if it does look different to the way I build software.
When I use a "no-code" product it's usually not more than a few months before I start using it's API and adding small bits of code here and there to do things not natively supported by the product. You would have to have a puritanical fervor and a lack of sense to want to eliminate all semblance of code from a product made out of code.
It's almost as if after seeing you could add images to Microsoft word documents you saw an article coming out about how Written English was going to be replaced by Hieroglyphics and soon we could communicate with nothing but Emoji and talking about how the next generation won't be literate. The sentiment in this thread is mostly a reaction to irritating and implausible clickbait.
a standard newspaper article then ? https://cheezburger.com/6860549/14-hysterical-headlines-that...
actually I'm pretty sure that there were a ton of articles in the vein of what you're saying circa 2000 when emojis rised in popularity
At maximum that a gui represents a bad abstraction that can't be used by non coders effectively to produce code save for when actual code exists that sufficiently specifies the program. For example a gui builder can help you build your web based store but is insufficient to build the tool that builds the store.
There's some value in having abstractions being more visible. I don't think that strictly speaking something like Node-Red qualifies as 'no code'. But it made me understand that, given that so much of development nowadays consists of 'gluing' code together, there's potential for such tools. Even if some of the boxes happen to allow you to write code.
At some point, all you care about is inputs and outputs. We are missing a better way to do these things.
That said, maybe this time is (a bit) different. Machine learning is markedly more mature today and could take no-code farther than it has in the past.
However, I can personally vouch for 2 champions in no code.
The big behemoth is Salesforce.com. The incipient champion is Bubble.io.
Cloud infrastructure ,API consumption and mobile usage are the paradigm shifting variables that were not present 10y ago.
The fact that cloud is getting (traditional) corporate green lights and that every employee is using software to do regular 9-5 work indicates that software creation is demanded at exponential scale.
> The end result is always back to code.
Sure. The same way the end result is always back to electrons flowing around. The abstraction layer that no code provides NOT TO YOU but to Michel the accountant is very relevant and will (10y from now) produce a new paradigm shift, as Salesforce pioneered the "no software" [1] SaaS 20y ago.
And the paradigm shift is not "0 code". It's "0 code to get thing rolling; and developing programming skills visually to later on have a more productive talk with coders"
[1] https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F...
My experience with Salesforce.com is that it's only a no-code champion if your needs are so simple that you might as well not be using Salesforce.com - i.e., a simple CRM with a few plugins. The real strength of Salesforce.com is that you can use code to customize it and get the real utility you're paying for out of it.
It's "no software" in the sense that all SaaS systems are "no software". Realistically, Salesforce.com is very much enterprise software of the sort that requires real customization in the form of real code to implement the important business requirements.
My experience has been different. When I worked for a travel company, it joined Salesforce. Shortly thereafter it had to hire a full-time Apex programmer to make Salesforce do all the things the Salesforce salespeople promised it would do without a programmer.
There's definitely a place for a la carte pricing for server-based software ("serverless" which of course includes servers, you silly person) and there's a place for very high-level code in domain-specific languages to solve immediate business problems ("no code" which of course includes writing code, you silly person) so just learn the shibboleth and try to avoid sounding silly.
/s