Are spreadsheets a true programming language? | Hacker News Reader

Are spreadsheets a true programming language?

about.subset.so

29 pointsbhl50 comments

It's not an interesting question. (*edit* I'm kind of taken with someone else's suggestion here that OP was written by Chat-GPT or similar. It would explain how it made me kind of angry with it's vapidity).

Of course spreadsheets are programming. So are R, Hypercard, Logo, etc. Some programming languages/environments are more useful for some sorts of tasks than others, or are simply infeasible for some tasks. (You wouldn't want to, even if you could, build an ecommerce website in "R" or "Julia" alone but they're both clearly programming languages). Some programming languages might be downright useless.

What does it tell us to say something is a programming language? Whatever it tells us, sure, spreadsheets of the Excel variety are programming languages/environments, of course.

I'm actually the person who wrote this. To be honest, I did write this for some content marketing in mind and didn't expect it to blow up here. But I literally did not use Chat-GPT...not sure what that says about my writing or how good GPT is lol

Basically I found an interesting article found here( https://news.ycombinator.com/item?id=25043741) and summarized some key points from the comments while adding my own ideas.

Fair. I suspect what it means is that in the future there will be no reason for anything but an AI to write "content marketing", because it all reads like AI's anyway, and has about as much originality.

I put spreadsheets in a special category of "document-as-program".

As in: - an excel spreadsheet is a program that is run by Excel - a word document (with or without macros) is run by Word - a web page is a program that is executed by the browser

Documents-as-programs have this dual identity where they are a combination of data, presentation and logic. It's not a perfect categorisation but I find it helpful.

I mean... a ruby program is run by the/a ruby interpreter, same with python.

but I guess they aren't as presentation-focused in the same way, presentation focused for a certain presentation environment, as your examples perhaps are.

Hypercard, then, would be in this category?

I would say HyperCard fits here.

The GUI is determined by the interpreter/vm. A spreadsheet doesn't really define it's GUI - the "host" defines it. A ruby script building a GUI (e.g. shoes) can look like anything. A spreadsheet, word document or web page has to have some basic structure.

Of course with things like VBA/OpenOffice Basic, or SPAs with JS, those distinctions start to blur - it's definitely not a perfect categorisation and it breaks down eventually.

Maybe you could say every document is like a custom plugin. E.g. my spreadsheet is like a plugin to Excel/Numbers/Sheets I _think_ in fact in MSOffice and OpenOffice plugins actually were just special documents but it's been a very long time since I was in that world.

> To master it, you have to learn their unique command line in each cell, R1 notation, pandas, some linux. And if you’re using Microsoft, you have to learn their suite and VBA.

Huh? Was this written by ChatGPT?

I think it got eaten... by some Linux or something.

I'm currently introducing my kids (ages 5-10) to Strong Bad's emails... it's fun to see that they hold up!

Quite possible. There's been a rush of LLM products marketing their use for creating "content marketing" articles.

I suppose there's an enjoyable inception/dogfood possibility in this industry.

I don't think ChatGPT would write such nonsense.

One thing that's special about spreadsheets is that they figure out the order of evaluation from dependency relationships: something that is somewhat unusual in mainstream software other than make and dependency injection libraries like Spring.

I'd make the case that figuring out the order to do things in is "one more thing to worry about" and also gets in the way of parallelization.

Note the "old A.I." tools in the 1980s such as logic programming languages like Prolog and the production rules engines (expert system shells) used backward and forward chaining strategies to accomplish this but both had some awkwardness when it came to the cases where the order of execution mattered. My guess is that these techniques will shine again in the new age of low/no code.

LabVIEW is this way too. I wonder if dataflow programming is more intuitive to non-programmers, even if it might run up against limitations when extended to larger projects. Both Excel and LV have a reputation of being a way for non programmers to automate complex tasks.

I'm not sure if this is a fundamental problem or just an accident in how these tools have been developed.

That is, many dataflow systems have ways you can make systems by drawing boxes (operators) and lines (connections between operators) but don't give you facilities to make a reusable box which is itself comprised of boxes and lines. If somebody really tried to make a tool of that sort which had a modules and other facilities for programming in the large I know we could do better but this may very well drive away the kind of person who is attracted to these tools. (I think of how many "data scientists" react violently to the slightest bit of SE discipline such as separating the results in a Jupyter notebook from the code that generated those results.)

It's a shame because all the time data analysts are thinking about "How do I make the monthly sales report for August?" and not about "... for every month" and it is such a universal and predictable problem but the tools don't give people a structured answered.

A concept that I've thought about applying to production rules (and maybe other systems) is "rules and schemes" where the code is divided into multiple layers with a relationship similar to HTML and CSS. Logical rules are one thing, what you do with those rules are another thing. People apply this kind of thinking to a small range of concerns in "aspect oriented programming" but with the right kind of compiler support it could be applied to other things like memory allocation. I hear people complain about "colored functions" when doing async programming but when I write for arduino I often write programs where (in my mind) there are a few (say five) colors of function that all play a particular role in the system and I even avoid automatic variables on the stack because they are just a waste in a program of that sort.

Isn’t it the human users who figure out the dependencies and enter them explicitly?

Humans enter the dependencies, but not the order of evaluation for those dependencies.

I think the dependencies they're talking about are something like A1 = C3*C5, C3 = B2+5, B2 = 12, C5 = 13... to determine the value of A1 you'll need to know the values of C3 and C5 which then depend on B2 so simply computing cells in ascending order wouldn't work for the first iteration and saving the dependency between cells would probably let you work a lot more efficiently as data in the sheet changes.

Also, I gave a dumb example involving four cells - some spreadsheets involve thousands of active cells with complicated interdependencies, conditional formatting and hidden ranges... these large sheets are usually rather responsive for how much unstructured complexity is in them.

Exactly, you could write formulas like that in Python but you would need to spell out the exact execution order, which is "one more thing you have to worry about" that divides professional programmers from everyone else.

At an introductory level it doesn't seem like much but there is a certain point in complexity where it becomes a major burden, particularly when it comes to composing complex systems out of multiple parts.

That's how frameworks like Guava and Spring banished the Factory, FactoryFactory, FactoryFactoryFactory, FactoryFactoryFactoryFactory, ... pattern in Java by creating a MetaFactory that sees the relationships between all the parts as a whole and resolves all of the things that would seem circular if you didn't carefully tease them apart manually. Things of this type, however, have a remarkable ability of "slipping people's minds" and you still hear people complaining about the Factoryⁿ problem in Java which is so 1998.

www.observablehq.com Does this for javascript. It was actually a learning curve to use but the code ends up much neater.

I have a feeling that the react world is rediscovering observables

They’ve had it a long time with MobX but they don’t seem to care.

QML is also very much like that. One declares relationships and the interpreter/compiler figures that out automatically. Highly recommend tinkering on it.

it's gonna be the next topic in computing IMO

dependency graphs are related to concurrency, decoupling, reactive rendering, lazy recomputation, efficiency and ultimately code concision (if you remove order safety, and memory updates from the code, only few lines remains)

Yes, spreadsheets are definitely programming. I use spreadsheets to implement GUI applications for specific administrative/planning tasks, for example:

- At work I'm tasked with grouping 40 administrative areas into larger geographically cohesive groups so that each group is roughly 20 km² in total area. This can be done by hand, sure - and I could also implement a GUI in some web framework to help me do it - but a spreadsheet lets me quickly develop a special-purpose application with good-enough usability, and it's all in all faster and more intellectually satisfying than solving the original problem by hand with a calculator.

- For planning a 120-person dinner party I need to make a table plan, organizing the guests into a certain number of 8-person, 10-person and 12-person tables (constrained by the tables available at the venue). Sure, I could cut out 120 pieces of paper and write the guest names on them, or copy-and-paste names around in a plain text document, but again a spreadsheet lets me quickly count how many guests have been allocated to each table and whether the current allocation uses the correct number of each size of table.

What resources did you use to figure out how to do that?

This is an interesting use of spreadsheets.

In a historical retrospective on timesharing[1], Fernando Corbato (of Multics fame) mentioned that he considers VisiCalc (a predecessor of Excel) as a novel and important form of programming (he called it 'declarative').

[1] https://youtu.be/uZxfBbikNkU (it was somewhere in this video)

As time progresses we get more open-minded and close-minded simultaneously -- we're experimenting with new ways of programming and computing, but we've also internalized existing structures as innate/fundamental. Maybe Corbato was just thinking creatively, or maybe he was less corrupted by decades of normative standards about what "programming" means.

Something about this article was deeply offputting.

This is an ideological question disguised as a technical question disguised as a linguistic question.

As a linguistic question, it depends how you define "programming language". Some people consider anything that tells a computer what to do to be a programming language. Others consider it useful to separate programming languages from markup languages, query languages, assembly languages, scripting languages, etc.

As a technical question, a lot of people jump onto "is it Turing-complete?" Personally, I think Turing-completeness is overrated and kind of a tangent.

Finally, there's the ideological question. Especially on Twitter, similar questions are intended to break down the hierarchy between people who code in C++ or Java and people who write HTML.

What I consider the interesting issue is how spreadsheets have been so successful for solving problems that would otherwise require "programming", and make the power of computers available to a much wider audience. Why haven't more systems caught on that would let people solve problems without "programming"?

In the first semester we had to write a Turing machine. Our profs solution was in excel

I think it would be smarter to ask this question somewhat in reverse; there are apparently lots of important tasks that we're used to think of as "programming" tasks, but are actually done more often, and arguably better, by "spreadsheets."

What can one learn from the other, and/or could we get some kind of singularity here?

> There is no requirement to name things since everything can be referenced by row and column

Ah yes, the joys of absolute memory addressing. How much hair was lost over those details until we figured out that using variables is nice?

It's such a good idea that Excel added named ranges a long time ago.

While I can't argue spreadsheets are a programming language, I would put forward that they are definitely a programming gateway drug for analysts. At least, from my experience, having to easily handle more rows than could be represented in an Excel sheet was what pushed me to SQL and Python. With powerBI and various other data modeling tools, those constraints aren't nearly as vicious as they used to be, but even 10 years ago they were insurmountable in vanilla 32 bit Excel.

I think so. Even microsoft thinks so, if its turing complete.

Excel has VBA so it is certainly so.

How can you argue Excel's implicit typing is an advantage. Names turn to dates, strings to numbers, and all sorts of other unexpected nightmares.

For trained programmers it might be more harm than help, but, for many laypeople, it absolutely is an advantage because it means Excel is automatically allowing them to handle date-like text as actual dates. Most of the time that's helpful.

Unless you are a biologist. Excel is infamous for mangling names of genes and thinking they are dates. In fact some genes had to be renamed because it was considered easier to do that than get Microsoft to fix the problem (or you know, just not use Excel, which many non-programmer types, including many bench biologists, use as a general data holder, akin to an adhoc database)

https://www.theverge.com/2020/8/6/21355674/human-genes-renam...

They are two sides of the same coin.

A spreadsheet has the data visible and the logic behind the scenes. A programming language has the logic visible and the data behind the scenes.

I used to look down on spreadsheets before I served my time at an HPC research institute. I learned there that they have their uses. Even among the most proficient of programmers.

As always; it's all about picking the right tool for the right job.

I'd say yes. Here was a fun and interesting talk I came across recently on homoiconicity and meta-programming in spreadsheets:

https://www.youtube.com/watch?v=U9uZlEqUQw0

Historically there was a view that spreadsheets don’t count as programming because they are not Turing-complete (ignoring VBA). With the addition of Excel’s LAMBDA function, this is no longer true.

I’m not sure you even needed lambda.

There’s a little known feature to enable circular references in Excel. This gives you iterators and recursion.

There are also named references in Excel which the article overlooks in its comparison to “true” programming languages.

I don't have access to ChatGPT4 but has anyone here used it for any kind of Excel troubleshooting? I think it could very helpful since many guides online aren't the best.

I was using the =GOOGLEFINANCE function, which outputs a table, and was having trouble querying Google on how to get Google Sheets to give me just one cell in that table because, like you said, online tutorials aren't the best. Given a descriptive query, ChatGPT was able to tell me to use the INDEX function pretty much immediately.

I would say that spreadsheets are not a programming language, but Excel is (as is Sheets).

a language for programming humans

This commentary is a prime example of the dangers of overgeneralization and a lack of critical thinking. The author argues that spreadsheets are a programming language, but fails to provide a clear definition of what constitutes a programming language. Instead, they rely on vague distinctions between spreadsheets and "traditional programming languages," which they define as having reusable code, a dynamic/automatic structure, and the ability to create sophisticated UI/UX designs.

The author also fails to acknowledge the limitations of spreadsheets as a programming tool. While they briefly mention that spreadsheets are less reusable than traditional code and have limited UI/UX capabilities, they downplay these issues and overemphasize the benefits of using spreadsheets. For example, they argue that spreadsheets are "easier" to use than traditional programming languages, but fail to acknowledge the complexity of learning the unique command line and R1 notation required to use spreadsheets effectively.

Furthermore, the author's argument that spreadsheets should be considered a programming language because they are used by a large number of people is flawed. Just because a tool is widely used does not mean it qualifies as a programming language. By this logic, we could argue that Microsoft Word is a programming language because millions of people use it to write code snippets.

Overall, this commentary lacks critical analysis and relies on unsupported assertions. While spreadsheets may have some programming-like features, they are not a programming language in the traditional sense. The author's argument that spreadsheets should be considered a programming language to increase the number of "programmers" is misguided and ignores the complexity of true programming languages.

It's painfully obvious that this is AI generated.

Both the article and the comment?

Another ChatGPT comment?

Reply on news.ycombinator.com