This is a good take, but easy to misunderstand.

The main problem is that MOST "programming" languages/environments are not made for business apps, (or for other niches, btw).

Python? Ruby? Julia? Delphi? all fail to work to make(or solve even small cases of) business apps.

By a long mile.

-----

What Excel solves, is have a barebones, half-working, unscalable, ill-suited... BUT MADE FOR help people get a "solution" for this.

Things that are more like this are Django, Jupyter notebooks, a little of Julia, FoxPro. But still are more pro-developer than pro-power-user.

Power Automate or whatever it's called exist.

I'd say the great weakness of No Code solutions isn't so much they are bad, but that they have no FOSS support. At all.

I'm a firm believer in empowering end user automation. The atrocities that folks cobble together with the Excels of the world are a marvel, and more power to them.

But in the end, we all talk about leaky abstractions, and the stark horror is that the fact that all of these wonders run on a computer, the worlds leakiest abstraction, the worlds most stubborn, pig headed, cantankerous contraption out there.

And all the lipstick in the world can't hide it.

I think it goes beyond automation and into customization. Giving end users the power to "program the program" just makes it possible to make the thing do what they want in a way that it wasn't set out to do. Without having to pay/find/wait for a developer to do it. Sometimes it's about automation. Sometimes it isn't.

>More and better tools that let "regular" people program.

There's one catch with Excel, the more complicated your spreadsheet gets, the closer it gets to programming. And at some point, it's more cost effective to write in a proper programming language than continue to maintain mess.

However, until this complexity level, Excel is great, and empowers a lot of people who barely know the basic features of Excel to solve their computational problems.

You can already have "regular" people as software engineers if you follow basic concepts like the SOLID principles. Unfortunately many engineers are incredibly smart and they don't see the difference between writing spaghetti code with cryptic names and writing clear, legible code that normal people can follow. I've worked with people that could figure out a program written in binary if they needed to, but that meant that they never learned to write structured, sensible, readable programs.

Or more realistically the rapid application development tools need to be better so we're not bogged down dealing with latest fad or resume driven development

There's not much reason to improve things. No one's out here saying "you don't get this job because you chose new technologies when they weren't needed".

Even if you can equate glue code with trash, we seem to have unlimited space or a black hole to throw that trash.

What more do you want beyond Wix and VB.NET? People just don’t use RAD stuff anymore because…well I don’t know why.

Regular people have their regular jobs to do. They want to use tools, not build them.

I'm all into PowerApps and all that, but no-code for anything the least bit sizable or complex is a fantasy from citizen developers.

It is not a fantasy for small businesses, who rely on internal tools and processes to operate. These tools solve real pain points for them and that is why they exist and why it is a fast growing market.

It's a lot of hype right now, not necessarily indicative of staying power. We've been through multiple bouts of "no-code/low-code will replace X" and it has never materialized in any meaningful way.

Zapier has been around for a decade at this point and has shown continuous, revenue-driven growth

>We need more "Excels." More and better tools that let "regular" people program.

The only reason why more people don't program is because Windows is antithetical to programming _anything_. The second you remove people from a windows environment is the moment they start coding, even by accident.

I was agreeing with you, but as I thought about it, I remembered MS Access. It is used, often ships with Office, but still isn't close to as popular as Excel. Either the model is wrong, or the need isn't there.

MS Access has awful UX. I've used it on and off over the years and can never find my 'flow state' as nothing in that program seems to flow at all.

If MS prioritised working on it it may have helped lift some people out of Excel and into DBA-lite territory but not in its current state.

In my experience, the main problem is that while Excel "distributed code versioning" with a whole bunch of copies around is awful, Access databases are not only much more prone to corruption and data loss in general (even in single user, non-simultaneous ideal use cases, never mind people attempting to multiplayer edit it over network shares...), it's often very hard for non-programmers to get any insights on any data you threw on it without using Excel in the first place.

So if the data is coming from Excel, and being extracted back to Excel, why use anything besides Excel?

Access used to be pretty standard for a small business trying to improve their situation, but we in the software development world spent so much time trying to work around limitations of Access and upgrading growing businesses out of Access that we took it personally and shouted to everyone not to use Access.

However, it is still taught in IT classes as a useful tool for small businesses, and it is.

My very first paid web gig was connecting a small business' Access based product catalog to their website. I was 14 or 15 at the time. I was able to do it with out any real coding knowledge except for some basic HTML I learned from MySpace and some copy-paste VBScript, haha. The site was a hit and I made $1,200 and immediately spent it all on an electric guitar.

MS Access isn't as good. Again, e.g. Hypercard.

Excel programming errors cost business $$$ https://www.cnbc.com/amp/id/100923538

Many more such cases [0], but Excel and spreadsheets in general also save businesses $$$$$, which explains their pervasiveness. Calculations take a long time and are easier for a human to mess up, which is why the initial spreadsheets were so popular as to drive the adoption of the personal computer in general [1]. The gulf between Excel and Python is pretty obvious, but there recently there have been few with their sights set on it, as most programmers looking to improve programming do so from their own experienced vantage point.

[0] http://www.eusprig.org/horror-stories.htm

[1] https://www.wired.com/2014/10/a-spreadsheet-way-of-knowledge...

You’re right. All business should get rid of spreadsheets to save money.

We can't blame spreadsheets for the cited errors, because they're errors in arithmetic rather than Excel bugs. All businesses should get rid of arithmetic.

The question is not just how much Excel costs, it is how much revenue it helps bring in. And in many places, it brings more than it costs. Nothing is worse than a poorly designed webapp that was supposed to solve the "Excel problem" in a process.

Engineering salaries cost business $$$ too. And still introduce costly errors of their own.

Why would it harm us? We are problem solvers, we can use our intellect somewhere else. Programming is just a tool.

A lot of my colleagues are hybrid of traders + programmers. They do a lot of Excel. Sure, we can automate text programming, let everyone do Excel, and us problem solvers still won’t find difficulties finding high paying job.

I wish every programmer held this sentiment and I'm guessing most don't

Simon Peyton Jones put some work towards that:

https://www.microsoft.com/en-us/research/podcast/advancing-e...

User defined functions:

https://www.microsoft.com/en-us/research/blog/lambda-the-ult...

True, but just using Excel does not lead to decent data models, though. IMHO, what we would need is for "regular" folks to grasp the basics of relational database first (at least 1:n and n:1) and then build an easy to use excel-like tool around it.

I'm not going to argue whether the 'world actually needs' that, or if people mostly, actually want that, or if, since excel is already there if you want it, you probably don't have to write, sell or build any more low code tools.

...because, although I could argue about those points, it's fundamentally unrelated to the OP, and issue that programming is hard, and, for a very long time, no one has really had any idea how to solve it.

Now, however, AI generated code (like copilot) is, for the first time in a long time, a potential avenue to actually change how software is created at all levels.

I think there's pretty interesting, because it opens up a lot of new opportunities.

Is the future dynamic languages / high level specifications that are AI-transformed into typed verbose languages like C/Rust/whatever and then compiled?

The ancient tools like Rational Rose tried to do this, but the tech was never actually technically good enough. Maybe... we'll see a real change in this space as the sophistication of the models improves... or maybe, like self-driving cars, it's always going to be 'nearly good enough'.

Hard to say.

...but, hot damn. More excels? Please no. Excel already exists. Don't rebuild that stuff again. Build new, different interesting tools please.

>...but, hot damn. More excels? Please no. Excel already exists. Don't rebuild that stuff again.

I don't think they literally meant another Excel. Just something that is easily accessible and usable by non-programmers to do very 'programmy' things, etc.

This argument also just assumes, 'anyone can sit down and use excel'. Which is not true, excel has a learning curve like anything else, most people learn 'just enough' to do their job, maybe there is a guy in their office that knows a little bit more and they can learn from them. But excel proficiency acquisition is very similar to a programming proficiency acquisition, maybe the track runs out faster (at some point you reach real diminishing returns and limits to a spreadsheet's capabilities but I've seen some insane shit written in excel, raytracers for instance, but no-one who has done that thinks it's a good idea.)

>excel has a learning curve like anything else,

Agreed.

>But excel proficiency acquisition is very similar to a programming proficiency acquisition

Strong disagree. Maybe if you only consider those extreme cases you referenced (ray-tracing, heavy VBA, etc.), sure. But in general? No shot.

Excel gives immediate feedback with a visual interface. There's no need to learn about variables or syntax or memory or compiling. There's no dependencies and no package managers. It abstracts nearly everything away. Click the place you want the thing to go, type the thing. Want a chart? Click the picture of the chart you like and click and drag over what you want in the chart. Want to change chart colors? Click the color you want. Want to change how the data is displayed visually? Press the bold button, or the color button, or the border button, whatever your heart desires is a click away with the same interface your used to with Word.

A great comparison is a geographic heatmap. In Excel, you need 2 columns. One with some States/Provinces and the other with some numbers. Then you click the big map button and instantly have your map. I can write the instructions for it in the space of a napkin and someone who has never touched Excel can be making all the maps they want. Now think about how you would explain making the same geographic heatmap in Python (or whatever your 'easy' language of choice is) to someone who has never learned any programming concepts.

The amazing thing about Excel is that many (most?) people start using it without EVEN knowing how to make a simple formula.

They literally start using it as a way to lay out tables (usually of data). Then they make graphs. And add more tables. And learn how to use it like a basic pocket calculator (half of the formula I see that should be sums are actually =B21+B22+B23+B24+B25…) Then comes SUM. Then VLOOOKUP. Perhaps some IFs or COUNTIFs.

This process can take years for someone to go from first use to anything even slightly programming-like, if you squint at it.

A tiny fraction of these people ever do anything complex enough it looks even much like low-code or no-code "development". Even less write macros.

But you know what? In the first half hour, when all they wanted was to email round a list of team members and their lunch preferences, they already achieved something with Excel that they found useful, and they felt productive ever since. Most Excel users spend almost NO time learning the tool compared to how much time they spend getting (what they see as, and what probably is) value out of it, even when we are sat in sheer terror as we witness the horror they have unleashed on the world.

That is the bar you have to clear to make a "better Excel".

Honestly I tried to do some simple shit in excel today for the first time in years and holy shit, who thought this ribbon interface was a good idea. I'm going back to apple's numbers.

I don’t get the ribbon either, I keep it hidden and put everything I want on the quick access toolbar.

But it's way more discoverable, which is something that most "programming languages" of course, don't do at all.

They mean no-code or low-code tools, but those come with a large hidden layer. These tools are known for making the 80% easy and the other 20% impossible. Excel can also become a mess.

>Is the future dynamic languages / high level specifications that are AI-transformed into typed verbose languages like C/Rust/whatever and then compiled?

How is that different from the present? Why are these "AI-transformations" different from what a compiler can do?

A compiler cannot take arbitrary high level descriptions and generate code.

You’ve seen copilot right? (https://github.com/features/copilot)

It’s fundamentally more sophisticated. This is like asking what is the difference between modern ML translation and the previous 20 years of research on language translation; the former actually works.

The latter basically doesn’t except in very specific circumstances.

Compilers can turn language into instructions only in a limited extremely specific set of circumstances.

We need more interesting tools, as you said. As long as the horizon of innovation remains on "something that generates good old code" I'm not very excited about the future. Copilot is an amazing tool, sometimes gimmicky, but a tool of the present nonetheless. As a compiler, it takes instructions and generates instructions. We need a future where AI is involved in debugging, and program comprehension, and correctness. More interesting tools than a better RAD.

Yeah, I was using Excel as shorthand for "simple enough yet powerful enough tools such that someone who is perhaps an expert in something else can build themselves something useful."