[mlatu]

> Excel is powerful, but it’s not easy to learn. It only seems that way to people who already know how it works.

this right there.

except, it IS easy to learn actually. it's visual, you can click around and find out. if you forget the spelling of some formula, no probs, there is a help button.

the interface is what makes it easier, markdown is also an interface. except it's not AS exposed to the user as excel is.

people dont want to read manuals or consult documentation, they want to hit the ground running.

[crdrost]

Yeah, I want to emphasize those aspects.

• Excel is based on a simpler model of computation, something like the unification ideas in logic programming, state is not named and minimally expressive, etc. You want a looping construct? Better autofill a column or something!

• Excel automatically includes printf-style debugging of every object in the system; that is the default state of the system and you have to hide columns you don't want to see.

• Excel has no compilation or run step. The document is living and when you change things you immediately see the results of that change.

This means that the programming model in Excel becomes much more amenable to the results-oriented mind. Decide on an incremental goal, then calculate a bunch of results “the long way” and then massage the formula until it gives a result that matches your manual calculations. Repeat as desired.

It's like clay, basically. You sculpt it to look right and then you sculpt the next piece to build on that and so on.

[ryanjshaw]

One additional point: since Excel packages the code with the data, when somebody sends me a spreadsheet with functionality I've never seen before it's extremely easy to figure out what they did and learn on the job. This is also why Jupyter notebooks are so powerful.

If instead of Excel they run a bunch of scripts and just send me the output, I am left much less empowered.

[kwhitefoot]

> when somebody sends me a spreadsheet with functionality I've never seen before it's extremely easy to figure out what they did a

You must have encountered only very simple spreadsheets. I've had to reverse engineer a number of technical spreadsheets that took days of full time sweated effort to merely understand the principles and more days again to extract the methods accurately enough so that they could be reimplemented in a programming language.

[feoren]

Think about how much harder it would be if you couldn't see the inputs, code, and outputs all together at once. The difficulty you found has little to do with Excel; you were trying to learn a whole new domain by reverse-engineering a model created by an SME. Of course it took multiple days of effort to merely(!?) "understand the principles" of a brand new technical domain. Ideally the SME should be explaining those things to you as well.

[mlatu]

> The difficulty you found has little to do with Excel;

i claim, if you allowed access to an underlying source code representation of the spreadsheet, or rather, if you made that transformation at all, you could easily add symbols and labels to transform an excel sheet into something a programmer could turn into a binary but i doubt that step inbetween is desired

I mean, the activity of analyzing an excel spreadsheet is more akin to learning where all the items in your favourite point and click adventure is and in what order to get them where, than to actually analyzing a problem

[listenallyall]

When you've done that, is it all of a sudden super-simple? You've had to incorporate all the same complexity into your model. If you sent it back to a spreadsheet user, don't you think they would say the same thing, just backwards?: "I had to reverse engineer a number of technical data processes in R that took days merely to understand the principles..."

[kwhitefoot]

Perhaps not super simple but it will have been broken down into named parts. In the days before spreadsheets were as capable as they are now I worked with plenty of quite old engineers who would write Fortran instead; their Fortran was always better than the spreadsheets that they later produced.

[listenallyall]

The degree something is well-designed and comprehensible is based mostly on the developer, not the tool. A spreadsheet with named ranges/tables, cell comments (sparsely, where necessary), clearly-defined tabs, etc can make debugging or reverse-engineering a breeze. The visual aspect of Excel can also help debugging immensely, i.e. conditional formatting of cells failing validation, filtering to isolate subsets of data, etc.

I will certainly agree that it is quite rare to come across a spreadsheet that is perfectly-organized, on the other hand a ton of developers write horrible spaghetti-code too. Further, a 10+ year-old spreadsheet will open right up in Excel... while a 10+ year-old data project is often written in a language you've never used before (or hoped you'd never use again).

[jabroni_salad]

That pt 3 is actually something I really like in Office. It isn't just instant, you can see changes live as you mouse over different options. I also really like the search tool that lets you just type what feature you are looking for. I have no idea where the 'new pivot table' button is and I don't care, I can just search it instead of hunting through menus.

[mlatu]

as much as i hate microsoft, excel endearingly excels expectations...

[MrPatan]

Ima stop you right there and ask how you made the bullet points.

• Is it just a pasted character?

* Is it a markdown thing? * Is it?

[dbalatero]

You can tell it's a character because the wrapped lines don't indent & align like a real bullet list.

[crdrost]

I was on my mobile, I think the keyboard is Gboard, you have a symbol keyboard with two pages and the second page has the bullet.

Also if I long press on the bullet I can choose among •♣♠♪♥♦, which I find to be a hilarious random assortment...

[asddubs]

it's a character

[pxc]

> except, it IS easy to learn actually. it's visual, you can click around and find out.

That's not easy at all. I am an actual Excel 2007+ virgin. I switched to OpenOffice (there was no Libreoffice yet; Oracle had not yet bought Sun) before high school. Before I finished university, I abandoned all traditional office tools in favor of open-source tools that use entirely different paradigms from Microsoft Office, e.g., Word -> Lyx/LaTeX, PowerPoint -> Org-beamer, Excel -> R. I didn't even use traditional Office tools when they were 'required' by class, instead explaining my commitments to the instructors and teaching myself the open-source alternatives as I went.

For the first ~5 years of my career, I was at startups where I didn't need to use Microsoft Office or even tools in that category.

So within the past year, I started dabbling in Excel for my job, when the last version of Excel I even messed around with was Excel 2003, pre-ribbon menu, in junior high.

And as a developer who is approaching contemporary Excel from a position that is actually pretty close to a blank slate in terms of experience with it... I am here to tell you that this

> [Excel] IS easy to learn actually

is false. You are almost certainly discounting experience people have gradually acquired with Excel in school and over the course of a career. This isn't just evident with oddball developers like me who wanted to and managed to avoid Excel for most of our careers so far. It's also perfectly evident in baby boomers who grew up without Excel and need assistance for basic tasks, and increasingly in zoomers who, like those two generations before them and earlier, have grown up without being trained on office software in schools.

Which takes us back to GP's statement:

> > Excel is powerful, but it’s not easy to learn. It only seems that way to people who already know how it works.

Moreover, these statements

> if you forget the spelling of some formula, no probs, there is a help button.

> people dont want to read manuals or consult documentation

contradict each other. So do the following two, in a slightly less direct way.

> it's visual, you can click around and find out

> they want to hit the ground running

Pressing the help button is reading the documentation, just as much as running `q --help` or whatever.

And anybody who is visually exploring a GUI with as many buttons and menus as Excel's is absolutely crawling, not running. Visually scanning an overloaded, totally new-to-you graphical interface is slow, slow, slow.

When I've been driving Excel on video calls with colleagues during working sessions (specifically for the purpose of learning it), I can practically hear the veins on their foreheads bulging as I fumble around.

Searching with your eyes, especially when some options are hidden behind additional clicks as they are on ribbon menus, is so unbelievably slow compared to searching through a comprehensive manual by typing a couple of words.

[feoren]

Complicated tools are hard to learn. There's no general fix to this. The only way to make complicated tools easier to learn is to watch a bunch of different people try to learn them and tweak little details based on what you see. In Excel 2003, Microsoft had 20 years of doing this. When they moved to the "ribbon" in 2007, they threw a lot of that learning away. So you're right that the ribbon makes Excel harder to learn than it needs to be.

But I reject the idea that visual GUIs are inherently more difficult to learn than non-visual interfaces; everything we've ever seen in the history of software suggests the opposite.

> Searching with your eyes, especially when some options are hidden behind additional clicks as they are on ribbon menus, is so unbelievably slow compared to searching through a comprehensive manual by typing a couple of words

Typing which words!? You're already assuming the user has a pretty strong understanding of the software if they know which words to search for. This is not a fair comparison with opening a brand new GUI for the first time.

Think of the difference between walking into a restaurant and having the waiter hand you a big menu with lots of pictures, vs. standing there and asking "What do you want?" ... um, I don't know, what do you have!? The latter is how it feels for new users to be presented with "> _".

[pxc]

> Think of the difference between walking into a restaurant and having the waiter hand you a big menu with lots of pictures.

The useful part of the menu is the text! Especially if I'm somewhere with novel or unfamiliar food, there's no way I can guess what actually went into a cooked dish or what its texture is like by looking at pictures of it. But all of that I can infer from a reasonable description of the dish given in terms of its ingredients and how it is cooked.

But if the waiter asks 'what do you want', that is indeed an offer for them to search on my behalf much more efficiently than I could do visually through a menu! I'm free to say 'something savory and salty' and see what they offer me, or ask 'what chicken dishes do you have?', or 'I need something light, because I'm not very hungry'.

Even in the example you chose, visually scanning a menu is less efficient and more restrictive!

> how it feels for new users to be presented with "> _".

Of course a shell prompt is not self-explanatory, because you have to learn the commands for asking about other commands.

But there's also no reason that accessing the command line for the very first time has to mean being dropped at a blank prompt with no instructions. That's completely inessential to the paradigm, and it's unfortunate that this is such a common default.

> Typing which words!? You're already assuming the user has a pretty strong understanding of the software if they know which words to search for. This is not a fair comparison with opening a brand new GUI for the first time.

Sure it is. I do this with commands I've never used or use very rarely all the time. In the worst case you try a few synonyms and words for related concepts and find what you're looking that way.

You're also not making a 1:1 comparison here. One may need some basic instruction on the command line environment itself, e.g., how to search for and open documentation at the command line. But that is not part of the process of learning to use a new command line application. You're comparing the cost of learning a single application to the cost of learning an entire paradigm and environment.

> But I reject the idea that visual GUIs are inherently more difficult to learn than non-visual interfaces; everything we've ever seen in the history of software suggests the opposite.

What volume of research has ever even investigated command line usability and how it can be improved? Where has that research been applied? How much of it focuses on applications/domains which are comparable in complexity to an absolute behemoth like Excel?

Consider the part of this discussion that has focused on developers who are hesitant to use the command line. Is there seriously any reason that a text-driven environment navigated non-spatially, through search/filtering, should be any harder to use than an IDE, like those same developers use every day?

----

I also wanna be clear that I'm not saying that Excel's non-obviousness is a fatal flaw, or that people who are effective with it should switch to something else. Excel is actually an impressive, capable piece of software.

I'm also not saying that most command line environments as they exist do a good job of being easy to jump into. They generally don't! I think the command line has long been largely neglected in terms of UX, and it shows.

But the way CLI environments lend themselves to searching, filtering, composition, and reusing old actions but slightly modifying them also make searching for, picking up, and using new command line programs really smooth and fast in a way that I think most of us don't give enough credit.