Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
On 1/31/2025 10:18, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
Yeah, I've seen that a lot, especially code that started on the PDP-11.
On 1/31/2025 10:28 AM, Robert A. Brooks wrote:
On 1/31/2025 10:18, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
Yeah, I've seen that a lot, especially code that started on the PDP-11.
In this case it is brand new code being written on VMS x86-64.
But there are special circumstances. I want to write the
same code in Pascal, Basic and Cobol. I started writing the
Pascal version. And I used true and false.
Arne
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
Arne
On 1/31/2025 10:18 AM, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
Arne
It works. Doesn't really matter if declared a constant. Zero is false, anything else is true. Using 1 vs -1 has been more my experience.
Perhaps the concept of true and false isn't as clear in Basic as in some languages.
On 1/31/2025 10:18 AM, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
It works. Doesn't really matter if declared a constant. Zero is false, anything else is true. Using 1 vs -1 has been more my experience.
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
Arne
On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
Oh goody. The "good" old days, when TRUE did not equal TRUE, are back. :-)
On 1/31/2025 1:28 PM, Simon Clubley wrote:
On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
Oh goody. The "good" old days, when TRUE did not equal TRUE, are
back. :-)
Some old some new.
C and VMS Basic are old.
But some newer script languages also have a
"flexible approach" to true/false.
$ type bool.php
<?php
function test($expr) {
echo ($expr ? 'true' : 'false') . "\r\n";
}
test(true);
test(false);
test(1);
test(0);
test(-1);
test("X");
test("");
test(null);
$ php bool.php
true
false
true
false
true
true
false
false
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
On 1/31/2025 11:39 AM, Dave Froble wrote:
On 1/31/2025 10:18 AM, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
It works. Doesn't really matter if declared a constant. Zero is false, >> anything else is true. Using 1 vs -1 has been more my experience.
I got the impression that the manual/compiler prefer -1 over 1.
print not 0%
does print -1.
On 1/31/2025 1:35 PM, Arne Vajhøj wrote:
On 1/31/2025 1:28 PM, Simon Clubley wrote:
On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
Oh goody. The "good" old days, when TRUE did not equal TRUE, are
back. :-)
Some old some new.
C and VMS Basic are old.
But some newer script languages also have a
"flexible approach" to true/false.
$ type bool.php
<?php
function test($expr) {
echo ($expr ? 'true' : 'false') . "\r\n";
}
test(true);
test(false);
test(1);
test(0);
test(-1);
test("X");
test("");
test(null);
$ php bool.php
true
false
true
false
true
true
false
false
$ type bool.py
def test(expr):
print("true" if expr else "false")
test(True)
test(False)
test(1)
test(0)
test(-1)
test("X")
test("")
test(None)
$ python bool.py
true
false
true
false
true
true
false
false
In article <679d001e$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/31/2025 11:39 AM, Dave Froble wrote:
On 1/31/2025 10:18 AM, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
It works. Doesn't really matter if declared a constant. Zero is false, >>> anything else is true. Using 1 vs -1 has been more my experience.
I got the impression that the manual/compiler prefer -1 over 1.
print not 0%
does print -1.
This sort of makes some sense when one considers the bit
representation of `-1` on a 2s complement machine (all bits 1).
In article <679d001e$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/31/2025 11:39 AM, Dave Froble wrote:
On 1/31/2025 10:18 AM, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
It works. Doesn't really matter if declared a constant. Zero is false, >>> anything else is true. Using 1 vs -1 has been more my experience.
I got the impression that the manual/compiler prefer -1 over 1.
print not 0%
does print -1.
This sort of makes some sense when one considers the bit
representation of `-1` on a 2s complement machine (all bits 1).
- Dan C.
On 1/31/2025 2:24 PM, Dan Cross wrote:
In article <679d001e$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/31/2025 11:39 AM, Dave Froble wrote:
On 1/31/2025 10:18 AM, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
It works. Doesn't really matter if declared a constant. Zero is false, >>>> anything else is true. Using 1 vs -1 has been more my experience.
I got the impression that the manual/compiler prefer -1 over 1.
print not 0%
does print -1.
This sort of makes some sense when one considers the bit
representation of `-1` on a 2s complement machine (all bits 1).
True.
But there is no consistency between languages.
$ type dump.for
[snip]
On 31/01/2025 19:24, Dan Cross wrote:
In article <679d001e$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/31/2025 11:39 AM, Dave Froble wrote:
On 1/31/2025 10:18 AM, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
It works. Doesn't really matter if declared a constant. Zero is false, >>>> anything else is true. Using 1 vs -1 has been more my experience.
I got the impression that the manual/compiler prefer -1 over 1.
print not 0%
does print -1.
This sort of makes some sense when one considers the bit
representation of `-1` on a 2s complement machine (all bits 1).
That was my understanding, a bitwise True and False should return zero >(False)
$ type bool.py
def test(expr):
print("true" if expr else "false")
$ type dump.for
subroutine dump(v)
integer*4 v
write(*,*) v
end
$ for dump
$ type logfun.for
program logfun
call dump(.true.)
call dump(.false.)
end
$ for logfun
$ link logfun + dump
$ run logfun
-1
0
Treating -1 as true in BASIC seems rather common, from the quick
survey I did; I speculate that this is almost certainly due to
the bit representation of -1 having all bits set, while in BASIC
the integer type is (usually?) signed, thus -1 on a two's
complement machine. I wonder what the original DTSS BASIC did?
On 1/31/2025 11:39 AM, Dave Froble wrote:
On 1/31/2025 10:18 AM, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
It works. Doesn't really matter if declared a constant. Zero is false,
anything else is true. Using 1 vs -1 has been more my experience.
I got the impression that the manual/compiler prefer -1 over 1.
print not 0%
does print -1.
On 1/31/25 4:05 PM, Dan Cross wrote:
Treating -1 as true in BASIC seems rather common, from the quick
survey I did; I speculate that this is almost certainly due to
the bit representation of -1 having all bits set, while in BASIC
the integer type is (usually?) signed, thus -1 on a two's
complement machine. I wonder what the original DTSS BASIC did?
I had a quick look at:
https://ia601901.us.archive.org/34/items/bitsavers_dartmouthB_3679804/ BASIC_4th_Edition_Jan68_text.pdf
and didn't see an obvious answer, though I didn't read the whole thing
and could've missed something. The exact values of true and false might well have been considered an implementation detail that should not be
relied on.
On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:ant TRUE = -1
Is it common to use:
declare integer const
declare integer constant FALSE = 0
Oh goody. The "good" old days, when TRUE did not equal TRUE, are back. :-)
Simon.
On 1/31/2025 11:53 AM, Arne Vajhøj wrote:
On 1/31/2025 11:39 AM, Dave Froble wrote:
On 1/31/2025 10:18 AM, Arne Vajhøj wrote:
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
It works. Doesn't really matter if declared a constant. Zero is false, >>> anything else is true. Using 1 vs -1 has been more my experience.
I got the impression that the manual/compiler prefer -1 over 1.
Manuals usually have a preference, but, can be incomplete.
print not 0%
does print -1.
That is an operation to flip the bits. The opposite of 0000000000000000
is 1111111111111111 ...
In article <679d26bd$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
But there is no consistency between languages.
$ type dump.for
[snip]
I don't know why this should be surprising?
On 1/31/2025 5:05 PM, Dan Cross wrote:
In article <679d26bd$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
But there is no consistency between languages.
$ type dump.for
[snip]
I don't know why this should be surprising?
I don't know if it is surprising, but it is inconsistent.
Fortran Pascal C Basic
true literal -1 1 usually 1 usually -1
false literal 0 0 0 0
test low bit set low bit set not 0 not 0
4 languages - 4 ways of doing it.
On 1/31/2025 5:05 PM, Dan Cross wrote:
In article <679d26bd$0$713$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
But there is no consistency between languages.
$ type dump.for
[snip]
I don't know why this should be surprising?
I don't know if it is surprising, but it is inconsistent.
Fortran Pascal C Basic
true literal -1 1 usually 1 usually -1
false literal 0 0 0 0
test low bit set low bit set not 0 not 0
4 languages - 4 ways of doing it.
Regarding the test:
Basic : TRUE TRUE FALSE TRUE TRUE
Fortran : F T F T F
C : TRUE TRUE FALSE TRUE TRUE
Pascal : F T F T F
On 1/31/2025 8:39 PM, Arne Vajhøj wrote:
Improved version:
* more values
* also pass individual values instead of array
* dump addresses for verification
* also try C bool for individual values (we are
past 1999)
[snip]
(in case someone wonder about C bool, then it is 8 bit!)
On 2/1/25 3:00 PM, Arne Vajhøj wrote:
(in case someone wonder about C bool, then it is 8 bit!)
I don't think it has to be. C99 says:
"An object declared as type _Bool is large enough to store the values 0
and 1."
8 bits are enough, but any integral type has enough bits. "bool,"
"true," and "false" in stdbool.h are macros that can be overridden,
although doing so is described as "obsolescent" behavior. It's probably necessary because of the uses of bool before the standard had it.
I'm pretty sure I've seen bool defined as an int on VMS, but whether
that was something VAX C did for you or was just some what some program
did in the absence of anything available from the (old) compiler I don't remember.
(in case someone wonder about C bool, then it is 8 bit!)
Is it common to use:
declare integer constant TRUE = -1
declare integer constant FALSE = 0
?
F T F F T F T T F F F T
Hello world!
On 2/1/2025 6:38 PM, Craig A. Berry wrote:
On 2/1/25 3:00 PM, Arne Vajhøj wrote:
(in case someone wonder about C bool, then it is 8 bit!)
I don't think it has to be. C99 says:
"An object declared as type _Bool is large enough to store the values 0
and 1."
8 bits are enough, but any integral type has enough bits. "bool,"
"true," and "false" in stdbool.h are macros that can be overridden,
although doing so is described as "obsolescent" behavior. It's probably
necessary because of the uses of bool before the standard had it.
I'm pretty sure I've seen bool defined as an int on VMS, but whether
that was something VAX C did for you or was just some what some program
did in the absence of anything available from the (old) compiler I don't
remember.
The C standard does not mandate 8 bit.
The VMS C documentation says 8 bit. Well - it says 1 byte
for whatever reason, but ...
If one include stdbool.h then bool is _Bool. From C 99.
Before C 99 then I think:
typedef int bool;
#define TRUE 1
#define FALSE 0
was common.
(stdbool.h also defines true and false)
If you really want to have a good time, look at how
JavaScript deals with this. Things aren't just true
or false, they're truthy and falsy, and sometimes Nan.
https://www.youtube.com/watch?v=et8xNAc2ic8
Fortran got some other rather unique usages
of logicals:
$ type morelogfun.for
program morelogfun
logical*1 a(12)
data a/1hH,1he,1hl,1hl,1ho,1h ,1hw,1ho,1hr,1hl,1hd,1h!/
integer*4 i
write(*,*) (a(i),i=1,12)
write(*,'(1x,12a1)') (a(i),i=1,12)
end
$ for morelogfun
$ lin morelogfun
$ run morelogfun
F T F F T F T T F F F T
Hello world!
On 1/31/2025 1:28 PM, Simon Clubley wrote:
On 2025-01-31, Arne Vajhj <arne@vajhoej.dk> wrote:ant TRUE = -1
Is it common to use:
declare integer const
declare integer constant FALSE = 0
Oh goody. The "good" old days, when TRUE did not equal TRUE, are back. :-) >>
Not sure what that means ...
On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
Fortran got some other rather unique usages
of logicals:
$ type morelogfun.for
program morelogfun
logical*1 a(12)
data a/1hH,1he,1hl,1hl,1ho,1h ,1hw,1ho,1hr,1hl,1hd,1h!/
integer*4 i
write(*,*) (a(i),i=1,12)
write(*,'(1x,12a1)') (a(i),i=1,12)
end
$ for morelogfun
DEC Fortran still allows Hollerith constants without having to specify
a compiler option to enable them ?
For people who do not know historical Fortran, see:
https://en.wikipedia.org/wiki/Hollerith_constant
Hollerith constants have been removed from the current Fortran language standards (and rightly so).
[Hollerith] is an extension in VMS fortran.
And even though it is a horrible way to do text, then it is not
something one get to use accidentally.
Every few years, somebody decides that computing can be made simpler by discarding the lessons of the past. Then they find have to re-invent the safety precautions and useful features of the past, and do it a bit differently.
On 2025-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
If you really want to have a good time, look at how
JavaScript deals with this. Things aren't just true
or false, they're truthy and falsy, and sometimes Nan.
https://www.youtube.com/watch?v=et8xNAc2ic8
And we use this crap to build critical websites that our society and
general way of life now depend on. :-(
And some even think it's a good idea to run this server-side. :-(
On 2/3/2025 5:05 PM, Lawrence D'Oliveiro wrote:
Trouble is, every other notation for string literals requires some kind
of escape system for representing characters that might interfere with
the syntax notation itself.
True. But that does not seem to be a problem.
On Mon, 3 Feb 2025 15:39:37 -0500, Arne Vajhøj wrote:
[Hollerith] is an extension in VMS fortran.
And even though it is a horrible way to do text, then it is not
something one get to use accidentally.
Trouble is, every other notation for string literals requires some kind of escape system for representing characters that might interfere with the syntax notation itself.
On 2/3/2025 5:05 PM, Lawrence D'Oliveiro wrote:
On Mon, 3 Feb 2025 15:39:37 -0500, Arne Vajhøj wrote:
[Hollerith] is an extension in VMS fortran.
And even though it is a horrible way to do text, then it is not
something one get to use accidentally.
Trouble is, every other notation for string literals requires some kind of >> escape system for representing characters that might interfere with the
syntax notation itself.
True. But that does not seem to be a problem. Whether it is
because it is simple or because practical all developers
know the two main ways (doubling and backslash escape)
does not change that it work fine.
On Mon, 3 Feb 2025 19:32:35 -0500, Arne Vajhøj wrote:
On 2/3/2025 5:05 PM, Lawrence D'Oliveiro wrote:
Trouble is, every other notation for string literals requires some kind
of escape system for representing characters that might interfere with
the syntax notation itself.
True. But that does not seem to be a problem.
I know. Normal people see it as an absolute nightmare to try to calculate
a count prefix. But surely any self-respecting editor makes that easy,
e.g.
44HThe quick brown fox jumps over the lazy dog.
It only took me a few seconds in Emacs, even without the benefit of a
custom command to make it faster.
And we use this crap to build critical websites that our society and
general way of life now depend on. :-(
And some even think it's a good idea to run this server-side. :-(
Note that the above seems to be a hollerith edit descriptor ...
Note that the above seems to be a hollerith edit descriptor ...
On Mon, 3 Feb 2025 20:53:00 -0500, Arne Vajhøj wrote:
Note that the above seems to be a hollerith edit descriptor ...
Ah, you are confusing usage with syntax.
On Mon, 3 Feb 2025 20:53:00 -0500, Arne Vajhøj wrote:
Note that the above seems to be a hollerith edit descriptor ...
Never heard of such a thing. <https://www.ibm.com/docs/en/openxl-fortran-aix/17.1.2?topic=constants-hollerith>
On 2/4/2025 6:16 PM, Lawrence D'Oliveiro wrote:
On Mon, 3 Feb 2025 20:53:00 -0500, Arne Vajhøj wrote:
Note that the above seems to be a hollerith edit descriptor ...
Ah, you are confusing usage with syntax.
It is two different things in the language.
On 2/3/2025 1:35 PM, Simon Clubley wrote:
On 2025-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
Fortran got some other rather unique usages
of logicals:
$ type morelogfun.for
program morelogfun
logical*1 a(12)
data a/1hH,1he,1hl,1hl,1ho,1h ,1hw,1ho,1hr,1hl,1hd,1h!/
integer*4 i
write(*,*) (a(i),i=1,12)
write(*,'(1x,12a1)') (a(i),i=1,12)
end
$ for morelogfun
DEC Fortran still allows Hollerith constants without having to specify
a compiler option to enable them ?
For people who do not know historical Fortran, see:
https://en.wikipedia.org/wiki/Hollerith_constant
Hollerith constants have been removed from the current Fortran language
standards (and rightly so).
It is an extension in VMS fortran.
And even though it is a horrible way to do text, then it
is not something one get to use accidentally.
On 2025-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
If you really want to have a good time, look at how
JavaScript deals with this. Things aren't just true
or false, they're truthy and falsy, and sometimes Nan.
https://www.youtube.com/watch?v=et8xNAc2ic8
And we use this crap to build critical websites that our society and
general way of life now depend on. :-(
And some even think it's a good idea to run this server-side. :-(
On 2/3/2025 1:24 PM, Simon Clubley wrote:
On 2025-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
If you really want to have a good time, look at how
JavaScript deals with this. Things aren't just true
or false, they're truthy and falsy, and sometimes Nan.
https://www.youtube.com/watch?v=et8xNAc2ic8
And we use this crap to build critical websites that our society and
general way of life now depend on. :-(
And some even think it's a good idea to run this server-side. :-(
JavaScript has had a huge market share in presentation layer
in web applications for decades.
Either companies don't know how to profit maximize or
JavaScript is/was a good choice for this type
of code.
Small code bases, frequent releases and high user
tolerance for small ooopses favor a language like
JavaScript. Ada would not work well in this context
from a business perspective.
Code bases are not small anymore though. And TypeScript
has taken huge chunks of market share from
JavaScript in recent years.
On 2/3/2025 1:24 PM, Simon Clubley wrote:
On 2025-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
If you really want to have a good time, look at how
JavaScript deals with this. Things aren't just true
or false, they're truthy and falsy, and sometimes Nan.
https://www.youtube.com/watch?v=et8xNAc2ic8
And we use this crap to build critical websites that our society and
general way of life now depend on. :-(
And some even think it's a good idea to run this server-side. :-(
JavaScript has had a huge market share in presentation layer
in web applications for decades.
Either companies don't know how to profit maximize or
JavaScript is/was a good choice for this type
of code.
Small code bases, frequent releases and high user
tolerance for small ooopses favor a language like
JavaScript. Ada would not work well in this context
from a business perspective.
Code bases are not small anymore though. And TypeScript
has taken huge chunks of market share from
JavaScript in recent years.
In article <67a4cc2d$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 2/3/2025 1:24 PM, Simon Clubley wrote:
On 2025-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
If you really want to have a good time, look at how
JavaScript deals with this. Things aren't just true
or false, they're truthy and falsy, and sometimes Nan.
https://www.youtube.com/watch?v=et8xNAc2ic8
And we use this crap to build critical websites that our society and
general way of life now depend on. :-(
And some even think it's a good idea to run this server-side. :-(
JavaScript has had a huge market share in presentation layer
in web applications for decades.
Either companies don't know how to profit maximize or
JavaScript is/was a good choice for this type
of code.
Server side Javascript does not run on the browser.
Small code bases, frequent releases and high user
tolerance for small ooopses favor a language like
JavaScript. Ada would not work well in this context
from a business perspective.
Code bases are not small anymore though. And TypeScript
has taken huge chunks of market share from
JavaScript in recent years.
Typescript is a better language. JavaScript should
have been better than it was, but that shippe has sailed,
and the story has been told many times: it was ten days
from conception to ship, and the consequent lack of
polish shows.
On 2/6/2025 10:24 AM, Dan Cross wrote:
In article <67a4cc2d$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 2/3/2025 1:24 PM, Simon Clubley wrote:
On 2025-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
If you really want to have a good time, look at how
JavaScript deals with this. Things aren't just true
or false, they're truthy and falsy, and sometimes Nan.
https://www.youtube.com/watch?v=et8xNAc2ic8
And we use this crap to build critical websites that our society and
general way of life now depend on. :-(
And some even think it's a good idea to run this server-side. :-(
JavaScript has had a huge market share in presentation layer
in web applications for decades.
Either companies don't know how to profit maximize or
JavaScript is/was a good choice for this type
of code.
Server side Javascript does not run on the browser.
Small code bases, frequent releases and high user
tolerance for small ooopses favor a language like
JavaScript. Ada would not work well in this context
from a business perspective.
Code bases are not small anymore though. And TypeScript
has taken huge chunks of market share from
JavaScript in recent years.
Typescript is a better language. JavaScript should
have been better than it was, but that shippe has sailed,
and the story has been told many times: it was ten days
from conception to ship, and the consequent lack of
polish shows.
If JavaScript was unique in the web frontend world
for lack of type safety, then the lack of type safety
could be due to its history.
But it is not unique. Other popular languages like
PHP and Python also has a relaxed approach to types.
Past popular languages like Perl and VBS same.
Web frontend is not like backend or embedded.
Small code bases, frequent releases and high user tolerance for small
ooopses favor a language like JavaScript. Ada would not work well in
this context from a business perspective.
Code bases are not small anymore though. And TypeScript has taken huge
chunks of market share from JavaScript in recent years.
If JavaScript was unique in the web frontend world for lack of type
safety, then the lack of type safety could be due to its history.
Other popular languages like PHP and Python also has a relaxed
approach to types.
On Thu, 6 Feb 2025 09:50:21 -0500, Arne Vajhøj wrote:
Small code bases, frequent releases and high user tolerance for small
ooopses favor a language like JavaScript. Ada would not work well in
this context from a business perspective.
JavaScript is also a dynamic language, unlike Ada. Maybe not as dynamic as Python, but still lets you do a lot in quite compact code.
I’m not sure I agree with the “tolerance for small ooopses”. There is a thing called “use strict”, which helps catch common JavaScript errors. It is even enforced in new-style modules.
Code bases are not small anymore though. And TypeScript has taken huge
chunks of market share from JavaScript in recent years.
TypeScript is just an attempt to add static typing to JavaScript. Maybe it works for native-side code bases (i.e. not in a browser sandbox).
On Thu, 6 Feb 2025 11:04:12 -0500, Arne Vajhøj wrote:
If JavaScript was unique in the web frontend world for lack of type
safety, then the lack of type safety could be due to its history.
Other popular languages like PHP and Python also has a relaxed
approach to types.
Worth being clear what we’re talking about. None of these languages is type-unsafe in the way that C, for example, allows free typecasting
between unrelated types, and in particular between pointers to unrelated types. They are all dynamic languages, and every value that a variable can hold does have an explicit type, and conversions between types follow well-founded semantic rules.
However, JavaScript and PHP have a laissez-faire attitude to equivalences with strings, and will happily autoconvert between strings and non-string types in various situations, often leading to surprising results. This is
why both those languages have the “===” comparison operator as a stricter form of “==” which says “turn off these string-nonstring autoconversions”.
Python never had this particular bit of brain damage. But it does still
have that common weakness with booleans. Which is a more manageable issue.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 432 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 30:29:13 |
| Calls: | 9,081 |
| Calls today: | 4 |
| Files: | 13,409 |
| Messages: | 6,022,133 |