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.
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.
http://web.stanford.edu/class/cs99r/readings/parnas1.pdf