On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
> On 1/28/2023 10:39 PM, Dave Froble wrote:
>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> One of the absolute FIRST things that I was told about floating point
>>> variables in my first programming class was to NEVER use them to represent
>>> money.
>>
>> What if you didn't have a choice?
>>
>> RSTS/E V04b
>>
>> Signed word integers
>> Strings
>> Single and double D-float
>>
>> That's all there was ...
>
> There is always integers and implied decimal.
>
> Not fun though.
>
> And one need an integer with enough bits ...
>
> Could PDP-11 do 32 bit integers?
>
> Arne

What part of "signed word integers" didn't you understand? As in 16 bits.
-32768 to 32767.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Dave Froble <davef@tsoft-inc.com> wrote:
>On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>> Consider the case where the numbers represent money.
>>>>>>
>>>>>> Who cares what the numbers represent? For example, if you round to
>>
>> One of the absolute FIRST things that I was told about floating point
>> variables in my first programming class was to NEVER use them to represent
>> money.
>
>What if you didn't have a choice?
>
>RSTS/E V04b
>
>Signed word integers
>Strings
>Single and double D-float
>
>That's all there was ...

Signed integers are fine. Read and write with a . added before the last two
digits, so the integer contains cents. That was very common practice.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Scott Dorsey <kludge@panix.com> wrote:
>
>Signed integers are fine. Read and write with a . added before the last two
>digits, so the integer contains cents. That was very common practice.

Other workarounds people have used over the years include keeping dollars and
cents as two diferent integers, and strings or integer arrays used to store
BCD or ascii numbers. That latter is very handy when you're asked to deal
with trillions of dollars and don't have BCD types available.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1/29/2023 1:21 AM, Dave Froble wrote:
> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>> On 1/28/2023 10:39 PM, Dave Froble wrote:
>>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>> One of the absolute FIRST things that I was told about floating point
>>>> variables in my first programming class was to NEVER use them to
>>>> represent
>>>> money.
>>>
>>> What if you didn't have a choice?
>>>
>>> RSTS/E V04b
>>>
>>> Signed word integers
>>> Strings
>>> Single and double D-float
>>>
>>> That's all there was ...
>>
>> There is always integers and implied decimal.
>>
>> Not fun though.
>>
>> And one need an integer with enough bits ...
>>
>> Could PDP-11 do 32 bit integers?
>
> What part of "signed word integers" didn't you understand?  As in 16
> bits. -32768 to 32767.

I sort of had guessed that word was the same as on VAX,
but I don't understand how it can't have a 32 bit integer.

How does one work with file sizes and file position
in bytes on PDP-11?

I know you don't do C, but I believe C was invented on
PDP-11.

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>
>I sort of had guessed that word was the same as on VAX,
>but I don't understand how it can't have a 32 bit integer.
>
>How does one work with file sizes and file position
>in bytes on PDP-11?
>
>I know you don't do C, but I believe C was invented on
>PDP-11.

I think the issue is with the programming language and not with the
architecture. And yes, you can use bignum in C, at least under v7 Unix,
and store really really big numbers.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1/28/2023 8:39 PM, Arne Vajhøj wrote:
> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>> Consider the case where the numbers represent money.
>>>>>>
>>>>>>      Who cares what the numbers represent?  For example, if you
>>>>>> round to
>>
>> One of the absolute FIRST things that I was told about floating point
>> variables in my first programming class was to NEVER use them to
>> represent
>> money.
>
> It is known to be problematic.
>
> But there are 3 cases where it happens anyway:
> - the developer does not care

Wrong developer

> - the language used does not have a decimal type and
>   integers with implied decimal is considered to
>   cumbersome

Wrong language for the job

> - decimal is actually used in general, but certain
>   calculations temporarily move over in floating
>   point (like some interest calculations)

Wrong language for the job

Obviously, all of these can be fixed properly. Guess the concepts of
right tool for the job and due diligence no longer carry any sway.

bill

On 2023-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/29/2023 1:21 AM, Dave Froble wrote:
>> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>>> On 1/28/2023 10:39 PM, Dave Froble wrote:
>>>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>>> One of the absolute FIRST things that I was told about floating point
>>>>> variables in my first programming class was to NEVER use them to
>>>>> represent
>>>>> money.
>>>>
>>>> What if you didn't have a choice?
>>>>
>>>> RSTS/E V04b
>>>>
>>>> Signed word integers
>>>> Strings
>>>> Single and double D-float
>>>>
>>>> That's all there was ...
>>>
>>> There is always integers and implied decimal.
>>>
>>> Not fun though.
>>>
>>> And one need an integer with enough bits ...
>>>
>>> Could PDP-11 do 32 bit integers?
>>
>> What part of "signed word integers" didn't you understand?  As in 16
>> bits. -32768 to 32767.
>
> I sort of had guessed that word was the same as on VAX,
> but I don't understand how it can't have a 32 bit integer.
>
> How does one work with file sizes and file position
> in bytes on PDP-11?
>

The same way as it's done with a block-based filesystem (ODS-2) on VMS.

In general, the 16-bit nature of the PDP-11 is reflected in the API.

Ever worked with real-mode MS-DOS at assembly language level ?

It's the same kind of thing.

> I know you don't do C, but I believe C was invented on
> PDP-11.
>

What makes you think that "int" in C is _always_ at least 32 bits ? :-)

There's a reason why both int and long int have always existed in C.

And on architectures that do not support 32-bit ints, then long int is
a library/RTL feature implemented by the language in the same way as
64-bit long long int is implemented by the language RTL on 32-bit
architectures.

Also, most languages on RSTS/E intended for commercial data processing
also supported a decimal datatype, which was implemented by the language's
RTL. It seems early RSTS/E Basic wasn't one of them however, based on
what David is saying.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/28/2023 10:39 PM, Dave Froble wrote:
> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>> Consider the case where the numbers represent money.
>>>>>>
>>>>>>     Who cares what the numbers represent?  For example, if you
>>>>>> round to
>>
>> One of the absolute FIRST things that I was told about floating point
>> variables in my first programming class was to NEVER use them to
>> represent
>> money.
>> --scott
>>
>
> What if you didn't have a choice?
>
> RSTS/E V04b
>
> Signed word integers
> Strings
> Single and double D-float
>
> That's all there was ...
>

No COBOL? Sad as it sounds if RSTS BASIC was the only language
on the machine (I am pretty sure it was not) then one would have
to write routines, no matter how inefficient and time consuming,
to do the job right. But floating point for money is never the
right answer.

bill

On 2023-01-28, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> I find it hard to see why one would bother with the risks
> of using floating point if a decimal type is available.
>
> VMS Basic has a decimal type.
>

Did RSTS/E Basic ever get a decimal data type, and if so, when ?

PDP-11 DIBOL had a decimal data type, but I don't know when DIBOL
was introduced to the PDP-11 (ie: was it _after_ David started
using RSTS/E Basic ?)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-01-29, bill <bill.gunshannon@gmail.com> wrote:
> On 1/28/2023 10:39 PM, Dave Froble wrote:
>>
>> What if you didn't have a choice?
>>
>> RSTS/E V04b
>>
>> Signed word integers
>> Strings
>> Single and double D-float
>>
>> That's all there was ...
>>
>
> No COBOL? Sad as it sounds if RSTS BASIC was the only language
> on the machine (I am pretty sure it was not) then one would have
> to write routines, no matter how inefficient and time consuming,
> to do the job right. But floating point for money is never the
> right answer.
>

Same question as for PDP-11 DIBOL: when did COBOL arrive on RSTS/E
and was it after David started implementing his application on RSTS/E ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/29/2023 9:51 AM, Simon Clubley wrote:
> On 2023-01-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/29/2023 1:21 AM, Dave Froble wrote:
>>> On 1/28/2023 10:44 PM, Arne Vajhøj wrote:
>>>> And one need an integer with enough bits ...
>>>>
>>>> Could PDP-11 do 32 bit integers?
>>>
>>> What part of "signed word integers" didn't you understand?  As in 16
>>> bits. -32768 to 32767.
>>
>> I sort of had guessed that word was the same as on VAX,
>> but I don't understand how it can't have a 32 bit integer.
>>
>> How does one work with file sizes and file position
>> in bytes on PDP-11?
>
> The same way as it's done with a block-based filesystem (ODS-2) on VMS.
>
> In general, the 16-bit nature of the PDP-11 is reflected in the API.
>
> Ever worked with real-mode MS-DOS at assembly language level ?
>
> It's the same kind of thing.

Compilers on 16 bit MS-DOS did support 32 bit integers.

So a compiler on 16 bit PDP-11 some OS could potentially as well.

>> I know you don't do C, but I believe C was invented on
>> PDP-11.
>
> What makes you think that "int" in C is _always_ at least 32 bits ? :-)

I don't.

The point is that there are some C IO routines that operate on
byte offset. No integer type bigger than 16 bit seems like a huge
problem.

> There's a reason why both int and long int have always existed in C.
>
> And on architectures that do not support 32-bit ints, then long int is
> a library/RTL feature implemented by the language in the same way as
> 64-bit long long int is implemented by the language RTL on 32-bit
> architectures.

For add and sub it does not even need a RTL routine if it has
"with carry" instructions.

It is absolutely possible.

But per Dave at least Basic chose not to support it. And I wonder.

Arne

On 1/29/2023 9:32 AM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>
>> I sort of had guessed that word was the same as on VAX,
>> but I don't understand how it can't have a 32 bit integer.
>>
>> How does one work with file sizes and file position
>> in bytes on PDP-11?
>>
>> I know you don't do C, but I believe C was invented on
>> PDP-11.
>
> I think the issue is with the programming language and not with the
> architecture. And yes, you can use bignum in C, at least under v7 Unix,
> and store really really big numbers.

So other language & OS combinations did support 32 bit
integers on PDP-11?

Possible including first version of C.

Arne

On 1/29/2023 10:42 AM, Arne Vajhøj wrote:
> On 1/29/2023 9:32 AM, Scott Dorsey wrote:
>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>>
>>> I sort of had guessed that word was the same as on VAX,
>>> but I don't understand how it can't have a 32 bit integer.
>>>
>>> How does one work with file sizes and file position
>>> in bytes on PDP-11?
>>>
>>> I know you don't do C, but I believe C was invented on
>>> PDP-11.
>>
>> I think the issue is with the programming language and not with the
>> architecture. And yes, you can use bignum in C, at least under v7 Unix,
>> and store really really big numbers.
>
> So other language & OS combinations did support 32 bit
> integers on PDP-11?
>
> Possible including first version of C.
>
> Arne
>
>

When was C first available?

The problem was, in 1974, we had RSTS/E and Basic+ on PDP-11. That was what was
available. Sure, in later years, there were more options. As far as that goes,
we developed what we called "double integer", which was two word integers, used
in memory as D-float, and stored as a 4 byte string. 6 variations gave us whole
integers, and 5 variations with 1 to 5 digits after the decimal point. The max
values were still limited to I believe 8 digits.

What was developed worked. Later, when discussing with customers the choice of
using newer capabilities, they asked, "what's the benefit" and actually what
they had was working. They were not interested in paying to replace something
that was working for them. There was also the issue of running the programs on
historical data saved on tape. They were not interested in converting the
historical data.

And so the old capabilities remained in use, and they did the job. They are
still doing the job.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

bill <bill.gunshannon@gmail.com> wrote:
>
>> - the language used does not have a decimal type and
>>   integers with implied decimal is considered to
>>   cumbersome
>
>Wrong language for the job

You go to war with the army you have, not the army you want.

I wrote an LL(R) parser in Fortran once, and a fourier transform in COBOL
because that's what there was on the machines I had at the time. Both
were excruciating but I got paid so it was okay.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>On 1/29/2023 9:32 AM, Scott Dorsey wrote:
>>
>> I think the issue is with the programming language and not with the
>> architecture. And yes, you can use bignum in C, at least under v7 Unix,
>> and store really really big numbers.
>
>So other language & OS combinations did support 32 bit
>integers on PDP-11?

That's not an integer, that's a long. And yes, many languages supported
longints on pdp-11s.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Dave Froble <davef@tsoft-inc.com> wrote:
>
>When was C first available?

On RSTS/E? Probably about 1980 with Whitesmith C. Maybe a couple years
earlier... I know their RT-11 C became available in 1978 and it was a real C.
I have a Comdex flyer for it hanging outside my office.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1/29/2023 8:16 AM, Scott Dorsey wrote:
> Scott Dorsey <kludge@panix.com> wrote:
>>
>> Signed integers are fine. Read and write with a . added before the last two
>> digits, so the integer contains cents. That was very common practice.
>
> Other workarounds people have used over the years include keeping dollars and
> cents as two diferent integers, and strings or integer arrays used to store
> BCD or ascii numbers. That latter is very handy when you're asked to deal
> with trillions of dollars and don't have BCD types available.
> --scott
>

Yes, there can be library routines to do some things, but, when the in memory
data types are limited, you either build some hard to use capabilities, if even
possible, or, you use floating point in memory.

Trillions of dollars were never an issue. At least for what we were doing.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/29/2023 9:54 AM, bill wrote:
> On 1/28/2023 10:39 PM, Dave Froble wrote:
>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>>> Consider the case where the numbers represent money.
>>>>>>>
>>>>>>> Who cares what the numbers represent? For example, if you round to
>>>
>>> One of the absolute FIRST things that I was told about floating point
>>> variables in my first programming class was to NEVER use them to represent
>>> money.
>>> --scott
>>>
>>
>> What if you didn't have a choice?
>>
>> RSTS/E V04b
>>
>> Signed word integers
>> Strings
>> Single and double D-float
>>
>> That's all there was ...
>>
>
> No COBOL? Sad as it sounds if RSTS BASIC was the only language
> on the machine (I am pretty sure it was not) then one would have
> to write routines, no matter how inefficient and time consuming,
> to do the job right. But floating point for money is never the
> right answer.
>
> bill
>

I have to wonder why some people continue to argue with success?

No, the only language available on RSTS/E, at that time, was Basic+. Much more
was added later using the RSX stuff under RSTS/E. But not in 1974.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/29/2023 9:57 AM, Simon Clubley wrote:
> On 2023-01-28, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> I find it hard to see why one would bother with the risks
>> of using floating point if a decimal type is available.
>>
>> VMS Basic has a decimal type.
>>
>
> Did RSTS/E Basic ever get a decimal data type, and if so, when ?
>
> PDP-11 DIBOL had a decimal data type, but I don't know when DIBOL
> was introduced to the PDP-11 (ie: was it _after_ David started
> using RSTS/E Basic ?)
>
> Simon.
>

I believe DIBOL was on the PDP-8. I don't know when or how it got on the PDP-11.

What I think might be interesting is, the people working on RSTS/E back in the
1970s probably aren't around to tell others just how primitive things were.
Seems some here are having a hard time imagining that.

Once VAX Basic was available, many things were added to the language. I guess
some things that are causing John grief. The thing is, once one starts down a
particular road, it's hard to change, and if things are working, no good reason
to change.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/29/2023 9:49 AM, bill wrote:
> On 1/28/2023 8:39 PM, Arne Vajhøj wrote:
>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>>> On 1/28/2023 6:19 PM, Johnny Billquist wrote:
>>>>> On 2023-01-28 23:35, Arne Vajhøj wrote:
>>>>>> On 1/28/2023 3:01 PM, Steven Schweda wrote:
>>>>>>>> Consider the case where the numbers represent money.
>>>>>>>
>>>>>>> Who cares what the numbers represent? For example, if you round to
>>>
>>> One of the absolute FIRST things that I was told about floating point
>>> variables in my first programming class was to NEVER use them to represent
>>> money.
>>
>> It is known to be problematic.
>>
>> But there are 3 cases where it happens anyway:
>> - the developer does not care
>
> Wrong developer
>
>> - the language used does not have a decimal type and
>> integers with implied decimal is considered to
>> cumbersome
>
> Wrong language for the job
>
>> - decimal is actually used in general, but certain
>> calculations temporarily move over in floating
>> point (like some interest calculations)
>
> Wrong language for the job
>
> Obviously, all of these can be fixed properly. Guess the concepts of
> right tool for the job and due diligence no longer carry any sway.
>
> bill
>
>

Must be nice to always be right. Even nicer when one doesn't know what one is
talking about.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Dave Froble <davef@tsoft-inc.com> wrote:
>
>Trillions of dollars were never an issue. At least for what we were doing.

It's a serious problem in many countries with out-of-control inflation.
My grandfather told me about how when he was a child in Italy, everyone
was a millionaire. "Even the wino on the street was a millionaire!" It
was a few years before I realized that this was not an indication that
the streets were paved with gold.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Dave Froble <davef@tsoft-inc.com> wrote:
>
>What I think might be interesting is, the people working on RSTS/E back in the
>1970s probably aren't around to tell others just how primitive things were.
>Seems some here are having a hard time imagining that.

I had a hard time imagining it in the seventies, so I completely understand.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1/29/2023 11:52 AM, Dave Froble wrote:
> On 1/29/2023 10:42 AM, Arne Vajhøj wrote:
>> On 1/29/2023 9:32 AM, Scott Dorsey wrote:
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?=  <arne@vajhoej.dk> wrote:
>>>>
>>>> I sort of had guessed that word was the same as on VAX,
>>>> but I don't understand how it can't have a 32 bit integer.
>>>>
>>>> How does one work with file sizes and file position
>>>> in bytes on PDP-11?
>>>>
>>>> I know you don't do C, but I believe C was invented on
>>>> PDP-11.
>>>
>>> I think the issue is with the programming language and not with the
>>> architecture.  And yes, you can use bignum in C, at least under v7 Unix,
>>> and store really really big numbers.
>>
>> So other language & OS combinations did support 32 bit
>> integers on PDP-11?
>>
>> Possible including first version of C.
>
> When was C first available?

1972, Version 2 Unix, PDP-11.

> The problem was, in 1974, we had RSTS/E and Basic+ on PDP-11.  That was
> what was available.  Sure, in later years, there were more options.  As
> far as that goes, we developed what we called "double integer", which
> was two word integers, used in memory as D-float, and stored as a 4 byte
> string.  6 variations gave us whole integers, and 5 variations with 1 to
> 5 digits after the decimal point.  The max values were still limited to
> I believe 8 digits.
>
> What was developed worked.  Later, when discussing with customers the
> choice of using newer capabilities, they asked, "what's the benefit" and
> actually what they had was working.  They were not interested in paying
> to replace something that was working for them.  There was also the
> issue of running the programs on historical data saved on tape.  They
> were not interested in converting the historical data.
>
> And so the old capabilities remained in use, and they did the job.  They
> are still doing the job.

Didn't VAX to Alpha migration cause some issues with D floating?

If I remember correct then Alpha did not fully support D.

Arne

On 1/29/2023 11:57 AM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>> On 1/29/2023 9:32 AM, Scott Dorsey wrote:
>>> I think the issue is with the programming language and not with the
>>> architecture. And yes, you can use bignum in C, at least under v7 Unix,
>>> and store really really big numbers.
>>
>> So other language & OS combinations did support 32 bit
>> integers on PDP-11?
>
> That's not an integer, that's a long. And yes, many languages supported
> longints on pdp-11s.

By integer I did not mean int but all the integer types
(short/int/long/whatever).

Arne

On 1/29/2023 9:49 AM, bill wrote:
> On 1/28/2023 8:39 PM, Arne Vajhøj wrote:
>> On 1/28/2023 8:28 PM, Scott Dorsey wrote:
>>> One of the absolute FIRST things that I was told about floating point
>>> variables in my first programming class was to NEVER use them to
>>> represent
>>> money.
>>
>> It is known to be problematic.
>>
>> But there are 3 cases where it happens anyway:
>> - the developer does not care
>
> Wrong developer

I agree.

>> - the language used does not have a decimal type and
>>    integers with implied decimal is considered to
>>    cumbersome
>
> Wrong language for the job

I agree, but 40 years ago there were a lot of common
languages without decimal type. Probably easier today
as most common languages has decimal - C and C++ being the
exception.

>> - decimal is actually used in general, but certain
>>    calculations temporarily move over in floating
>>    point (like some interest calculations)
>
> Wrong language for the job

I think it would be more risky to do the interest calculations
in decimal than in floating point. Decimals could easily
loose precision if developer not extremely careful about
decimals.

> Obviously, all of these can be fixed properly.  Guess the concepts of
> right tool for the job and due diligence no longer carry any sway.

Probably more an old times problem than a today problem. Newer
languages just have it even if they are not targeted towards
real business applications.

Arne