[repsilat]

Hah, I was nodding along with the article and then got to this bit:

> What reason is there to believe we can improve programming technology to be vastly easier and more accessible? To start with, spreadsheets. Spreadsheets are by far the most popular programming tool, used by far more people than “real” programming. Surely it must be possible to carve out other domains like that of spreadsheets without taking on the full complexity of programming.

As someone writing a spreadsheet app with magical programming powers (https://6gu.nz) no wonder the author seemed to be sweet-talking me :-).

And yeah, I think we can do a lot better. Some low-hanging fruit: backslashes in strings, "what is Unicode", "what is a hash function and why do I care?". Etc.

There's a crap-tonne of essential complexity in just about everything we do, but most tasks for which "programming" should be the right answer are not the sorts of things programmers actually do.

Part of the problem is, we have all the best tools because we are the tool makers. There isn't good version control for Excel. Linting is mediocre. And the language itself sucks, because the programmers who work on it don't think spreadsheets are programming, and don't think the people using spreadsheets are programmers.

I do think the conclusions of the article are o ff-base, though. I have no faith in professional societies, and I don't think the answer is "institutions". The answer is business -- bringing programming to the masses is worth trillions. Programming is the biggest force-multiplier that exists. It's what the FAANGs (widely disparate companies in different industries) have in common -- they (as companies) "know how to program".

Maybe businesses are short-sighted, but the value here is so big it just has to happen. Magic of capitalism and all that.

[vanderZwan]

> There isn't good version control for Excel. Linting is mediocre. And the language itself sucks, because the programmers who work on it don't think spreadsheets are programming, and don't think the people using spreadsheets are programmers.

Since you're writing a spreasheet app, I presume you are familiar with Feliene's work on this topic?

http://www.felienne.com/publications

Also, you probably will find Edwards videos about his own experiments interesting:

https://vimeo.com/jonathoda

[repsilat]

> I presume

I'm not! Thank you!

I've been pretty heads-down writing my thing, but I'll be sure to set aside my evenings to go through both sites exhaustively, and probably try to get in contact with both to ask for feedback.

[shalabhc]

Also check out Flowsheets by Glen Chiacchieri: https://tinyletter.com/Flowsheets/letters/flowsheets-v2-and-...

[mjevans]

Programming for spreadsheet like things is something a DBA does for /databases/.

No, they don't look like spreadsheets, but THAT is the industrial strength tool being used by a professional chainsaw juggler.

[repsilat]

AirTable looks kinda like a spreadsheet, and it's a MS Access clone at heart. Not terribly programmable, though it does look pretty usable.

I think "traditional" databases will fail to reach a general audience (or rather, much expand the definition of "technical audience") because SQL is not really easier than Python etc. Maybe the problem is environments and not languages, though.

Personally I think the relational model is just a little too limited. It's possible to build abstractions in SQL (views, temporary tables, `WITH` etc) but it's hard. And repetitive.

Basically I think functions and variables are great little building blocks, so I'm pushing them. And then, having not backed myself into a corner with by having chosen a limited computational model, I'll make relational stuff easy too :-).

[mbrock]

I wonder what you would get if you crossbred Postgres and Haskell, for example.

Basically adding indexed tables to the Haskell data model, maybe? Some hybrid of relational tables and algebraic data types?

Sometimes even when writing compilers I’ve had a feeling that relational queries and update would be really nice.

There seem to be four main data paradigms: (1) objects with pointers, (2) algebraic data types, (3) relational tables, and (4) Prolog-style clauses.

Some Haskell programs seem to partially reimplement 1, 3, or 4 using 2...

[lisper]

> backslashes in strings

There's a simple solution to that: use «balanced quotes»

[repsilat]

Does that help if those characters appear in the string?

My bet is on editors that let you "type your string into this text box".

[lisper]

> Does that help if those characters appear in the string?

Yes, that's the whole point.

«With balanced quotes you can have «embedded strings» without escapes»

The only time that doesn't work is if you want to embed a quote character as a character rather than as a string delimiter. But that is extremely rare.

There are also “different styles” of balanced quotes to choose from, so you can embed a quote character of one style inside a string delimited by a different style.

There will always be perverse situations where a backslash is needed. But you can make them much less common with balanced quotes.

[arkh]

PostgreSQL allows dollar quoted strings. $whoohoo$this is a string $whoohoo$. A really good way to include strings in strings as the tag can be almost anything you want. I think it is more flexible than heredoc and friends.

https://www.postgresql.org/docs/9.0/static/sql-syntax-lexica...

[iainmerrick]

I agree, but even there you can have problems if you want a string containing a newline or tab character!