Excel macros are risky because they offer a kind of privilege escalation. Most Excel built-in functions (that is, what you write into the cells) have limited reach. They impact that cell and (by reference) other cells, but not the underlying filesystem and other things. Even looking at the database ones, I'm not seeing a single function that writes to the DB but plenty that read from it, that's "safe" in that it would be very hard to abuse these kinds of things to screw with other systems or the host system. But macros can run arbitrary code and access whatever the user can access in a way most Excel functions cannot and can trigger arbitrary effects. The equivalent of `rm -r ~/` is not possible in straight Excel, but is feasible with a macro. C and C++ have nothing to do with that, it's the underlying privilege model that permits it.
There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims.
> There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims.
And this idea can be applied to so many things.
Seriously, very often things have enough downsides that you don't need to exaggerate things that are not downsides. You're actually weakening your side by doing so because if people cannot trust even that bit of honesty, why would they trust anything you say?
be trustworthy is the first rule in convincing others.
Broken security model/sandboxing aside (which is inexcusable), the use of C/C++ expands the attack surface - there are some excel exploits though that take advantage of C vulns like buffer overflows: https://www.exploit-db.com/exploits/18087
There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims.