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.)

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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 result may be complicated under the hood but may be easier to operate as well.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.)

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.

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.

A lot of these optimizations have already been solved.

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

Dumb advertisement article...

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.