The Future of Software Is No Code | Hacker News Reader

The Future of Software Is No Code

inc.com

119 pointsbatemanSMA182 comments

They've been trying the "let end users code in an impoverished pseudo programming language" for a long time and at best it only ever takes over small niche. And they still need real programming languages and software engineers to help them overcome their problems when they try to scale, extend, or encounter a problem that's too complicated.

There are two things here. The first is sometimes programming languages are harder than they have to be and the other is that sometimes problems are hard.

1) Yeah, C++ is really complicated and you could probably replace it with language that was less complicated, but if you're trying to do something in the C++ problem space then you're still going to require a lot of difficult thought with respect to your problem, your solution, and the machine it's implemented on. You're not going to get away from writing driver code with a no code solution.

2) If you want to do arbitrary things, then eventually you'll need something that's turing complete (or really close to it if you're going to talk about things like Idris or Agda). A no code solution might be able to handle things as long as you follow a very carefully constructed path, but eventually your users are going to have reasonable requests that no code solutions won't be able to solve because if they could they would just be programming languages unto themselves.

If you're telling me that eventually CRUD apps will be mostly automated away, then I believe you. If you're telling me that eventually software engineers won't be needed then I'll see you in line at the unemployment office because the last two jobs to be made obsolete are software engineers and youtube personalities (and last I checked they're working on automating youtube personalities).

If you're telling me that eventually software engineers won't be needed then I'll see you in line at the unemployment office because the last two jobs to be made obsolete are software engineers and youtube personalities

lol, love that! I'm not afraid, if it is to be, so be it, I'll just work on how to grow my own twinkies from a personal garden.

I agree with you but what I would add is that what programmers miss is that there is a continuum between how much the underlying rules of the system can be changed and knowing when to expose these is actually your job as a programmer.

For example, users can always change a URL. This has allowed companies like Twitter to give a little URL-UI (UUI) to help power users while still letting normal people type in the search field. Way on the other end of the spectrum is a tool like Microsoft Excel where there is practically no limit to what a pro can do. Somewhere in the middle would be a sort of table-based design where admins could add simple rules (like layered tax rates, minimum requirements, or when a price change goes live) without needing to do a code deploy.

> If you're telling me that eventually CRUD apps will be mostly automated away, then I believe you.

Don't. Read "worse is better" again. In the 90s CRUD apps were a solved problem. Then in the 2000-2005 or so they became graphical (access, foxpro, dbase, paradox, filemaker, and yes visual basic and delphi ...) and it was trivial to get CRUD apps done.

People who wouldn't know code from Welsh English made databases for libraries, of their CD/DVD collections/... just for fun even.

Today, that doesn't happen anymore. And the web frameworks we currently use for that by and large don't work on mobile and even those are losing in the marketplace for reasons I can't understand, but there is a new javascript framework we just GOT to use. CRUD apps these days ... need a web interface, an android one, an ios one, and more. Minimum number of programming languages required: Javascript, Java/Kotlin, ObjC/Swift, and a backend language (can't use Java for that ... that would make ... euhm ... that would make sense ? And yes, you could use even Javascript, but ... so let's use Python ... or Go).

And let's just not mention that such absolutely basic things as a data table that were lowest-common-denominator are now exceptional. Sorting by every column ? Rarely happens. Having all data in a single listbox with search, filter, and rapid scrolling ? Unheard of (because very impractical on the web).

So no worries about programmer jobs. Ever simpler things will require ever more programmers. Worry about enjoying programming.

What I wouldn't do for a tool like powerbuilder today...

That said, html + css is the wrong tool for applications and we keep jamming that square peg through the round hole.

> In the 90s CRUD apps were a solved problem. Then in the 2000-2005 or so they became graphical (access, foxpro, dbase, paradox, filemaker, and yes visual basic and delphi ...) and it was trivial to get CRUD apps done.

Because CRUD apps were for one platform, running purely locally, not dealing with disconnected clients, concurrent clients modifying shared data, unreliable database connections, clients with arbitrary screen dimensions, resolutions and orientations, or in arbitrary human languages. I think you underestimate the scope of modern CRUD applications.

Sure it's complex. But WordPress works fine. Why can't a crud tool ?

A lot of that is self-inflicted complexity and following latest business trends (read: mostly hype). Things like opting for distributed cluster and map-reduce where a couple of unix commands piped together, running on a mid-tier laptop would do. Things like going with the latest and greatest web framework, that incidentally pulls in 5-layers deep stack and thousands of dependencies into your workflow.

Also related is typical business optimization - which usually means externalizing costs to users. Like, "CRUD apps were for one platform" - the cost of doing them for multiple platforms is at worst linear with the number of platforms, and most of that cost can be moved to a constant factor if you design your architecture correctly. It's a big deal, but it's not always that big of a deal. And contemporary alternatives result in applications sorta-working on multiple platforms at the price of one, but having half (or less) functionality.

The framework is intended as complexity management. Instead of picking each of 20 components each of which has 7 choices with different tradeoffs and figuring out which subset of choices delivers an acceptable complete picture just read how to use the components we have picked for you in a suggested fashion.

The result may be complicated under the hood but may be easier to operate as well.

Problem is, this often backfires - you end up using 5% of the power of the framework, but spending 95% of the dev time fighting it to achieve what you really want.

In my experience this is a sign that you've picked a wildly unsuitable framework, rather than that the very concept of a framework is wrong.

In my experience, a wildly suitable framework for one person will almost certainly be wildly unsuitable for someone else, especially if that framework is especially opinionated. Appealing to every use case would mean a proliferation of frameworks with very subtle differences, leaving a prospective user entirely confused about which one to use.

That's not to say that there's no place for frameworks, but it is to say that there's value to being able to piece together the equivalent functionality (or at least the critical subset thereof) from unopinionated "do one thing and do it well" components with relative ease and minimal pain.

I think the "relative ease and minimal pain" option is usually picking a framework and working with it as it's intended to be used.

Unfortunately, "picking a framework" for which "working with it as it's intended to be used" actually matches with the user's intentions tends to be the excruciatingly difficult part. Best-case: the user happens to find the perfect framework for one's use-case. Common-case: the user gets by on hacking the framework to do one's bidding, regardless of how it's intended to be used, because the user can't find one that actually satisfies the user's requirements.

See also: the proliferation of Excel spreadsheets driving business logic pretty much everywhere outside of Silicon Valley (and in some cases even within).

I don't see the relationship there... end users choose Excel because it's the only thing that's available to them. For a professional programmer you should not only have better judgment but also have some familiarity with the frameworks available for what you want to do.

I worked as a system administrator around when they were EOLing Windows XP and I think you are really underestimating the benefits of Web apps here.

In the late 1990s IBM Lotus Notes / Domino ran on multiple platforms and worked fine for CRUD applications with disconnected clients, concurrent clients modifying shared data, unreliable database connections, clients with arbitrary screen dimensions, and multiple human languages. The underlying architecture was a bit ugly but it worked.

As an industry we have absolutely regressed in many ways. Web application make distribution easy but almost everything else is worse.

For all the hate it got, the Notes/Domino platform did some things really well.

I just love the dichotomy on HN where you get one article: “The Future of Software Is No Code” and another “Why it took a long time to build the tiny link preview on Wikipedia,” these two are seemingly orthogonal in my mind.

I think orthogonal (at least from its usage in math-related contexts) means the two don't have anything to do with each other.

Nah, that would be skew. Orthogonal crosses but goes in a different direction.

Except you can have orthogonal vectors that don't intersect.

Orthogonal is frequently used to mean two (or more) things are independent of one another. I have never heard skew used in that way.

Yes, the poster above has assumed the meaning of 'orthogonal' from its etymology, but the use he criticises comes from statistics (https://stats.stackexchange.com/questions/12128/what-does-or...)

I believe in the, quite common, context just used it's meant as non-parallel. Or the two ideas don't track at all.

Yeah, but they were saying in math related contexts, in which orthogonal is almost equivalent to perpendicular.

I believe even in the context of mathematics orthogonal means independence. I.e., one can move along x and y axis without having y or x value being changed. However if you move along any line that's not parallel to x or y axis then both x and y value change simultaneously. That's how I interpret orthogonality in the context of math anyway.

>However if you move along any line that's not parallel to x or y axis then both x and y value change simultaneously.

A third orthogonal axis is neither parallel to x and y, nor do x and y vary as you move along it.

Replace parallel with linearly indepent, and you are spot on.

No need to replace anything; the implicit assumption is a 2D space.

Then you can only talk about two concepts. I would like to be able to say, intelligence, morality, and obesity are mutually orthogonal.

If your model is 2D, then you are requiring a relationship between at least two of them.

The example was in 2D. The reader is able to generalize from there, we hope, no? :)

As long as you don't rely on concepts that don't generalize to higher dimensions. To the extent that you use concepts that don't generalize in your example, you are using a poor example.

That's the idea, and these ideas do intersect. Rate your belief in them on a scale of 0..1. if your rating was (0,0) you are at the intersection.

The real reason it took so long was buried in the comments: the community was unwilling to accept a sub-par solution at all.

And if your requirements are very steep, you're probably not going to get away from code, but if your goal is to build something quickly and make a few compromises, then maybe No-Code approaches are for you.

Not orthoganal, I'd say. They're diametrically opposed. I want the no-code thing to work. I just don't think it's going to.

I have been hopeful for this for a long time - it's not so much that I expect it to stop the need for a developer, but rather that it will allow a developer and domain expert to work together more efficiently.

The ideal case, in my mind, is a case where apps can scale. A user needs a simple tool, so they build it in a UX-friendly way, which has limitations but can reach some basic data sources and can do some basic CRUD.

Then, the user starts reaching a point where they need to scale. Then, something like VBA can be written by the user or by some developer, and tied into the UX. Indices can be added to the database, and to a DBA it looks like any other CRUD app. Views and materialized views can be used to add information from other parts of the database.

If there's one difficult part, the system can call a service that has access to the database and can do computing more directly, communicating through a standardized JSON system. (Perhaps something like JSON API.)

Then, the tool starts getting popular, and is straining at the seams. Instead of having to create an entirely new project, the project can be exported using a translation layer to a pure programming language, with tests built automatically. Developers can then take it in any direction necessary.

The biggest problem is that it's hard to progressively scale small apps - every time a small tool created outside IT gets created, it expands until it starts being dangerous - excel anyone? - and then IT is brought in to build a full scale system that solves all the problems. IT then gets angry at the users for creating a useful tool instead of getting dragged out into the funding-design-create-test-bugfix process.

And that's why the No Code sounds so appealing. It's a structural PITA to scratch your own itch.

We have had this in the DSP field since the 1990s with pure data, and before that the closed source Max, now a part of Ableton Live 10. Faust is another example of a graphical coding tool for DSP, in the case of Faust you can export C++ that you then include in a larger C++ based application.

These kinds of tools are only viable for their narrow problem domains. Code will always rule for general purpose development. At least until AIs are good enough to produce usable results from a problem description.

Electrical Engineering has already trod this path. Before HDLs became good enough for logic synthesis, FPGAs and ASICs were developed with schematics or manually mapping circuits into the target architecture. That process doesn't scale well as you end up wrangling with 2D spatial representations and constantly fiddling with low level details. Now, HDLs are the primary means of developing such hardware and the vertical tools are limited to specific data processing niches where there is some productivity advantage in reusing established design methodologies.

Hmm, yeah I'm similarly skeptical as someone who did his fair share of LabVIEW for a research lab back in the day.

I would regularly get asked to do things in LabVIEW that were (sometimes quite literally) impossible to do without writing some C code. More than a few programs basically became wrappers around C libraries.

That's to say nothing about the unwieldy LabVIEW monstrosities that I'd regularly get asked to take a look at because they were complicated as hell. Massive programs, mostly because of copying and pasting. While you can wrap things up in functions and subroutines and etc., you have to know that you should do that. And I certainly can't blame a research scientist for not knowing that - it's not really their job to.

Fundamental software concepts like DRY don't disappear just because you're using a visual language.

> I would regularly get asked to do things in LabVIEW that were (sometimes quite literally) impossible to do without writing some C code.

Is this because (a) LabVIEW is high level and C is low level, or (b) because LabVIEW can't handle some complex algorithms?

(a) doesn't bother me as using a low-level language for low level tasks is a perfectly reasonable thing to do.

> While you can wrap things up in functions and subroutines and etc., you have to know that you should do that.

If someone uses a programming language for more than scripting (or in a visual language, sketching) they should learn to program. It makes no difference that the language is visual.

> Is this because (a) LabVIEW is high level and C is low level, or (b) because LabVIEW can't handle some complex algorithms?

It's high-level in the sense that you program by choosing a set of components. A very apt analogy might be Excel and VBA: It would be extremely difficult (if not impossible) to accomplish some tasks using Excel, and if you're using Excel as a "programming language" you will find yourself reaching for VBA to do certain arbitrary tasks.

> If someone uses a programming language for more than scripting (or in a visual language, sketching) they should learn to program. It makes no difference that the language is visual.

Sure, but saying people should do x is basically absolving yourself of the problem and throwing your hands up in the air. They don't do x, so it's sometimes our job to figure out why they don't x and how we can encourage people to do x over time.

LabVIEW is very much presented informally as "program without learning how to program" (very similar to the article), so people using it don't feel as though they should have to learn basic programming fundamentals.

Thanks for your reply. So, in practice (b). I had been led to believe the underlying language G was at least in theory general purpose though its libraries are specific to instrument control and similar applications.

I used LabVIEW for a few years. In my view, LabVIEW is as low level as you want it to be. It has some very low level operators. And it can handle algorithms as complex as you want them to be.

One of the first hurdles faced by all beginning programmers is "what to do when a program gets too big to fit on one screen," or to understand in one sitting, etc. We all know at least some basic solutions to this problem: Variable naming, subroutines, etc. When LabVIEW programs grow beyond a single screen, which happens quickly, it becomes very cumbersome to navigate through multiple windows and their different viewing modes. Since a program can have multiple entry points, it's hard to figure out what a program "does" in a top down fashion.

Second, there's the reason why so many of us went back to CLI and text editors after experiencing the wonders of the GUI. I think that doing complex work with GUI based tools becomes physically laborious to the point of being debilitating. I came away from my LabVIEW sessions with splitting eyestrain headaches and wrist fatigue.

The physical work involved in laying out code also discourages refactoring.

Maybe, oh maybe, there's something right about text based programming languages.

Or maybe LabVIEW needs a better editor/IDE. I very quickly gave up with Franz Lisp on a VAX running Berkeley Unix not because of any deficiency in the language but because I had to use vi to edit it.

There have been only two languages (Prograph and Max) with any similarity to LabVIEW which have gained significant numbers of users, so the space of visual dataflow languages hasn't been explored enough to write them all off.

LabVIEW was designed in the 1980s when nothing similar to base it on existed, and various design choices were committed to which didn't work out well. In the following decades, many advances in language design took place or were widely adopted and would be difficult to retrofit to an language of that era.

I've only read about LabVIEW, but I have a fair amount of experience designing another visual dataflow language, Full Metal Jacket (http://web.onetel.com/~hibou/fmj/FMJ.html).

In Full Metal Jacket's IDE, opening a function definition is done by right-clicking on its vertex (rectangle); connecting an output of one vertex to an input of a second vertex by dragging the mouse cursor in its general direction and releasing or, if the the second vertex is absent, right clicking on the output and dragging the vertex from another window. Hovering over a vertex displays its documentation string, hovering over inputs or outputs displays their types.

I adopted some ideas from functional programming languages - simple syntax from Lisp along with Gabriel's MIT approach, strong static typing with type inference from Haskell and ML, tagged data and a few other ideas from experimental dataflow hardware (I knew the people involved in this both at Cumbernauld and Manchester); and some vocabulary from graph theory. It was obvious to me very early on that there was no way anyone could honestly market dataflow languages at people who don't consider themselves programmers. Not only do you still need to design algorithms, you have to think in a completely new way.

Very interesting. I wonder if this could find a niche on microcontrollers or FPGA's.

Yes. More generally, good programmers aren't crucial because they know how to code, they're crucial because they know how to construct good programs.

Syntax is often too complicated, I agree. But to me, software development is not about learning syntax but about handling and understanding complexity. Good languages support handling complexity and I really don't see a future where complex software can be built without something supporting you in handling complex interactions between things.

But domain experts can handle complexity just fine, especially given right tools to help with domain driven design/DSL , abstracting, versioning, parameterizing, information hiding, reuse, modularity, and getting help from software engineers when needed).

And since there are easy to use examples of each of those in various categories, it's not impossible to imagine some tool will tie all of them together.

I think there's a third issue you didn't mention: Ecosystem/framework complexity.

Writing a device driver in C is complex, sure, but pretty much all that complexity comes from the problem domain. C++ adds a little more incidental complexity, but if you use it to write a device driver, you're still mostly fighting "how my computer talks to hardware" - and at least that's the correct fight to be having.

But if you're writing a CRUD app for the web, the incidental complexity is off the charts. Five different languages (HTML/JS/CSS/{Ruby|Python|Whatever}/SQL), three or more frameworks (Bootstrap/React/Redux/Django/SQLAlchemy)...and you haven't even deployed yet.

There should be a middle position between "impoverished pseudo programming language" and "here's your five-layer web stack, have fun". If your app is basically three "if" statements and a "for" loop with some UI on top, I agree that you should write those statements in a real programming language. But you shouldn't need three layers of framework on top, just to put them in front of a user!

I think this is what everyone is talking about when they bring up VB and Delphi in this thread. I don't think that "Delphi for the web" is an impossible goal - and I've put my money where my mouth is, by building a sane development platform for the web - https://anvil.works. You do everything in one language (Python), with proper tooling support (hello, autocomplete!), and skip the BS.

(On the other hand, perhaps this is what you meant by "CRUD apps will mostly be automated away". If so, it's only in the sense that my time is being "automated away" when I use a GCed language rather than malloc.)

Sounds like.......... a framework

which hides away complicated things like sql behind an more accessible api...

> complicated things like sql

Heh, SQL (formerly SEQUEL) is the 'structured English query language', designed to be simple enough for anyone who knows a bit of English - not unlike Cobol.

> SQL (formerly SEQUEL)

Off-topic, but today I learned I've been pronouncing it as originally intended all this time.

Yes sure, but when you start one language having to learn another just to store and retrieve data is a lot to ask.

And of course once you progress with your data needs you get into more complex aspects of the language where the simplicity of the language isn't as important as the concepts and ideas it does express.

AFAIK the idea was that SQL is so close to plain English that any accountant could simply use it to generate reports or enter data. It's really an old fallacy that using plain language would make complexity go away.

In other words: https://xkcd.com/927/ (XKCD: Standards)

I disagree. I'd say that attempts to let end users do their work without 'programming' have succeeded marvelously. We've handled the 50% case, and then the remaining 50%, and repeated this process several times.

When I was a kid, I had to type a valid line of source code to load and launch an application (often two separate lines). Today I can literally touch a picture of it with my finger to do the same thing.

There may always be tasks for which we need someone to write a process description in a Turing-complete language, but even as a programmer, almost all of the non-programming tasks I do today would have required programming 30 years ago.

> There may always be tasks for which we need someone to write a process description in a Turing-complete language, but even as a programmer, almost all of the non-programming tasks I do today would have required programming 30 years ago.

And the end result of this is what? More or less code gets written? Is there a need for more or less programmers over time? What's the trend, do you think?

Maybe the computing pie gets bigger faster than the software needs can be turned into non-programming tasks.

That's a great question, and I'm going to sidestep it a bit by saying I think the limiting factor isn't technology.

95% of the projects I've worked on have been some fairly simple permutation of ETLs, CMSs, and ops -- all of which are sufficiently constrained problem spaces that we've got good systems for them which work well without the need for Turing-complete programming languages.

But as long as we're constrained by legacy codebases, overly complex third-party APIs, and the need to maintain business models, we're not going to be able to make things as simple as we know they should be. It's not just services: I've got 100 legacy file formats on my disk, and they mostly are completely different and require different tools for no good reason.

I've wasted many months (years?) of my life figuring out how to plug the API from service X into the API for service Y and put the results on a simple webpage, with some CSS that a designer gave me. That's not the sort of thing that ought to require a Turing-complete programming language. It's almost all accidental complexity.

Someday we'll sort this all out, and then maybe we'll go on to discover some other unexplored area where we need lots of (Turing) programmers, or maybe we won't, but that's beyond the inflection point. Our next 50% barrier isn't technical, and as long as we've got artificial socioeconomic barriers in the way, I can't guess what's after that.

> Maybe the computing pie gets bigger faster than the software needs can be turned into non-programming tasks.

Most "software" needs these days are business related. Legions of engineers are just adding minute variations to the same CRUD frameworks to make slightly different products. I think the kind of programming that goes into making a CRUD startup and the kind of programming that went into making a device driver in the '80s is very, very different.

I can imagine this being the future, but it's quite a long way off. I was thinking about this as I was doing some work in Python earlier today - back when I was working in C, variable-length lists and hash maps were so inconvenient that I often just convinced myself that fixed-length lists and sequential searches were "good enough" for the case at hand (and, often, I was right). With Python, of course, I don't even think twice about using relatively higher-level concepts (in fact, I don't have a choice), so even as a professional programmer, I've popped one meta-level up in the abstraction stack. That said - there are a LOT more meta-levels that tools need to pop up before somebody who doesn't even understand what a linked list is is going to be able to produce software that serves a useful purpose. Even in that future world, there will be a need for "low-level" folks who can at least think in assembler when necessary - but I imagine that role will be more like that of a surgeon in meatspace.

> With Python, of course, I don't even think twice about using relatively higher-level concepts (in fact, I don't have a choice), so even as a professional programmer, I've popped one meta-level up in the abstraction stack

But these existed in programming languages before Python's inception, at least back to Lisp in the 60s. And newer languages like Go eschew some of the higher level flexibility of a Python on purpose.

Also, despite the widespread use of languages like Python, JS and Ruby, C/C++ and Java remain just as widely used as ever.

> there are a LOT more meta-levels that tools need to pop up before somebody who doesn't even understand what a linked list is is going to be able to produce software that serves a useful purpose

I can think of lots of useful web applications today built by people with no knowledge of linked lists (or at least, they didn't need any such knowledge for those applications). The entire CMS market seems to exist to enable this.

> They've been trying the "let end users code in an impoverished pseudo programming language" for a long time and at best it only ever takes over small niche.

I bet spreadsheets are the most common form of programming on the planet. So at best it takes over a very large niche, becomes entirely mainstream and we forget it's programming at all.

(Of course spreadsheets can use 'real' PLs, but most people only use the basic formulas and ranges.)

from my POV spreadsheets are code (there's a formula language after all), just laid out differently and with a very different IDE.

That's my point. And while niche, the niche is enormous and important. Spreadsheets are a huge success in domain-specific programming for everyone.

And huge success in functional programming.

> They've been trying the "let end users code in an impoverished pseudo programming language" for a long time and at best it only ever takes over small niche.

Exactly. Creating a "simpler programming" for business users, in the end, only creates a 2nd language the IT staff has to support. Even getting business users updating something as simple as a quality CMS is an uphill slog.

Another often unacknowledged reality about that - I suffered for three years in the "Salesforce" environment which bills itself as the be-all end-all "no more programmers" solution. In reality, it's clunky and limited, and even when non-programmers are able to get something that approximates what they want, it ends up being slower than molasses. That's when they call in a programmer to figure out what went wrong and it's usually something like re-running a complex DB query a thousand times to satisfy a simple request. And you can hardly blame the business users - they have no visibility into what they're doing, so it's completely understandable that they come up with an inefficient mess. If user-created software is ever going to be feasible, the back-end is not only going to have to translate their drag-and-drops into usable code, but it's also going to have to intelligently optimize: that is, infer what their goal is and find the most efficient way to achieve that goal. That alone should tell you how far we are away from a programmer-less future.

Aren't query planners already intelligently optimizing?

A lot of these optimizations have already been solved.

I feel like CRUD web apps are pretty much automated already. You load in React or Vue or whatever, then you just write CSS and HTML in a copy paste style where you're copying from your brain. In fact! The automation has gone so far that people even specialize in using these new automation tools.

Typically they're referred to as designers and web engineers.

Dumb advertisement article...

Round and round we go. Textual code looks like the barrier when you start learning, but it's a boon when you've gotten past it. The big barriers to quality software are not typing or syntax, they're just the most visible from the outside.

Despite the goal being to "let anyone program", these tools rarely end up as more than toys. Why is that?

It's because learning to program is not a matter of learning syntax. If that was the barrier we'd have just put more effort into NLP and been done with it.

But traditional spoken/written languages are inadequate for the precision needed in programming, so we use more precise alternatives. The language is a tool that makes it easier to program, despite looking more intimidating from the outside.

That said, when you limit your domain you can make quality "codeless" tools. Shader Blueprints in Unreal come to mind as a good example. But a lot of the value they provide is in seeing the previews at every step because it's a very visual thing that you're making. And if you're hitting performance barriers, you'll probably need to rewrite it in text anyway.

Just because programming languages look scary from the outside does not mean that removing them will make programming easier. Most of the time it will make programming harder.

Precisely. As I frequently like to remind those around me (because I'm a total drag), "Coding isn't easy, but it's also not the hard part of programming".

I think this is the important distinction. These "codeless" tools really just shift the inherent complexities of software development instead of getting rid of them. Anecdotally, I had much harder time learning how to read/understand LabVIEW graphical "code" than I did learning C.

I used Unreal's Shader Blueprints as a positive example, but the more procedural Blueprints used in gameplay boggle my mind. I find them harder to read and much harder to write, and that's when they're well formatted.

Another point that I forgot to bring up is that graphical tools don't always let you setup functions, and when they do the added indirection usually makes them even more confusing. It makes it difficult to break out repeated logic and confusing to follow the code after you do break it out.

LabVIEW isn't a "codeless" tool. It's a programming language. It's very different from C (dataflow instead of imperative) and requires a different way of thinking.

I think they recognize that, which is why they said code in quotes.

It's still related to the topic, as that's one of the first places people go when trying to take the code out of programming.

Even simpler than that, most people simply aren't interested in programming. A lot of programmers seem to have difficulty comprehending this. As you say, there are of course barriers for many, but we can't continue with the premise that everyone could be a coder and would be a coder if X and Y were met.

I argue that programming languages are not complicated. Although most people butcher the English language, it's a far more complicated language than C, which has relatively few keywords and an unambiguous syntax. But programming languages, especially C, are tremendously repetitious and lack nuance because of the fact that they are so simple. Simplistic units in principle are really good at building different complex things, whereas things that are more complicated are usually better at articulating simpler ideas. No wonder nobody programs computers in English! A programming language that tries to meet parity with English, or any spoken language, would be an utter nightmare to deal with.

My point is that someone who has any innate interest in programming can make their way past the layer of intimidation, especially now more than ever with the sheer amount of information that didn't exist when I started coding. I remember when looking at code was intimidating because it didn't match my understanding of what a language was, and it was in the era of "Just F###ing Google It" when nobody on forums would help you, online documentation was terrible, and there was no Stack Overflow. Now, there is really almost nothing holding anyone back besides the will to do so.

There is a limited amount of things that most people are willing to learn. When one is hardly autodidactic, they will choose the path of least resistance and only learn when it is a necessity. When programming to any degree isn't a necessity for someone, they're not going to want to do it. Heck, sites like Wix and Squarespace are insanely easy to use, and I know people who want to make their own site for their business and drag their feet in using site builders because they find it annoying to understand what it even is they're doing when they're dragging around components. They don't want to have to learn, and would rather someone who is interested in building sites do the work for them.

Hence, why there are still programmers.

What you describe certainly has been my experience. Many of the markup languages that were designed to make it possible for "non coders" to write interfaces just turned into another programming language, only clunky and irritating.

For example, tag libraries like the JSTL were designed to split the programming between interface and back end, allowing designers to manage the programming logic in the interface. HTML and markup tags were fine, but in my experience, once you get into loops, conditionals, and so forth, the designers almost always send it back over to the programmers, who now have to learn a new (and generally half assed, in my opinion) set of tags to implement programming logic. As I remember, they pushed this pretty hard (the head first books even devised a mock scenario where a corporate memo banned the use of JSP code in a page). Ruby on Rails went with ruby code and helpers, and I think it was vastly more successful. YMMV of course, but the experience led me to believe that if you're going to program, just use a programming language[1].

As for this article? Well, the sub title is: "It's accelerating how businesses are able to impact their strategy." So, we have a sense of what we're in for if we choose to keep reading.

Beyond that? Actually, I do think that things we used to write code for will be handled differently, and may not require programmers. This is nothing new for the industry. There was a time when a spreadsheet required a computing expert. Same for calculations, servers, publishing an article on what is now a "blog". Blogging engines totally accelerated how writers impacted their strategy.

[1] a lot of people don't quite understand the hype and, yeah, attitude of ruby and rails programmers in the early days. I do think this community went too far with it, but the scenario (a corporate memo banning something) does get at why. The java world had gotten sort of insane, and ultimately was starting to rely on things like memos from above because that was the only way to imagine why anyone would actually write the way the spec said. There really was a massive cheer when someone (DHH in this case) just finally put up a giant screen at a conference saying, literally, "fuck you". Although I think you can achieve with more civility, that kind of bluntness is necessary to beat back the insanity in this field every now and then.

You remind me of the old article about "Soft Coding": https://thedailywtf.com/articles/Soft_Coding

> The reason we find ourselves Soft Coding is because we fear change. Not the normal Fear of Change, but the fear that the code we write will have to be changed as a result of a business rule change.

> It’s a pretty silly fear to have. The whole point of software (hence, the “soft”) is that it can change that it will change. The only way to insulate your software from business rule changes is to build a completely generic program that’s devoid of all business rules yet can implement any rule. Oh, and they’ve already built that tool. It’s called C++. And Java. And C#. And Basic. And, dare I say, COBOL.

> Textual code looks like the barrier when you start learning

The fact that, hundreds of years after Newton, mathematicians still use symbols to convey concepts strengthens your argument here.

Not only that, but writers around the world still use text to express their thoughts. And, 5000 years ago, they started with drawings. But, smart as they are, they realized it sucks, and that for anything beyond simple concepts, text is da best.

I second this. Programmong languages where made to be precise enough for computers to understand and ambigous enough for general computing

Interesting! That's a point of view I've never thought about and it makes sense, thank you!

It's like saying the future of books is no writing.

But what's hard with writing a book is not putting words on a paper. It's organizing thoughts and expressing it in a way that convey what you wish to share.

Same with software.

As a freelancer, I spend a lot of time with my clients speaking with them, watching them work, reading their doc, understanding their culture, doodling on paper.

Because my job is first to extract what they need from them.

They are incapable of doing that. I have yet to meet a client that comes to me with half of the information I need to build their software by themself.

So let's say we figure out a way for people to make software, express the rich and complex though and work flow their task require, yet with a an easy process. Its seems dubious given our past history, but I'll indulge the author.

Now what ?

What would my customer build with that ? They don't even know precisely what they want, let alone what they need.

And then let's say that Jesus descents from the sky and a miracle occur, and their figure it out, and create the product with the unicorn No Code magic tool.

They have no idea how to deal with the changes they are going to need to make. How to adapt to politics. How to make it so that it can evolve. What technical decisions will affect their cost in the future. After all, it's not their job.

The code is not really the hard part of the job.

We keep the code because it fits the problem quite well and make it easy to solve once we have the rest figured out.

Very well put.

"I'll go talk to the stakeholders to find out their requirements... in the meantime, you guys start coding."

http://www.modernanalyst.com/Resources/BusinessAnalystHumor/...

Made me think of this comic by commitstrip [1]

- Some day, we won't even need coders any more. We'll be able to just write the specification and the program will write itself.

- Oh wow, you're right! We'll be able to write a comprehensive and precise spec and bam, we won't need programmers any more.

- Exactly

- And do you know the industry term for a project specification that is comprehensive and precise enough to generate a program?

- Uh... no...

- Code, it's called code.

In the end, we'll just move the abstraction layer to another level, that's it.

[1] http://www.commitstrip.com/en/2016/08/25/a-very-comprehensiv...

Yup. One of the most important things I've learned in my programming career is that reality is damn more complicated that it seems. At all levels - both physical and abstract.

The real problem is that humans imagine things and communicate them at very high abstraction levels, without filling in the levels below. Much like a children's drawing of a car is nowhere near detailed enough to serve as a blueprint for building one, our usual descriptions of stuff don't contain necessary details at all. If you want to build a real thing, all the work to fill in the lower levels of detail needs to be done. You can't magick it away. Today, that work is done 10% by the people writing specifications and 90% by programmers figuring things out. In the future it might be done by a computer - but that computer would necessarily need to be a human-level artificial intelligence, doing all the work programmers do to go from the way we communicate to a working program.

You don't fill all the lower levels of details. You're likely not caring about generated machine code, you're likely not caring about details of memory deallocation, you're likely not caring about Unicode quirks when you're comparing strings, you're likely not even aware which algorithm is used when you're multiplying two BigDecimals, you're likely not care which characters are allowed in HTTP header names, and so on and so on. A lot of implementation details are already implemented. There's no reason that programs won't be abstracted further away. Sure, it still is programming, but with less unnecessary details (so more people can do it).

Most programmers/developers don't deal with the problems that you mentioned on a day-to-day basis. They are already abstracted away, and most programmers/developers try to make sure that they deal with the actual problem at hand instead of repeating the same problem in each project. The actual problems are not going to get any easier. The abstraction levels will get higher, but the actual problems dealt with will not.

You're thinking of the lower-level details of the computer but the issue is the low-level details of the problem you're trying to solve. The amount of detail necessary to solve even the most basic business problem is far more than the average client can ever describe on their own.

All the computer abstractions help solve computer problems and in turn make it easier to implementation solutions but doesn't make the business problems any smaller.

Yes, what you describe is the point at which abstractions meet your problem from the bottom. You're not developing solutions yourself down to level of pure physics, but that's because we have a solid abstraction layer of digital computing. Your job is to work down from the problem idea until you connect to that layer.

It still doesn't change the fact that the surface area of that layer is enormous, and so is the space between it at the bottom and your problem at the top. All the details in between is what you need to figure out.

I'm not completely sure the bottom can be qualitatively raised very far up. The digital computing abstraction is a qualitative model change, from physics to mathematics. Experience suggests that when you decompose a business problem, the lowest algorithmic details very often end up on, or slightly above, that bottom layer - so you need the ability to work on that level. Of course, if you're willing to limit your scope and problem domain, then a lot of things can be abstracted further - but they won't generalize.

You're right, but it doesn't seem that hard to teach/guide people to be precise.

The fact that you can get Linux kernel developers who rail strongly and vehemently against compilers because the compiler optimized it against what you said, which wasn't what was wanted, strongly suggests that it's not a matter of precision.

More specifically, people generally have a vague idea of what they want. While you could explain a fully precise mathematical model that corresponds to that idea, people don't really have a good way to know if the model is correct or if there is some hidden corner case that causes problems. So they accept the model until they find one case where it was wrong.

It's hard to impart the true understanding of just how much details a real-world problem has without making someone try and solve some real-world problems.

Right on. What many, and especially this writer with his talk of tech being more "human" don't understand, is that code isn't a language _for computers_. It's a human language used to describe something unambiguously, to the point where it could be eventually interpreted as machine instructions.

People not understanding this has, in my experience, led to a lot of very bad decisions, especially around outsourcing. So many people in 2006 thought that American/Canadian developers would disappear in a few years as everything was outsourced. They didn't realise that writing a "comprehensive and precise spec" to send to a team of developers on the other side of the world, and have them implement _exactly_ what you asked them to, was actually creating more work.

I think it is a nice way to look at it. I always thought all people in all professions are trying to figure out some "code", just in different abstraction layers.

I mean, a lawyer learns the "code" of law. A psychologist learns the "code" of human, which has a lot of black boxes but one can still make partial sense of it.

The comic misses the point. Yes, it's still called "code", but as you point out, the abstraction layer moves another level up.

This is the whole point behind the reverence for "declarative programming" in the Erlang world (and probably others). Tell the computer what to do, not how to do it. The "how to do it" part should instead be the responsibility of the programming environment (which can - hopefully/ideally/eventually - do a better job than the programmer at organizing the "how" in a manner which appropriately balances efficiency and robustness).

The Future of Selling Stuff to Enterprisey Places is Showing Them Slick No Code Interfaces and Persuading Them It Will Allow Ordinary Users To Get Things Done

(but there will be severe limitations and in practice the users will end up logging calls to IT support)

This is either just very misinformed or selling things to misinformed people. The fundamental problem is the inherent complexity in all but the simplest information systems.

The skill set required for managing that complexity is basically the same as for a software developer - and software developers have developed their preferred tools for manage it, and the relevant reason that the tools are not better than they are is that it's hard to build good tools, not that software developers are inept for the task.

I'm not saying that the tools can not be improved, but I'm saying that the tools won't be graphical.

More intuitive prototyping tools are another thing though - I'm all for it.

> This is either just very misinformed or selling things to misinformed people.

It's possible that that is an accurate description of all "sales"; if they were properly/fully informed, it would be called "buying", not "selling".

That strategy has worked since, at least, COBOL. I don't see the strategy breaking any time soon.

Indeed, the original design goal of COBOL was to make professional programmers unnecessary. That rather spectacularly failed to work.

I think the same can be applied to Cucumber testing: having to write “natural language” tests in one area and then a bunch more code to interpret that dialect.

Why not express tests directly in code like everyone else instead of pretending business people will ever write them, understand them or know their limitations? Cuke seems like extra busywork job security rather than GTD.

Despite plenty of experience to the contrary, I'm still a believer that there's some way to disentangle what needs to be done from how it needs to be done. I do think the business people have to understand what they're asking for, and how to tell whether they've got it. I don't think many of them are going to learn code to do it. Maybe there are documents out there, somewhere, that unambiguously describe what business people want and whether they've gotten it, but until I see those mythical creatures, I'm willing to cut Cuke some slack.

Cucumber did get one idea right though - enforcing a separation of concerns between a high level non-turing complete specification and turing complete code that executes it.

Gherkin just isn't a great language to demonstrate the benefits of that.

Hey, I remember my boss telling me about the wonders of Lightswitch. Silverlight was going to revolutionize things for "power-users".

Man check out my Geocities site!

I remember my boss telling me that Flash would replace html.

Oh man, that hurts to read. That's some wishful thinking there. I'm currently helping a division of the Air Force replace a legacy flash application that they've spent years trying to keep going.

This is not ‘no code’, anymore than someone programming in Python is doing ‘no code’ just because they aren’t programming in assembly.

A visual coding language is just providing a different abstraction, but it is still in the same space as other abstractions like a high level language such as Python.

Now, it might be hiding more behind the abstraction than a traditional high-level language, but that is a difference in degree and not kind. It does, however, mean that there are going to be more things that can’t be expressed in the visual language because the abstraction is too broad to be broken down enough. This means that a lot of the tasks that need to be done can’t use the abstraction and need a different programming language.

The way we make progress is by hiding more and more things under better and better abstractions. So this is the way forward - if the abstractions are better.

But there are two problems here. The first is that you can make better abstractions in text-based languages, too. In fact, it's easier to do there. So the visual coding language is always easily caught by text-based languages. They may be easier to use for the layman, but they don't offer anything extra to the professional.

The second problem is that abstractions always have limits. Good (useful) languages give you a way to escape from the abstractions when you need to. Evil languages sucker you in and then trap you in a too-limited abstraction from which you can't escape. (It's not just visual languages, either. The original Pascal, before the Turbo extensions, had exactly this problem.)

> The first is that you can make better abstractions in text-based languages, too.

Not always:

The most general data structure is a directed graph. Is a formal textual description as good as shapes connected by arrows?

MIMD parallelism is straightforward with dataflow. (No worries about synchronization: processes wait until they've received all their inputs before running.) Again, shapes connected by arrows partially ordered in two dimensions is a more natural representation than text.

Finite state machines. Again, shapes connected by arrows is clearer.

>> The first is that you can make better abstractions in text-based languages, too.

>> Not always

Why are you writing and reading in text / code? Surprise, surprise - the English language is text / code. Please, to support your arguments send in some pictures or models or videos etc.

I've been working on http://web.onetel.com/~hibou/fmj/FMJ.html

It's ongoing work, and visible progress has been slow over the past year or so. Recently I've been refactoring the code, and improving the type system. One thing worth noting is that representation of functions as a graphs makes type inference more straightforward.

English and other languages are text because our ears hear a single stream of speech and written languages reflect that. Historically, computer programs are single streams of instructions because computers have until recently had processors only capable of doing one thing at a time, and we've usually programmed with text (GRAIL and DRAKON being exceptions) because that's all most terminals could display.

But for finding your way around a city by subway, representing an electric circuit, an organic molecule, or an elementary particle interaction, we use diagrams.

We should just use category-theoretic diagrams for everything.

> The most general data structure is a directed graph. Is a formal textual description as good as shapes connected by arrows?

Oh yes. My company used a "visual" programming language for a workflow project and it's pretty much a directed graph with nodes -- the whole thing takes 50 printed pages to see the whole thing and is pretty much impossible to understand. And it's not even that complicated of a workflow.

> Finite state machines. Again, shapes connected by arrows is clearer.

Only for mostly trivial state machines.

As far as I can tell, this is an advertisement for QuickBase.

I can't tell from this article or their homepage how they are replacing code, but it sounds like they're trying to fill the niche of Microsoft Excel and Access, letting a semi-technical user specify limited queries and behavior.

Letting more users access the data they need is a laudable goal, but of course there will always be some need for the kind of precisely specified behavior that you get from code. "The Future of Some Software Is No Code" might be a more appropriate title.

Yup. The articles are making the rounds again. Here’s some older ones:

Apr 21 https://www.inc.com/greg-satell/how-no-code-platforms-are-di...

Apr 11 https://www.cio.com/article/3268508/leadership-management/en...

Mar 6 https://www.zdnet.com/article/do-you-really-need-developers-...

Feb 27 http://www.tucsonnewsnow.com/story/37601734/quick-base-power...

No it's not. For some reason, people with no SW background tend to under-estimate the complexity of seemingly simple business rules and their interactions.

Exactly. And that's my primary argument when I tell people they should learn some basic programming - because it can quickly make you realize just how imprecise the day-to-day human thinking and communication is.

“Rather than having to pay upfront, even the smallest startup could access technology that rivalled what a large enterprise had available to them.“

This assumption seems wrong to me and I’ll even suggest the exact opposite. Cloud software has traditionally been cumbersome since its the one size fits all approach. With the advent of the cloud, people were willing to sacrifice functionality for convenience. Now that everything is in the cloud this is not true anymore and we’re starting to see pushback at all levels. Almost every company has a different workflow that only custom software can serve best. This is why companies with more resources will win at the software game; assuming they know how to play. Molding software to your workflow is always better than changing your workflow to accommodate software.

I think a lot of people may be missing the point.

No Code is not about replacing all forms of software development. It's just about the vast majority of solutions can be done via no code platforms.

simplistically, wordpress is a no/low code platform that allows people to target all kinds of solutions. Complex issue trackers allow all kinds of workflows to be mapped. Our entire issue system / build / deployment process coordinates a number of services together, very very low code. But I feel confident I could model any number of build processes because the platforms are super flexible/powerful.

I've been watching a friend of mine who is running a vegan food box business ( https://thekaibox.co.nz/ ) put together the whole thing without code. It's not suuper smooth, but the whole webshop / purchasing / logistics / shipping / printing / people management etc is done with "No Code". But it's quite impressive what he can achieve, albeit with some manual steps, by connecting around 10 different pieces of software to do what he wants. I've been working with him as it always seems like he may need some custom software to make things work better. But we often brainstorm a way to do it with existing tools. The great thing is, he keeps adapting the system to match his evolving understanding of his business STRAIGHTWAY. This makes things super agile.

As platforms get better at connecting with each other it will allow more and more no code / low code solutions to be developed. I think it will be interesting to see what tools actually accidently become "no code" platforms because they build a base level of flexibility into it.

How about the future of world literature is no text / no alphabet?

Or how about the future of mathemtatics is no numbers?

Or how about the future of civilization is no books?

Or how about the future of marketing is no bullshit?

And so on. Source: https://github.com/bigkorupto/awesome-nocode

There is this product called Labview that does visual programing. I am not a huge fan because its just easier personally to write c code. Does everyone just want picture books. Plenty of people like normal books. I think Code is just more concise to understand. There are probably plenty of people who feel the same way.

Oh man do I hate Labview. I used everything else when possible including C, python with C bindings, and even MatLab compiling into C to give direct equipment directions. But that being said it is just my (and it seems like your) preference. I had several peers who were significantly better at getting the whole lab collection, processing, and output process up and running quickly and efficiently and they did not know how to code. I think there is a space for "no code" tools. Of course there will be someone on the back working with code but visual tools help lower that barrier for individuals with other skills than coding.

I don't think that either LabVIEW or C are particularly well-designed programming languages but the problems with LabVIEW aren't because it's visual. Visual programming does not make the problem of writing complex algorithms go away, but it does have other advantages.

> Much of what they used to set up in Excel spreadsheets or checklists on clipboards they can now do in cloud-based mobile applications.

> "A big part of the benefit to no-code or low-code platforms is that they let you access elements of a development environment visually rather than actually writing the code yourself. That accelerates development and improves quality at the same time," Marshall Worster, a senior director of solution architecture at Mendix, told me.

So this is today's equivalent to an Access DB or spreadsheet designed by a non-technical user which grows completely out of control, and then a programmer is eventually brought in to clean it all up with much more difficulty than if he had designed it in the first place.

These tools have their place but there are serious drawbacks to them.

The author of the article is forgetting a ton of things that software building needs. If that Janitorial service needs to scale and use data to drive optimizations and improvements, I doubt quick base can do all that. Another way to put that is, can you build google maps with quick base?

So it’s not really the future. The future that the author suggests is already here. We have form builders, web site builders, accounting tools that can be customized, automated billing and scheduling tools etc etc. So yes, most business can subscribe to these tools and avoid writing code. However someone still has to write code to make that happen

I work for one of these companies (Mendix) and no surprise, I strongly believe that no-code/low-code tools are here to stay.

What will they replace? Certainly a lot of CRUD programming. That's the absolute sweet spot for now. But make no mistake, high performant enterprise-grade systems with 10.000s of concurrent users are also being built.

I personally don't think it's the visual programming that makes the difference. Instead, the magic is: the very tight integration between forms, logic and data model. This allows rapid application development (not prototyping!) of web/mobile applications. Hardcore developers become many times more efficient and "citizen developers" can still contribute things such as business logic without knowing all the low-level details. All the boilerplate BS of modern web apps? Gone. Instead you just have an IDE with a "Run" button.

An example: remove an attribute from an entity in the data model? On next deployment, the system will remove the column from the database automatically. Also, the IDE will show errors (within a second) in all the forms where the attribute is still being used, so you know what to change. This gets you in a state of flow very quickly. I know many developers that would hate switching back to Java/.NET because they can't get nearly as much done.

The tight integration is possible because the syntax of visual programming is simpler/more limited (and very strongly typed). This allows the compiler/IDE to reason about what the "code" is doing.

I had a deja-vu reading this article, sounds just like the things that were promised in the 80s, then the 90s and probably other times I missed. There are periodic tides of centralization and decentralization washing over the IT world.

I do feel things are different this time around, though. SW distribution really has been significantly improved and there are much better ways of doing client/server applications now.

As to graphical app development UIs taking over programming - I have my doubts.

I also had a deja-vu moment. When I began to study CS a professor of us really tried to get us into electrical engineering instead of CS. His basic argument was, that in 10 years programmers will basically be unemployed or on the verge of it, because even nowdays there are visual code generators that can create better code than most programmers could. That was 2004 and I think he was referring to LabVIEW.

A lot of things have happened since then, but LabVIEW is still very much a niche application for a very specific domain. And code generators didn't magically abstract away integration, requirements optimization, scaling and architectural desision making.

> I had a deja-vu reading this article, sounds just like the things that were promised in the 80s, then the 90s and probably other times I missed

Even the Smalltalk environment in the 70s, sort of. Not in replacing code, but making an environment where any end user could create their own applications, so they wouldn't have to rely on programmers.

Oh man I can't wait to write my new tech in LEGO Mindstorms EV3 block code or Scratch or SIMULINK or literally just Visio drawings with a bunch of scripts on top. It's a massive horrendous clunky pile of inextensible garbage 80% of the time. The only reason it's ever been wanted was so managers could visually see what you're doing and quite frankly as the person writing it I should be explaining it rather than them looking at it.

The code is the easy part.

The understanding of how systems and resources fit together to accomplish goals -- that's the hard part.

If you're trying to replace the software developers that take fully-fleshed-out work items (including a complete pseudocode description of business logic, edge cases, failure modes, acceptable data ranges...), then you might have some success. But then you've only managed to replace the lowliest of developers.

Even in my experience as an enterprise developer, I've yet to come across anyone that didn't bring some amount of independent thought to the process. And, due to the nature of our work, almost all of us learn to question assumptions, hone definitions of behavior, ponder possible failure scenarios, and just in general ask the "what if?" questions that will bite us if left undiscovered. Our ability to translate that into a standard machine-readable language is really a small fraction of the value we contribute. Yes, it is a barrier to entry—and it's seen as akin to voodoo by some non-technical types—but replacing it with something with a "friendlier" interface doesn't shrink the problem domain in the slightest.

I'm in two minds here.

On one hand, it's a bit of a shame that the article focuses on "no code". What the linked applications all seem to do is a pretty standard package of workflow tooling, reporting generation and data source connectivity. If any of them do a better job than all the existing ones them good on them. In my experience, good tooling here is quite hard to come by and could be very useful/valuable.

On the other hand, on the odd occasion that I've had users buy a tool believing they're doing my job, it's ended up net positive for me. When it inevitably goes south, the reminder that what I do is actually harder than it looks has been beneficial. Obviously, I always get in writing that I wouldn't ever have to support their efforts at finger painting.

Oh great, another article claiming that cloud and APIs will make code go away. What do these people think drives APIs and provisions infrastructure in the cloud? We may get better abstractions for some forms of data, but there will always be a demand for code, even when we get hyper-intelligent AIs it will still need to be able to generate code.

At $WORK, management attempted to jump on the no-code train, forcing us to use Salesforce and OutSystems to attempt to write complex business systems. What we got was an unverifiable, totally vendor locked, poorly performing system that cost hundreds of thousands of dollars. It was an exercise in frustration.

Any system sufficiently complex to replace programming is indistinguishable from a poorly written and designed programming language. It's the same broken thought process that leads to business rules engines which themselves always end up being maintained by a specialized programming team. You can't magic away the skills and requirements that necessitate a programmer, you can merely make the programmers job easier or harder.

orclev law :)

I'm curious, what were the worst parts about that experience? Was it the limitations of what was possible on those platforms, or were things possible but just too unwieldy? Can you imagine a scenario in which it didn't suck?

Only using visual development exacerbates traceability and verifiability though. Reviewing "code" is hard if there is none.

For example I have yet to see a good way to visually diff graphs.

Text diffs are usually shown by displaying added parts in green and removed parts in red while including surrounding context in a neutral color.

You can do exactly the same thing for graphs.

You can, but I have not seen tools that actually do. My issue is that I develop a graphical node-based programming language and I'd like to be able to see diffs. I thought that I could convert our format into some other form and use a diff tool for that format.

Right, the problem with developing a completely new programming language is that you need to also create new support tooling for all the ways in which it is different. That's one of the reasons most programming languages are so similar: it's just less work that way.

If you use text as a storage medium, you can reuse diff, grep, sed and other text-based tools. They won't be perfectly adapted to the language semantics, but good enough. Debugging with gdb is a similar situation: if you include DWARF in compiled binaries it works, otherwise your language needs its own debugger.

I think the best thing you could do is to convert your graph into some common format like dot and create a generic diff tool for that format to make it easier for the next person with similar needs.

We are using xml underneath, the problem is that since the graph can be cyclical the nodes and links are in separate lists, which makes a standard diff quite a poor tool. As you say, converting to dot and making a tool for that is probably the way to go. I was just hoping that I could do just the first step. I was thinking about SVG as well, but in that case the diff would have to be very specifically tailored and not much of a reusable brick.

This reads like a promo piece for these companies. It's been tried many times and hasn't worked.

As a developer, I'd love anything that makes my job easier, but that usually is more control and explicitness. I think "always bet on text" is a more accurate future: https://graydon2.dreamwidth.org/193447.html

I strongly agree. Text is just much more efficient in so many ways.

A tangent, this is related to why so many people - myself included - love the paradigm of Emacs as an OS, i.e. moving as much of their workflow and non-work tasks into the editor. It's because of - severely underexplored elsewhere - the power of the abstractions around text Emacs provides. When everything is text - including the UI - but the text isn't transient, like typically used in Unix, but at rest, like in text editors, you get to employ the same set of editing, navigation and search commands to do vastly different tasks. Combine with how so many things can be represented by text, and you get a very powerful tool.

I’ve worked for a company that had a significant need for developers (18% growth per week sustained over three years). Most of the needs were not addressed by product team because no one had to time to notice them. So, some of the guys decided to use no-code tools to set up processes: Google Docs, Zappier, IFTTT were popular, connected haphazardly to the Reporting tools -- up to a point where half of the process complexity was hidden in those areas that the CTO had no idea existed.

Was it good, scalable, usable? Not really, it was a heart-stopping inconsistent mess, but it held while the company was hiring. It gave to the newly hired product managers patterns to follow, experience in which processes to follow, impact estimates of what needed to be prioritised.

I’ll readily agree that the circumstances were exceptional, and the communication with the product teams could have been more helpful, but the no-code approach provided prototyping. I can imagine a tech lead push back on some requests by asking project managers to implement some options with no-code tools and come back with more insights, before committing developper time.

I recall we were shown something like this a while ago in an embedded systems class. Engineers can basically build their engine/flight/you-name-it control software from boxes they click together. Some are inputs (sensors), some are outputs (actuators), other mash those together (tasks) - so you get a graph-based model of your system. And a compiler builds structured C code from it. I was told - so this is just hear-say! - that it's not uncommon for the engineers working with these tools to be well qualified domain experts, but rather poor programmers.

What I want to say is: This no-code stuff the article is mentioning as cool and agile and all - that is already in existence for nearly 20 years; and that's only one tool I accidentally happen to know of. The author just adds "agile", "cloud" and "disruptive" to a yesterdays idea/technology.

(I should disrupt myself now from the thought how a WYSIWYG web editor is an cloud based tool using a no-code way to generate HTML from your text; and in most cases that probably even qualifies as agile...)

I liked this meme better the first time around -- when it was called CASE tools.

Or how about the second, when it was called UML code generation?

The computer magazines of the 80s and 90s are littered with advertisements from fly-by-night companies promising: "Develop this app with ZERO lines of code!"

The problem with codeless development environments is -- okay, instead of code I'm going to represent programs with something else, say, a symbolic language based on flowchart symbols. The problem is, once my flowchart symbols become concrete enough to be executable by computer, they also become isomorphic to constructs in some programming language. So you haven't really gained anything in expressive power, but you have:

* possibly made things more comprehensible for visual thinkers (at the expense of verbal thinkers). Note that men skew visual and women skew verbal, so this may be considered sex discrimination.

* forced the developers to engage in far more rat wrestling

* required as a hard dependency a particular development environment in order just to get the "code" up on the screen, let alone interpret or change it, thus committing the mortal sin of vendor lock and, in QuickBase's case, locking the application into a cloud platform which may go away when the company liquidates

* made the program more difficult to version-control, diff, or perform large-scale edits on (outside those explicitly supported by the tool)

* turned complex programs into visual clutter, making them far more difficult to manage

* made it difficult or impossible to do things which violate the tool's assumptions about the program structure or function

And there will be assumptions, because the way to gain more expressive succinctness than is exposed by a typical programming language, and hence to build the case for using such a visual tool in the first place, is to assume like crazy. Assume that there is a database, that the application will appear as various forms and reports, that programmers will never need or use certain constructs/patterns, etc.

So invariably these attempts to take the code out of software development fail, and get relegated to niches akin to the skeevy back pages of PC Magazine right next to the porn advertisements. It seems to be happening again, as lastI heard QuickBase wasn't doing too good.

FileMaker Pro

Access

Rational Rose

Logic Works ERwin

App Maker

PowerApps

OutSystems

VisionX

Mendix

QuickBase

... and a zillion others.

There’s nuance in a spectrum between non-technical end-users developing simple workflows and forms, and trying to run an entire business on it with business rules, interoperability, standards, etc.

I worked at IBM back in Rational Rose's heyday (though not on the Rational team, thankfully). The sheer amount of configuration you'd inevitably end up doing was orders of magnitude greater than the actual thing you wanted to write.

Learning to use APIs for open source libraries is really where the power of creating quality custom apps fast and easy resides and a GUI laid on top of those is a very limiting factor.

I made my first app with one called "The Apple Media Tool" and another with it's successor, "iShell". Using those did help me understand how code worked when I was first learning but they also exposed the limitations of taking that route, and they're huge.

If I had an app that provided a GUI for all the features I might want or need now it would be bloatware that takes a very long time to learn how to use and I would still be limited to what it included.

The rub is, you don't always know what you need until you need it when building an app.

Learning how to use available APIs on the other hand has no such limits and allows you to drop them in and learn how to use them on a "Need to Know" basis, and to contribute to the projects that provide them.

That's really a pretty great way to build software.

Always wrong, always.

Pick some problem space. Now imagine specifying some tool to work in that problem space. Now imagine all of the unique cases and complex interactions that need to be handled and how the specification needs to take into account all of them. You can't simply rely on "obvious by context" solutions, the specification needs to embody that context, AI won't save you. What you have in the end is a very complex machine, it is code. You can move up and down the abstraction levels from machine/assembly code up to python or SQL up to even higher levels, but it's all just coding. I contend that job will never go away. It may approach problems at progressively higher levels of abstraction but that just makes it more valuable, not less. Today coders are able to automate things that in the 1960s would have seemed like magic, are coders less valuable and in demand today or more?

It depends how you define "code". If "code" is a system of rules to convert information from one form, to another, then software will always need code.

This article talks about the "agile", but creating software has never been about code. It's always been about delivering value. Code or no code, creating software and delivering value is no trivial task.

I believe we will always need to define the conditions and boundaries that computers need to work within.

What we need to get better at is defining and communicating what those conditions and boundaries need to be.

I think one great example of that is Behaviour-Driven Test (BDD) and gherkin. Gherkin is code written in a business readable, domain specific language.

Programming computers may change and complex computer code will become abstracted away further, but no matter how you look at it, programming computers will never totally disappear.

This has been an age-old promise, but I see two primary bottlenecks that keep surfacing.

First, non-IT experts don't understand the trade-offs involved in their decisions. They may make a barely "good-enough" decision to get started via trial-and-error, but it often doesn't take into account a lot of implications because they don't know what questions to ask themselves and others.

Second is that existing data is not very malleable. Once production data is created, it sets conventions in stone that are not easy to change. You cannot change your data structures and relationships without a lot of manual re-translation of the data itself. Therefore, early decisions make a big impact, bringing us back to the first bottleneck.

A better use of resources is perhaps to make IT professionals faster rather than try to make non-IT people into instant IT professionals.

This made me smile..

So legacy applications are going away? Like the one that I maintain at work, written in (mainframe) SAS, which is so-called 4th generation programming language, invented with a promise of users just "telling" computers what to do in a "natural" language.

Don't get me wrong, I like the promise. It's what Facebook is doing with Haxl, which is a domain-specific language for content filtering, written in Haskell.

Unfortunately, the needs of users will often grow and the language will have to become Turing-complete (like for example, HTML/CSS was extended with Javascript), if it wasn't already, and also will have to become extensible by user routines written in mainstream language. And then you get messy, "legacy" (as they are called after few years) systems.

The bulk of programming is dealing with all these layers we've come up with. To make things easier for humans to send commands to machines and make them do what we want them to. Honestly a decent level A.I. system could replace most coding. I don't think it would need to be human level but at least would need to learn from watching people do tasks. Yes most apps are CRUD apps but a lot are CRUD apps with events that need to happen at certain times to maybe give feedback to users or populate another part of the app. This is where good UI + UX comes in. That is not an easy thing to do once you break out of the canned templates.

I started this post thinking a decent A.I. could do this but now I'm not so sure. ;-)

There is no such thing as "no code". You can hide it behind pretty interfaces but in the end, you are just using images instead of words.

And with images, people think of children books, easy, right? In reality, as soon as you introduce a tiny bit of complexity, it becomes closer to Chinese. In Chinese, you can still see the little drawings, but that's just the background of a highly complex language.

Whether you code in an English-like text based language or a proto-Chinese-like picture based language doesn't change the fact that you are coding. Most people end up preferring the "text" approach that is more adapted to computers, and ultimately easier.

At least 80% of Chinese characters are picto-phonetic -- meaning that you have a radical that only gives you a vague category for the lexical item and another part that gives you a hint of how to pronounce it (or would have when the character was devised, anyway; there's substantial drift). To think about this in terms of English, imagine the word "I" were written with a stick figure and a picture of an eye (except for most the meaning is a little more obscure than this). It's only a handful that are really like pictures.

I personally feel no-code/low-code platforms are here to stay and will be the future.

The straight-away advantage with these platforms is the readily available development environment. The visual interface helps you to improve the quality and accelerates the development which allows Rapid Application Development (RAD)

These platforms allows you to move towards app modernization in a flexible and incremental approach with out disruptions.

WaveMaker (https://www.wavemaker.com) is Yet another RAD (Rapid Application Development) Platform which also offers continuos Deployment.

No Code Trivia Quiz:

Q: What's the name for someone who can't read & write?

- (A) Chief Alphabet Officer

- (B) Illiterate Know-All / Know-Nothing

- (C) No Alphabet Creative

- (D) Other - Please Tell

Q: What's the name for someone who can't read & write code?

- (A) Chief Digital Officer

- (B) Certified No Code Business Architect®

- (C) Quick Base / Mendix / Zudy / Pega / <Your No Code Corp. Name Here> Marketing Bullshitter

- (D) Other - Please Tell

Source: https://github.com/bigkorupto/awesome-nocode#no-code-trivia-...

Wow. I read that page, believing it to be satire, but then clicked through to pega.com - https://www.pega.com/technology/software-writes-your-softwar.... And I'm still not sure if this is an elaborate in-joke.

It's not satire. It's "real world" marketing bullshit. Would you hire an accountant that tells you that numbers (and mathematics) are so last year. What really count is your customer experience (CX) journey and so on. Welcome the wonderful world of highly-paid buzz-word C-level business executives. You might also enjoy the Get Rich Quick "Business Blockchain" Bible - https://github.com/openblockchains/get-rich-quick-bible Reads like a satire too (but all "real world" examples).

There have been earlier attempts at this, e.g. The Last One: https://en.wikipedia.org/wiki/The_Last_One_(software) They work only to the extent that the generated programs were foreseeable by the software designers.

> You don’t code software in Pega. You design it.

This has to be from a mindset that designing and coding are different jobs done by different people: http://wiki.c2.com/?ArchitectsDontCode

Yes, but the copy on the page was the part that tripped me up the most.

Lots of good comments in here. I will chime in with the observation that: we've made a lot of progress. To be a programmer 30 years ago is totally different from today. The tooling is better, more approachable, more abstract and less technical.

Will we ever be without code? Doubtful. Things will evolve and improve, but the only visions sold of no longer having code is in the sales pitches of products.

There exists a tool called "Blue Prism".

I have an existence proof of an enterprise that was/is sold this tool on the basis that there is no code and the users will use the visual editor to create the code themselves.

Behold : https://www.indeed.co.uk/Blue-Prism-jobs

If it's so easy why are people being paid £500 a day?

I've been trying to automate myself out of business for 30 years now. So far, I have failed miserably at it and am busier than ever.

People have been saying this for at _least_ 30 years.

https://www.washingtonpost.com/archive/business/1990/12/31/a...

FYI: I've started a collection about awesome no code [1] - Why code? All about the Chief Digital Officer's (CDO) clicky-clicky-clicky dream future. No text. No numbers. No code.

[1] https://github.com/bigkorupto/awesome-nocode

I do believe that the majority of coding will be replaced by AI or some automated process requiring some inputs and expected results to "code" an application. However, this article reads like an advertisement, and it fails to go deeper into the topic at hand, unfortunately.

"Linux supports the notion of a command line or a shell for the same reason that only children read books with only pictures in them. Language, be it English or something else, is the only tool flexible enough to accomplish a sufficiently broad range of tasks."

-- Bill Garrett

Whenever I hear of this I think of "The future of math is no algebra, only geometry".

"640K is more memory than anyone will ever need"

No it's not. For the simple reason that Artificial Intelligence can never ever cover for Natural Stupidity.

when I think of no code/ low code. I shudder a bit as I think about ServiceNow.

Yeah. I remember when 4GLs were going to replace COBOL, too.

Code isn't going anywhere.

As long as computational operations exist, there will need to be a language to represent those operations. As long as that exists, there will be more languages to streamline that, and so on and so forth.

Computers are not magic. They do not think. Even if they did, they would be constrained by the same fundamental linguistic bottlenecks that we human beings are.

To illustrate this point: I will concede that no code solutions are possible when every human being achieves Buddhist Enlightenment. This would be the human equivalent of a no code solution. No one communicating, or orchestrating external experiences to create an epiphany. Just an internal realignment of values.

Another illustration: Convince all of your neighbors to agree with you without communicating to them in any way.

Coding is a fundamental axiom of information transfer. If you aren't doing it in some fashion, you aren't DOING anything. If you are doing it, then you are constrained by your encoding scheme. The thing that trips up most users is that they aren't consciously aware of their own encoding schemas, and are typically resistant to adopting someone else's. In the article's case, they are asserting that "visual" programming is not code.

Which is dead wrong.

It just means the new code is your visual motif or paradigm. (E.g. A box means X, a line means Y.)

Underlying that visual implementation is...nothing else but more code!

You will never compute without code. You will never COMMUNICATE without code.

This entire article is just a visual representation of a complete vacuum of common sense.

Note the irony: My response is an example of resistance to adopting the author's encoding scheme. It is likely that his point is not communicable to me in its current phrasing because we have fundamentally different experiences and knowledge structures that get decoded from the same visual representation (the article). Or it is being clearly communicated, and it's just BS.

(E.g. when I see the phrase "no-code solution", it translates to me as a hypothetical solution that doesn't require communication of information according to a fixed set of schemas to orchestrate desired computing behavior. This is dead on arrival. If we are communicating, coding happens.

Either the author is mistaken, or I am. The only way to know for sure is for he and I to COMMUNICATE, establish a common coding schema between us, a "common sense" if you will, and to clear things up so we can both confidently say that we are saying the same thing about the same thing.

TL;DR:

No-code happens when world peace does.

Sweet, I barely write code at work now. So I should be setup well for this.

Reply on news.ycombinator.com