According to Bill Sloman <bill.sloman@ieee.org>:

It's OK if you are an accountant, I guess.

Accountants have to explain what they are doing to other accountants,
and Excel won't let you do anything that is hard to explain. ...

It's hard to belive that anyone who has used Excel would say that. In my experience, any Excel spreadsheet large enough to be interesting has bugs.

Back in the 1980s I worked on a financial modeling package called Javelin.
You could use it for a lot of the financial stuff people do in spreadsheets (Lotus 1-2-3 at the time.) The models were a lot more structured and it
was far easier to audit them and check that they did what you expected.

Users didn't care, they loved their spreadsheets. Best quote: "It's up to my boss to check if my speadsheets are right."

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 31 Jan 2026 23:21:28 -0000 (UTC), John Levine
<johnl@taugh.com> wrote:

According to Bill Sloman <bill.sloman@ieee.org>:

It's OK if you are an accountant, I guess.

Accountants have to explain what they are doing to other accountants,
and Excel won't let you do anything that is hard to explain. ...

It's hard to belive that anyone who has used Excel would say that. In my >experience, any Excel spreadsheet large enough to be interesting has bugs.

Back in the 1980s I worked on a financial modeling package called Javelin. >You could use it for a lot of the financial stuff people do in spreadsheets >(Lotus 1-2-3 at the time.) The models were a lot more structured and it
was far easier to audit them and check that they did what you expected.

Users didn't care, they loved their spreadsheets. Best quote: "It's up to my >boss to check if my speadsheets are right."

Forbes estimates that 88% of spreadsheets contain errors.




John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Oh dear, another example of ineptness triumphing over technical
goodness.

There is a mistaken emphasis on usability and deferred error
checking -- to make "coding" less difficult for the inept.

Even in languages that have scoping rules that allow you to
be more pedantic in defining identifiers, people choose to
ignore them as an expedient.

"The larger the dictionary, the FEWER the number of misspellings
the spell-checker will find!"

Similarly, laziness in deploying invariants lets errors in
*processing* creep into data and persist -- often beyond
the point where they COULD have been noticed!

("This value can't exist here! But, once you get PAST this
point, the code will treat it as valid data...")

The worst misuse (IM) of Excel is in place of a database.
Yet, people seem terrified to NOT be able to see their data
at a glance (really? can you SPOT an error that would merit
its presentation, thusly?)

[I have encountered datasets maintained in excel (and other spreadsheets)
that were horrendously large and impossible to manage. Yet, offering
to restructure the data in a database brings terror to the users...]

I repeatedly complain to an R user which is an Excel user via
quotations like so: "languages like PHP and Mathematica are still
heedless to variable misspellings; [. . .] reversing bad design
decisions, is often impossible once there is a community of users. The shortcomings of Perl, PHP, CSS, JavaScript, etc, are going to persist
[. . .] JavaScript, Perl, PHP, Excel [. . .] having little type
safety" says
Harold Thimbleby, "Heedless programming: ignoring detectable error is
a widespread hazard", "Software: Practice and Experience"

--- PyGate Linux v1.5.10
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <10lmdtj$3cdnh$2@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:

Oh dear, another example of ineptness triumphing over technical
goodness.

There is a mistaken emphasis on usability and deferred error
checking -- to make "coding" less difficult for the inept.

Even in languages that have scoping rules that allow you to
be more pedantic in defining identifiers, people choose to
ignore them as an expedient.

"The larger the dictionary, the FEWER the number of misspellings
the spell-checker will find!"

Similarly, laziness in deploying invariants lets errors in
*processing* creep into data and persist -- often beyond
the point where they COULD have been noticed!

("This value can't exist here! But, once you get PAST this
point, the code will treat it as valid data...")

The worst misuse (IM) of Excel is in place of a database.
Yet, people seem terrified to NOT be able to see their data
at a glance (really? can you SPOT an error that would merit
its presentation, thusly?)

[I have encountered datasets maintained in excel (and other spreadsheets) >that were horrendously large and impossible to manage. Yet, offering
to restructure the data in a database brings terror to the users...]

I have worked for the Rotterdam Harbour. There was a guy there that
had a huge spreadsheet, keeping track of *all* naval vessels
whereabouts.

I worked with a sql database that contains all loading and unloading
used to reconstructed the path of vessels around the harbour.
There was a great surprise, vessels unloaded in the middle of a
an agrarian area. Later I discover that was a placeholder of
docking stations that had disappeared.

I repeatedly complain to an R user which is an Excel user via
quotations like so: "languages like PHP and Mathematica are still
heedless to variable misspellings; [. . .] reversing bad design
decisions, is often impossible once there is a community of users. The
shortcomings of Perl, PHP, CSS, JavaScript, etc, are going to persist
[. . .] JavaScript, Perl, PHP, Excel [. . .] having little type
safety" says
Harold Thimbleby, "Heedless programming: ignoring detectable error is
a widespread hazard", "Software: Practice and Experience"

There is a widespread habit of "casing away" warnings. That is in the same category. Most programs can avoid those. The proper way is to log warnings
with an explanation of why they are not indicative of a mistake.


Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

--- PyGate Linux v1.5.10
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2/1/2026 1:58 PM, albert@spenarnc.xs4all.nl wrote:

In article <10lmdtj$3cdnh$2@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:

Oh dear, another example of ineptness triumphing over technical
goodness.

There is a mistaken emphasis on usability and deferred error
checking -- to make "coding" less difficult for the inept.

Even in languages that have scoping rules that allow you to
be more pedantic in defining identifiers, people choose to
ignore them as an expedient.

"The larger the dictionary, the FEWER the number of misspellings
the spell-checker will find!"

Similarly, laziness in deploying invariants lets errors in
*processing* creep into data and persist -- often beyond
the point where they COULD have been noticed!

("This value can't exist here! But, once you get PAST this
point, the code will treat it as valid data...")

The worst misuse (IM) of Excel is in place of a database.
Yet, people seem terrified to NOT be able to see their data
at a glance (really? can you SPOT an error that would merit
its presentation, thusly?)

[I have encountered datasets maintained in excel (and other spreadsheets)
that were horrendously large and impossible to manage. Yet, offering
to restructure the data in a database brings terror to the users...]

I have worked for the Rotterdam Harbour. There was a guy there that
had a huge spreadsheet, keeping track of *all* naval vessels
whereabouts.

I was offered a contract to design a database to track commercial
properties owned by a large corporation, here. The guy offering
the contract was currently using an /ad hoc/ spreadsheet that was
little more than a giant table (the data in each field having no
actual significance -- but, it looked nice when presented in tabular
form! <rolls eyes>) As he pitched his requirements to me, he made
statements like:
"The first letter can indicate whether it is office space,
lab space or a commercial outlet. The second letter can
indicate the direction of the main entrance. The third letter
can indicate the number of floors. The fourth will indicate
which month the lease is up for renewal -- unless it is not
a leased property -- in which case it will indicate the number
of bathrooms on the premises. The..."
He had actually TRIED to organize his spreadsheet so all similar
criteria were grouped together -- quickly discovering the limits
of two-dimensional space for such an endeavor!

I.e., the typical mindset of the sort of person who just doesn't
"get it" -- let the machine do the remembering so YOU don't have to!

(If you want to be able to identify properties that face east, then
search for "... WHERE door_faces = EAST ...")

In *his* mind, he was almost done -- and just needed someone to
clean up the little details.

I waited to get back home before submitting my "no bid" to his
superior. Obviously the sort of contract that would run on and
on and on and on and... and NEVER see a satisfactory conclusion.
Great if you're looking for a paycheck; not so great if you
value your time!

I worked with a sql database that contains all loading and unloading
used to reconstructed the path of vessels around the harbour.
There was a great surprise, vessels unloaded in the middle of a
an agrarian area. Later I discover that was a placeholder of
docking stations that had disappeared.

Obviously, someone hadn't finished their design task! At the very least, annotating this deficiency.

I once received a notice from a financial institution that they
were required, by law, to withhold a portion of my earnings /because
they did not have my social security number on file/. This despite
the fact that my SSN was printed ON the notification!

Turns out, some idiot had decided "0" would represent "none/nil"
(because their DBMS didn't understand the concept of "BLANK"?).
And, had further implemented the test on the first CHARACTER of
the SSN (9 digits identifiers of the form ###-##-####).

At the time my SSN was issued, the numbers were allocated, in batches,
to geographical areas. So, anyone living near me, at the time, would
also have a SSN of the form 0##-##-####. Ooops!

I repeatedly complain to an R user which is an Excel user via
quotations like so: "languages like PHP and Mathematica are still
heedless to variable misspellings; [. . .] reversing bad design
decisions, is often impossible once there is a community of users. The
shortcomings of Perl, PHP, CSS, JavaScript, etc, are going to persist
[. . .] JavaScript, Perl, PHP, Excel [. . .] having little type
safety" says
Harold Thimbleby, "Heedless programming: ignoring detectable error is
a widespread hazard", "Software: Practice and Experience"

There is a widespread habit of "casing away" warnings. That is in the same category. Most programs can avoid those. The proper way is to log warnings with an explanation of why they are not indicative of a mistake.

Or, rethink how you are approaching the problem and ask yourself if
a better type choice would avoid that scenario.

Some languages will gleefully cast/convert anything to anything else.
Immature developers fail to understand the value of strong typing
and tend to see it as a nuisance.

Like complaining that a program needs an "END" ("It's OBVIOUSLY the end of
the program/file... why do I have to explicitly state that??? How stupid...")

Or, using REALs for every variable.

I hold "hungarian notation" in particular disdain. It complicates naming
and opens up opportunities for a lazy developer to leave an "old" name
in place that no longer is conforming.

I also roll my eyes at how often folks fail to handle integer overflow
(esp in address arithmetic). As if they were dealing with actual "numbers" where such an occurrence is not possible.

--- PyGate Linux v1.5.10
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)