I like the programmers on here telling the professional users that Excel is overblown and they could just use Numbers, OpenOffice or Google sheets.

Imagine an accountant coming on here and telling you that you don't need vi, emacs, sublime text or VSCode. You certainly don't need your IDEs. After all it's perfectly possible to code in Notepad.

You also don't need your languages. BASIC was perfectly good.

The killer feature of Excel for financial modelling, over 'proper' software, databases etc is portability and auditability.

Everything I do at work is subject to external audit. Every audit firm in the world has Excel. The tax advisors have Excel too, as to the tax authorities. Apprentices are trained in Excel. The people I hire may not have used our ERP, but they have all used Excel. It is the one constant in our world. The actual accounting records are in an ERP, but all of the outputs are in Excel. I have worked at several multinationals and several SMEs. Excel was everywhere.

Those feelings are nice, but Excel in most context is just a liability. The intersection where a spreadsheet is the right tool for the job, and the job is performed by someone who doesn't have many options is pretty small.

In business cases, the risk with home grown spreadsheet 'workflows' is pretty big, and in home usage cases you don't really need more than just a basic spreadsheet. The intersection is perhaps where you have some offline data, cannot write a program as fast as you can use a spreadsheet and there is no risk associated with taking the data and workflow out of a guarded environment.

The same can be said for things like word processing, when you need a book or a paper, you might be in need of typesetting rather than a program that tries to do everything but at a level a novice can use it. You're not going to get a paper or an offset printed book from a text editor. Perhaps if you self-publish a PDF that doesn't need to meet any requirements you can get away with an all-in-one DIY solution. But the time period where that was relevant (around the late 90's) has come and gone.

Let's not stop there, the same can be applied to someone doing some Apps Script, Python notebooks or other solo yolo work, because it felt faster or more productive to them. Surprise! Your cowboy behaviour doesn't actually work at scale, doesn't fit in a shared system and doesn't work in production. But you wanted to be quick and 'get it done'. Instead you waste your own time and everyone else's time, and didn't deliver something that works. (at work; and that includes "but I have done it this way for 1000 years! - doing it wrong a lot doesn't make it less wrong)

But say you want to do some budgeting at home, and all you need is some boxes to type numbers in, then yes, why not use a spreadsheet. But that's not what people celebrate. People celebrate running a company with 100's of jobs on a single spreadsheet, and probably only because it hasn't gone horribly wrong yet. And then there's the real bad scenario, a specialised system (say, an ERP or PIM or CMS) where you pull the data out, do the thing in excel because you didn't want to learn how to use the system and you happen to have written some lists of numbers in excel once and therefore it is now your universal hammer. Good for you, bad for your department or entire business unit because you just broke out of a shared workflow because you thought you knew better which tends to have universally bad consequences.

Excel specifically is an example of "they just don't know any better", just like the everything-is-a-nail example (where Excel is the hammer and every problem looks like a spreadsheet). You could replace Excel with something else and it would still be the same problem (i.e. replacing Excel with Word in scenarios where people want to send someone an image that is on their clipboard - they know they can paste it in Word, so that is what they do and you on the receiving end get a grainy compressed image in a word document). It's not that the sending and receiving didn't work at all, or that the software or the people are bad, it's just a really shitty "solution" that shouldn't be glorified and be seen as the failure to educate that it is.

You can enjoy it as much as you want on your own time. That doesn't make it the great universal fit you think it is.

I think you misunderstand 'workflows' in business. This is not a case of ingesting a large amount of data, transform, analyse etc.

A normal finance team gets constant one off requests for information. Download something from the ERP, lookup against something else, pivot it by department. Then you get a follow up for the same but with x excluded, but they need it in 10 minutes before a meeting. Excel is great for that.

Then there are the dozens of files behind accounting records. Take a Fixed Asset Register (since it is at the top of the balance sheet), a list of your assets and their depreciation schedule. Maybe your ERP doesn't have one, or your company didn't buy that module, or you have a special class off asset that doesn't fit in it. Maybe they coded it for one country, but in your country the rules are different, so it ends up in Excel.

Then maybe you have a bank account and you have cheques that are posted to your ledger but have not cleared the actual bank yet. Then you have items on your real account that you couldn't post yet, maybe someone paid you with no reference. So you keep a little Excel reconciliation to check.

Then inventory, maybe the ERP didn't split it in the way your consolidation needs it, so you transform the data in Excel and reconcile it back

Then you have all the things that belong in this accounting period but haven't been billed yet, so you have a running list of accruals and when they will reverse. Then you have all the things that are posted in this period but relate to later periods, so you keep a prepayments file. Maybe both of these spit out a journal to upload back to the ERP and reconcile the balance.

Then you get a download of the payroll for the month, but you need to rearrange it into net pay, gross pay, taxes paid by the employee, taxes paid by the employer, pension contributions... then you have to split it by cost centre too. This could be coded, but it is different in every country... and the cost centres keep changing, and the analysis head office wants keeps changing... so it goes in Excel.

Then I want to verify that the system posted the correct absorption to inventory, so I paste in an inventory report and a TB and last month's reconciliation updates.

I can code, but I can't maintain 100 pieces of software that change all the time. I also need all the people in the chain to be able to follow it....

And yes, finance people know how to apply the famous 'checks and balances' to keep out most classes of mistakes....and to detect the same mistakes made by the engineered 'proper software' we have to work

I doubt I misunderstand it since this is what I get paid for. I'm also not suggesting this is a case of large data, ETL or anything like that. (what I'm writing about is people using it for that anyway which is what we have other systems for and they should not be doing that)

Our finance teams use excel too, but not as the 'do everything' tool that the article and plenty of comments here makes it out to be. They use it as a scratchpad, and it works well. But it doesn't contain ground truth, ever.

This one perhaps matches with 99% of the rant I wrote:

Then inventory, maybe the ERP didn't split it in the way your consolidation needs it, so you transform the data in Excel and reconcile it back

While we primarily deal with Dynamics (AX and 365), pretty much everything fits in there. In some cases the clunky UI makes it slow to do some transformations, even if just to check something to (as you wrote, verify the software did what it was supposed to do), and then you dump a couple of thousand rows out, do your work, and either are happy with what was verified or load some transformed data back in (this hasn't really been needed as we revised our rules as to data locations a few years ago, not in terms of "do this or you get fired" but in terms of "please make sure that when external systems outside of your team streams data in or out of the ERP, the chance of it not being correct is as low as you can get it").

As I wrote in some other reply (which some people appear to disagree with as if it's something I made up), my issue is with the horror cases of people building their own mini-ERP in a set of excel workbooks, or not using shared systems for data sharing and governance but instead emailing files around. Maybe it's the little learning being a dangerous thing, or feeling confident in a tool also giving people false confidence to perform actions that really should not be done that way.

Write a piece of software that ends Excel's dominance and then I will take your opinion seriously.

I hate Excel for many reasons but it is king for a reason.

Excel is king of cancer that you'll implore to cut out once you realize it slowly kills your business. A perfect trap for novice entrepreneurs.

30% of my jobs when I was in integration was unfricking folders of folders of irregular xls built by users, and sometimes we just failed due to the sheer amount of crap which was in motion and had to be transitioned atomically. It never worked first and second time, so we had to do waves of complex transitions with parallel accounting (double workload on an already suffocating business), until things failed rarely enough to be scheduled as regular bug fixing tasks.

There's more in the thread. Mildly amusing if you enjoy galaxy brains trying to out-smug each other.

https://hackaday.com/2024/11/01/apple-forces-the-signing-of-applications-in-macos-sequoia-15-1/

!codecels

I'm looking to get into video editing and I don't think I need all that much. These would be simple shitposts of static images and crude MS paint drawings. I'm not even talking about animation, just one frame after the other. I would like to add gifs, music, voice recordings, and sound effects though.

I'm hoping for something simple that my average performance laptop could run. And also for something free

"The development of new product lines for use in service of critical infrastructure or [national critical functions] NCFs in a memory-unsafe language (e.g., C or C++) where there are readily available alternative memory-safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety," the report says.

"Putting all new code aside, fortunately, neither this document nor the U.S. government is calling for an immediate migration from C/C++ to Rust — as but one example," he said. "CISA's Secure by Design document recognizes that software maintainers simply cannot migrate their code bases en masse like that."

But for all new code, bros it's ogre.

"For existing products that are written in memory-unsafe languages, not having a published memory safety roadmap by Jan. 1, 2026, is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety," the report said.

It's ogre.