I knew it was bad, but not that bad.
On Fri, 23 Jan 2026 21:35:54 -0600, Lynn McGuire wrote:
I knew it was bad, but not that bad.
Back in earlier Web 1.0 days, I developed an online shop system for
a client, that had to be localizable for different target markets -- different currencies, different languages.
I developed a templating system, which allowed the code to substitute
strings into other strings, making choices according to numbers of
items (for singular-versus-plural cases), gender etc. Since the
placeholders were substituted by name, not position, this allowed for differences in grammar (e.g. verb-noun ordering).
As new languages came along with more grammatical peculiarities, I
added new templating cases, that could substitute to exactly the same
strings for existing languages. For example, a list of items in
English might expand to one of
1 item -- rCLArCY
2 items -- rCLA or BrCY
3 or more items -- rCLA, B, ... C or DrCY
whereas in Japanese, the case with 3 items has to be distinguished
from the ones with 4 or more items.
The hard part was explaining the templating system to translators. I
tried giving copious examples of how the substitutions would work in
specific cases. As I recall, I still had to do some massaging of the
strings they sent back, in some cases having to guess what they meant,
and then get them to test the results, to confirm with them that the
site was producing the correct messages in all cases.
"Internationalis(z)ing Code - Computerphile"
https://www.youtube.com/watch?v=0j74jcxSunY
"Catering for a global audience is difficult, Tom takes us through a 'timezones' style explanation of the things you need to keep in mind
when internationalising your code."
I knew it was bad, but not that bad.
Yup, I just write and sell my software in American English. I've got
enough problems without having to deal with localization.
One of my programmers has been working on converting our Windows user interface, written in 450,000 lines of C++, from Ascii to Unicode for
two years now. It was a one year project to start and his latest
estimate is another year to complete.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
"Internationalis(z)ing Code - Computerphile"
https://www.youtube.com/watch?v=0j74jcxSunY
"Catering for a global audience is difficult, Tom takes us through a
'timezones' style explanation of the things you need to keep in mind
when internationalising your code."
I knew it was bad, but not that bad.
Yup, I just write and sell my software in American English. I've got
enough problems without having to deal with localization.
You can probably get by with engineering software.
One of my programmers has been working on converting our Windows user
interface, written in 450,000 lines of C++, from Ascii to Unicode for
two years now. It was a one year project to start and his latest
estimate is another year to complete.
Like the early history of Fortran - when people ask when the project
was going to be finisehd, the answer was always "in six months".
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
[...]-aI've got enough problems without having to deal with localization.
BTW, I don't put commas in my 12 digit printed numbers because I sell
40% of my software outside the USA, just periods.
Shoot, people can't
even agree on periods or commas for the fractional part.
BTW, I don't put commas in my 12 digit printed numbers because I sell
40% of my software outside the USA, just periods. Shoot, people can't
even agree on periods or commas for the fractional part.
On Sun, 25 Jan 2026 15:21:27 -0600, Lynn McGuire wrote:
BTW, I don't put commas in my 12 digit printed numbers because I sell
40% of my software outside the USA, just periods. Shoot, people can't
even agree on periods or commas for the fractional part.
This is where you should automatically query the locale settings.
On Sun, 25 Jan 2026 15:21:27 -0600, Lynn McGuire wrote:
BTW, I don't put commas in my 12 digit printed numbers because I sell
40% of my software outside the USA, just periods. Shoot, people can't
even agree on periods or commas for the fractional part.
This is where you should automatically query the locale settings.
On 1/25/2026 7:42 PM, Lawrence DrCOOliveiro wrote:
On Sun, 25 Jan 2026 15:21:27 -0600, Lynn McGuire wrote:
BTW, I don't put commas in my 12 digit printed numbers because I
sell 40% of my software outside the USA, just periods. Shoot,
people can't even agree on periods or commas for the fractional
part.
This is where you should automatically query the locale settings.
Yup, only if I had the time. I am at 15% of converting my Fortran
code to C++. 800,000 lines of Fortran code with 700,000 lines to go.
I got my input parser on my data reduction software to working in
C++ just last Thursday.
Lynn
On 2026-01-25 22:21, Lynn McGuire wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
[...]-aI've got enough problems without having to deal with localization.
Getting all right if implementing things from scratch is demanding.
(Luckily software and systems nowadays handle that for us.)
$ LC_NUMERIC=de_DE.UTF-8 printf "%9.3f\n" 1.234,567
1234,567
$ LC_NUMERIC=en_US.UTF-8 printf "%9.3f\n" 1,234.567
1234.567
BTW, I don't put commas in my 12 digit printed numbers because I sell
40% of my software outside the USA, just periods.
That, OTOH, is just the trivial part. Even some old languages (like
Simula) allowed to change the decimal mark character for read/write
of real numbers. Since you just need that function on the interface
level it can be done in one place (presuming you use the respective
function, or redefine your own); the internal representation may be
all the same. So just define the numeric separators in the program's >environment.
Shoot, people can't
even agree on periods or commas for the fractional part.
Are you really complaining about characteristics of people's (or
nation's) historic conventions?
I started writing Fortran code in 1975 for one of my dad's programmers
when I was 14. Dad was always selling the future capabilities of the software, more than the software did or was even designed to do.
On Mon, 26 Jan 2026 00:45:41 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
On 1/25/2026 7:42 PM, Lawrence DrCOOliveiro wrote:
On Sun, 25 Jan 2026 15:21:27 -0600, Lynn McGuire wrote:
BTW, I don't put commas in my 12 digit printed numbers because I
sell 40% of my software outside the USA, just periods. Shoot,
people can't even agree on periods or commas for the fractional
part.
This is where you should automatically query the locale settings.
Yup, only if I had the time. I am at 15% of converting my Fortran
code to C++. 800,000 lines of Fortran code with 700,000 lines to go.
I got my input parser on my data reduction software to working in
C++ just last Thursday.
Lynn
How many of your grandchildren are working on this software?
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I started writing Fortran code in 1975 for one of my dad's programmers
when I was 14. Dad was always selling the future capabilities of the
software, more than the software did or was even designed to do.
Sounds an awful lot like Bill Gates, but he even sold software
that had not even been written. There is a story where he wrote a
Fortran compiler, which failed tests and was therefore not accepted,
and he refused to fix the bugs.
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
Lawrence DrCOOliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
On 1/27/2026 12:45 AM, Thomas Koenig wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
If I remember correctly, Microsoft licensed somebody else's Fortran 90 compiler and relabeled it.
On 1/27/2026 12:45 AM, Thomas Koenig wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
If I remember correctly, Microsoft licensed somebody else's Fortran
90 compiler and relabeled it.
Lynn
On Tue, 27 Jan 2026 01:46:43 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
On 1/27/2026 12:45 AM, Thomas Koenig wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
If I remember correctly, Microsoft licensed somebody else's Fortran
90 compiler and relabeled it.
Lynn
There is a big chance that you don't remember correctly.
At least it is different, not to say opposite, from the story that I
read in other places.
They say that when Microsoft found out that support for F90 is
necessary for continuation of their Fortran business then they
decided that their compilers stuff has more important things to
do. So they sold their compiler sources and Powerstation brand to
Digital that later became Compaq and later yet before merger with HP
sold it to Intel where it either replaced Intel's own Fortran compiler
or was merged with it. The last part of the story is not conclusive.
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
On 1/26/2026 11:46 PM, Lynn McGuire wrote:
On 1/27/2026 12:45 AM, Thomas Koenig wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
If I remember correctly, Microsoft licensed somebody else's Fortran 90
compiler and relabeled it.
Kind of reminded me of, god what was that C++ std lib they licensed for
msvc 6.0. Damn I cannot remember the name right now... search...
Dinkumware! Ahhh.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 1/26/2026 11:46 PM, Lynn McGuire wrote:
On 1/27/2026 12:45 AM, Thomas Koenig wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> schrieb:
On Mon, 26 Jan 2026 22:47:33 -0000 (UTC), Thomas Koenig wrote:
There is a story where he wrote a Fortran compiler, which failed
tests and was therefore not accepted, and he refused to fix the
bugs.
Who was dumb enough to buy that?
They didn't, it was not accepted.
Unfortunately, the story itself seems to have vanished from the
Internet, or at least I cannot find it with Google any more.
If I remember correctly, Microsoft licensed somebody else's Fortran 90
compiler and relabeled it.
Kind of reminded me of, god what was that C++ std lib they licensed for
msvc 6.0. Damn I cannot remember the name right now... search...
Dinkumware! Ahhh.
To be fair dinkum about it, the company name was not derogatory.
IME, locale settings can be a bigger hinder than help, especially onRight. When using locales, the result of the program run is not
Windows and with MS Office.
Locales are only useful when displaying info directly for the user to
view.
Alas, most C++ projects are not GUI, but much lower level libraries
where there is no connection between the current machine
locale and the locale of the human viewer
who might eventually view the produced data.
Moreover, most produced text data is consumed by other
software nowadays,
not humans, and having to deal with varying locales
just breaks or at least complicates the things here.
So locale-dependent
behavior should not be the default, but rather something to be ordered explicitly and used rarely.
[...]
IME, locale settings can be a bigger hinder than help, especially on
Windows and with MS Office. If your program exports data in tab or semicolon separated formats to be opened in a spreadsheet, or has some
other connection to MS Office programs, you have to use the formats that
the locale wants, not the formats the current user wants.
(LibreOffice
is vastly more flexible.) Displaying a decimal point, decimal colon, or decimal apostrophe is not difficult - it is handling the imports and
exports that is the challenge.
"Internationalis(z)ing Code - Computerphile"
-a-a https://www.youtube.com/watch?v=0j74jcxSunY
"Catering for a global audience is difficult, Tom takes us through a 'timezones' style explanation of the things you need to keep in mind
when internationalising your code."
I knew it was bad, but not that bad.
Yup, I just write and sell my software in American English.-a I've got
enough problems without having to deal with localization.
One of my programmers has been working on converting our Windows user interface, written in 450,000 lines of C++, from Ascii to Unicode for
two years now.-a It was a one year project to start and his latest
estimate is another year to complete.
David Brown <david.brown@hesbynett.no> schrieb:
[...]
IME, locale settings can be a bigger hinder than help, especially on
Windows and with MS Office. If your program exports data in tab or
semicolon separated formats to be opened in a spreadsheet, or has some
other connection to MS Office programs, you have to use the formats that
the locale wants, not the formats the current user wants.
That is so true. Localization in MS Office is a pain, and the different
CSV formats are horrible.
On my personal PC, I have set the decimal separator, with German
settings otherwise, to a dot. This makes data interoperable
with all sorts of scripts and other programs that I tend to use
togetether with data from Excel files. Using tab as a separator works
pretty well then, it is at least unique.
I do have another computer, used as a workstation, which I keep
on US English settings. This allows easier communication with,
for example, international support for programs which originate
outside of Germany. It also allows me to have the original Excel
function names, which are also localized. Luckily, I can save
an Excel file in English and than open it on my German-language
computer in German.
(LibreOffice
is vastly more flexible.) Displaying a decimal point, decimal colon, or
decimal apostrophe is not difficult - it is handling the imports and
exports that is the challenge.
I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
On 30/01/2026 21:28, Thomas Koenig wrote:
David Brown <david.brown@hesbynett.no> schrieb:
[...]
IME, locale settings can be a bigger hinder than help, especially on
Windows and with MS Office. If your program exports data in tab or
semicolon separated formats to be opened in a spreadsheet, or has some
other connection to MS Office programs, you have to use the formats that >>> the locale wants, not the formats the current user wants.
That is so true. Localization in MS Office is a pain, and the different
CSV formats are horrible.
On my personal PC, I have set the decimal separator, with German
settings otherwise, to a dot. This makes data interoperable
with all sorts of scripts and other programs that I tend to use
togetether with data from Excel files. Using tab as a separator works
pretty well then, it is at least unique.
I do have another computer, used as a workstation, which I keep
on US English settings. This allows easier communication with,
for example, international support for programs which originate
outside of Germany. It also allows me to have the original Excel
function names, which are also localized. Luckily, I can save
an Excel file in English and than open it on my German-language
computer in German.
(LibreOffice
is vastly more flexible.) Displaying a decimal point, decimal colon, or >>> decimal apostrophe is not difficult - it is handling the imports and
exports that is the challenge.
I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings. Then at least you get sane paper
sizes and measurement units.
LibreOffice has its faults and weaknesses, but it is still far ahead of--- Synchronet 3.21b-Linux NewsLink 1.2
MS Office in many aspects. (Or perhaps "less terrible" is more accurate?)
In comp.lang.c David Brown <david.brown@hesbynett.no> wrote:
On 30/01/2026 21:28, Thomas Koenig wrote:and sane dates...
David Brown <david.brown@hesbynett.no> schrieb:
[...]
IME, locale settings can be a bigger hinder than help, especially on
Windows and with MS Office. If your program exports data in tab or
semicolon separated formats to be opened in a spreadsheet, or has some >>>> other connection to MS Office programs, you have to use the formats that >>>> the locale wants, not the formats the current user wants.
That is so true. Localization in MS Office is a pain, and the different >>> CSV formats are horrible.
On my personal PC, I have set the decimal separator, with German
settings otherwise, to a dot. This makes data interoperable
with all sorts of scripts and other programs that I tend to use
togetether with data from Excel files. Using tab as a separator works
pretty well then, it is at least unique.
I do have another computer, used as a workstation, which I keep
on US English settings. This allows easier communication with,
for example, international support for programs which originate
outside of Germany. It also allows me to have the original Excel
function names, which are also localized. Luckily, I can save
an Excel file in English and than open it on my German-language
computer in German.
(LibreOffice
is vastly more flexible.) Displaying a decimal point, decimal colon, or >>>> decimal apostrophe is not difficult - it is handling the imports and
exports that is the challenge.
I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings. Then at least you get sane paper
sizes and measurement units.
LibreOffice has its faults and weaknesses, but it is still far ahead of
MS Office in many aspects. (Or perhaps "less terrible" is more accurate?)
Date format is adjustable in many applications.-a Choose the one you
want.-a Flexibility is taken to a bit extreme in GINO graphics libraries
(a UK product), with a calendar that goes all the way back to 1066...:)
Flexibility is taken to a bit extreme in GINO graphics libraries (a
UK product), with a calendar that goes all the way back to 1066...:)
On 30/01/2026 21:28, Thomas Koenig wrote:
I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings. Then at least you get sane paper
sizes and measurement units.
LibreOffice has its faults and weaknesses, but it is still far ahead of
MS Office in many aspects. (Or perhaps "less terrible" is more accurate?)
On 1/31/2026 12:50 PM, G wrote:
In comp.lang.c David Brown <david.brown@hesbynett.no> wrote:
On 30/01/2026 21:28, Thomas Koenig wrote:
and sane dates...I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings.-a Then at least you get sane paper
sizes and measurement units.
Date format is adjustable in many applications.-a Choose the one you
want.-a Flexibility is taken to a bit extreme in GINO graphics libraries
(a UK product), with a calendar that goes all the way back to 1066...:)
LibreOffice has its faults and weaknesses, but it is still far ahead of
MS Office in many aspects.-a (Or perhaps "less terrible" is more
accurate?)
David Brown <david.brown@hesbynett.no> schrieb:
On 30/01/2026 21:28, Thomas Koenig wrote:
I have not yet succeeded in getting LibreOffice to display a decimal
point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings. Then at least you get sane paper
sizes and measurement units.
That is better, thanks!
LibreOffice has its faults and weaknesses, but it is still far ahead of
MS Office in many aspects. (Or perhaps "less terrible" is more accurate?)
I find Impress to be very difficult to work with, compared to
PowerPoint.
But the most recent thing that drove me up the wall
was Excel's inability to display a bar graph with non-overlapping
bars for a primary and secondary axis, so I can display data like
a 2 0.1
b 3 0.3
c 5 0.2
in a sane way. Libreoffice Calc can actually do this.
On 31/01/2026 23:10, Gary Scott wrote:
On 1/31/2026 12:50 PM, G wrote:
In comp.lang.c David Brown <david.brown@hesbynett.no> wrote:
On 30/01/2026 21:28, Thomas Koenig wrote:
and sane dates...I have not yet succeeded in getting LibreOffice to display a decimal >>>>> point with German settings, and when I use US English I get inches
for paper sizes :-(
Use UK settings, not US settings.-a Then at least you get sane paper
sizes and measurement units.
Indeed.-a Some countries use little-endian dates, some use big-endian
dates, and one country likes muddled-endian dates :-)
Date format is adjustable in many applications.-a Choose the one you
want.-a Flexibility is taken to a bit extreme in GINO graphics
libraries (a UK product), with a calendar that goes all the way back
to 1066...:)
Dates from long ago can be very important, and challenging to get right.
-aBut I doubt that there is a lot of overlap between people interested
in programming with graphics libraries and people trying to match up
exact dates a millennium ago!
(In the MS Office vs. LibreOffice comparison, Excel famously thinks 1900
was a leap year.-a And rather than fix the problem, MS bullied it in as
an ISO standard.)
LibreOffice has its faults and weaknesses, but it is still far ahead of >>>> MS Office in many aspects.-a (Or perhaps "less terrible" is more
accurate?)
I fully understand why many people from non-English-speaking countries sometimes find it best to have an English locale or language settings on their systems. But I have never understood why they pick US English forBecause the US is fairly big, and has economic power disproportionate to
the purpose. Despite the Brexit madness, UK standards are far closer to European norms than the US standards are. And for many purposes, those norms are nearly global - the US is the only one that is different.
On 2026-02-01 05:35, David Brown wrote:
...
I fully understand why many people from non-English-speaking countriesBecause the US is fairly big, and has economic power disproportionate to
sometimes find it best to have an English locale or language settings on
their systems. But I have never understood why they pick US English for
the purpose. Despite the Brexit madness, UK standards are far closer to
European norms than the US standards are. And for many purposes, those
norms are nearly global - the US is the only one that is different.
it's size, so it's peculiarities get catered to more often than might otherwise seem justified. I am a US citizen, but I'm not endorsing this, merely describing it.
But when people in other countries want to choose an English language environment (because English has a lot of influence on the world - for
good reasons and bad reasons), why pick an environment that has more incompatibilities and baggage than necessary? I expect it is mostly a
matter of sticking to default choices unless you know you need
something different, and simply not thinking about the alternatives.
The US has three times as many native speakers of English than the
entire rest of the world combined, including the entire British
Commonwealth.
On Sat, 31 Jan 2026 16:10:38 -0600, Gary Scott wrote:
Flexibility is taken to a bit extreme in GINO graphics libraries (a
UK product), with a calendar that goes all the way back to 1066...:)
ldo@theon:~> date -d "1-Jan-1066"
Mon 01 Jan 1066 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-966"
Wed 01 Jan 0966 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-866"
Fri 01 Jan 0866 00:00:00 LMT
On 2026-02-01 17:01, David Brown wrote:
...
But when people in other countries want to choose an English language
environment (because English has a lot of influence on the world - for
good reasons and bad reasons), why pick an environment that has more
incompatibilities and baggage than necessary? I expect it is mostly a
matter of sticking to default choices unless you know you need
something different, and simply not thinking about the alternatives.
The US has three times as many native speakers of English than the
entire rest of the world combined, including the entire British
Commonwealth.
When someone from a non-English speaking country sets up
an English compatible environment, there's a pretty good chance he's
doing so to communicate with people in the US, rather than other parts
of English-speaking world.
On 02/02/2026 01:11, James Kuyper wrote:
On 2026-02-01 17:01, David Brown wrote:
...
But when people in other countries want to choose an English
language environment (because English has a lot of influence on
the world - for good reasons and bad reasons), why pick an
environment that has more incompatibilities and baggage than
necessary? I expect it is mostly a matter of sticking to default
choices unless you know you need something different, and simply
not thinking about the alternatives.
The US has three times as many native speakers of English than the
entire rest of the world combined, including the entire British Commonwealth.
There are about 400 million native English speakers around the world,
of which about 230 are in the USA. Of course any such numbers will
be estimates, with surveys being from different years, but it
certainly looks like you overestimate the numerical ratios.
Still, the native speaker numbers are not the relevant numbers here -
it is primarily the second language users that matter. That is, of
course, even more difficult to judge well - there is no consensus on
how well a second language must be understood to count as an English
speaker. Best guesses, as far as I can see, are about 1.1 billion.
When someone from a non-English speaking country sets up
an English compatible environment, there's a pretty good chance he's
doing so to communicate with people in the US, rather than other
parts of English-speaking world.
No, by far the most likely reason for a non-native English speaker to
speak English is to communicate with another non-native English
speaker. English is the lingua franca of the world.
But my point was more about the factors /other/ than the language.
The whole world, other than the USA, uses metric for everything
technical. The whole world, other than the USA, Canada and Mexico
uses A4 and related paper sizes. The whole world, other than the
USA, uses either little-endian or big-endian dates.
Thus for perhaps 80% of people in the world using a computer and communicating in English, UK locale settings are a better fit than US
locale settings. (For many, perhaps most, other English variants -
like Indian English locale, would be even better.)
On Mon, 2 Feb 2026 11:27:53 +0100
David Brown <david.brown@hesbynett.no> wrote:
On 02/02/2026 01:11, James Kuyper wrote:
On 2026-02-01 17:01, David Brown wrote:
...
But when people in other countries want to choose an English
language environment (because English has a lot of influence on
the world - for good reasons and bad reasons), why pick an
environment that has more incompatibilities and baggage than
necessary? I expect it is mostly a matter of sticking to default
choices unless you know you need something different, and simply
not thinking about the alternatives.
The US has three times as many native speakers of English than the
entire rest of the world combined, including the entire British
Commonwealth.
There are about 400 million native English speakers around the world,
of which about 230 are in the USA. Of course any such numbers will
be estimates, with surveys being from different years, but it
certainly looks like you overestimate the numerical ratios.
Still, the native speaker numbers are not the relevant numbers here -
it is primarily the second language users that matter. That is, of
course, even more difficult to judge well - there is no consensus on
how well a second language must be understood to count as an English
speaker. Best guesses, as far as I can see, are about 1.1 billion.
When someone from a non-English speaking country sets up
an English compatible environment, there's a pretty good chance he's
doing so to communicate with people in the US, rather than other
parts of English-speaking world.
No, by far the most likely reason for a non-native English speaker to
speak English is to communicate with another non-native English
speaker. English is the lingua franca of the world.
But my point was more about the factors /other/ than the language.
The whole world, other than the USA, uses metric for everything
technical. The whole world, other than the USA, Canada and Mexico
uses A4 and related paper sizes. The whole world, other than the
USA, uses either little-endian or big-endian dates.
Thus for perhaps 80% of people in the world using a computer and
communicating in English, UK locale settings are a better fit than US
locale settings. (For many, perhaps most, other English variants -
like Indian English locale, would be even better.)
That sounds about right except for keyboard layout.
For majority of non-native English user (not necessarily speakers, many computer users can't speak English, even more can't understand English
spoken by natives, but they read and write English not too badly) US
layout would be more practical than UK layout.
On 02/02/2026 01:11, James Kuyper wrote:...
The US has three times as many native speakers of English than the
entire rest of the world combined, including the entire British
Commonwealth.
There are about 400 million native English speakers around the world, of which about 230 are in the USA. Of course any such numbers will be estimates, with surveys being from different years, but it certainly
looks like you overestimate the numerical ratios.
On 2026-02-02 05:27, David Brown wrote:
On 02/02/2026 01:11, James Kuyper wrote:...
The US has three times as many native speakers of English than the
entire rest of the world combined, including the entire British
Commonwealth.
There are about 400 million native English speakers around the world, of
which about 230 are in the USA. Of course any such numbers will be
estimates, with surveys being from different years, but it certainly
looks like you overestimate the numerical ratios.
I looked at the Wikipedia article on English (language), which says that
US has 244,079,241 native speakers of English, and that the world has 391,286,346. When I did the calculations last night, that, came out to
75%, but for some reason it's 62% this morning. Perhaps I shouldn't post
that late at night.
It's still more US speakers than non-US speakers.
If that is the case, then that is a good reason for choosing US layout.
But AFAIK the differences between the US and the UK layouts are very small.-a And a large proportion of computer users use Latin keyboards,
even if their native languages use significantly different writing systems.-a So keyboard layout is often partially independent of other language and locale choices.
For example, I use a Norwegian layout
keyboard, but have my locale set to UK (with the region set to Norway).
Changing to the UK keyboard layout would be silly - it would mean some symbols are in a different place, and I could not type the Norwegian
letters I need when writing in Norwegian.
Changing to US layout would
be a step sillier, and there would be no advantages.
If you are used to a keyboard with a different writing system - say,
Greek - then you might find it convenient to change to a Latin based
layout for writing in English.
But I see no reason why you might have a
preference for US layout over UK - either would be fine.
On 02/02/2026 15:36, James Kuyper wrote:
I looked at the Wikipedia article on English (language), [...]
I also got my numbers from Wikipedia.-a I think there are a variety of numbers, depending on the dates and the source of the numbers.
One of my programmers has been working on converting our Windows user interface, written in 450,000 lines of C++, from Ascii to Unicode for
two years now.-a It was a one year project to start and his latest
estimate is another year to complete.
which I call TLW "tools-logics-window"
I publish it in dec. 2024, on my WWW site under URL:
<https://energokod.gda.pl/monografie/Arch.%20Prog.%20Nieuprzywilejowanych.pdf>
Op 01.feb.2026 om 10:06 schreef Lawrence DrCOOliveiro:
On Sat, 31 Jan 2026 16:10:38 -0600, Gary Scott wrote:
Flexibility is taken to a bit extreme in GINO graphics libraries
(a UK product), with a calendar that goes all the way back to
1066...:)
ldo@theon:~> date -d "1-Jan-1066"
Mon 01 Jan 1066 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-966"
Wed 01 Jan 0966 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-866"
Fri 01 Jan 0866 00:00:00 LMT
Now it becomes important to indicate whether the Gregorian or the Julian calendar is used.
Not all countries switched at the same date.
NOTE: Do not push any "business logic" in to your libs.
W dniu 24.01.2026 o-a04:35, Lynn McGuire pisze:
One of my programmers has been working on converting our Windows
user interface, written in 450,000 lines of C++, from Ascii to
Unicode for two years now.-a It was a one year project to start and
his latest estimate is another year to complete.
I think that this task should be named "rewrite". But I recommended
"clean up" instead. In the case "clean up" you have great opportunity
to make your app far better than previous. Modern industry approach,
is modularity. This is prove in many essential industry branch, and especially in IIww years.
On Mon, 2 Feb 2026 11:18:03 +0100, Fred. Zwarts wrote:
Op 01.feb.2026 om 10:06 schreef Lawrence DrCOOliveiro:
On Sat, 31 Jan 2026 16:10:38 -0600, Gary Scott wrote:
Flexibility is taken to a bit extreme in GINO graphics libraries
(a UK product), with a calendar that goes all the way back to
1066...:)
ldo@theon:~> date -d "1-Jan-1066"
Mon 01 Jan 1066 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-966"
Wed 01 Jan 0966 00:00:00 LMT
ldo@theon:~> date -d "1-Jan-866"
Fri 01 Jan 0866 00:00:00 LMT
Now it becomes important to indicate whether the Gregorian or the Julian
calendar is used.
ldo@theon:~> date -d 4-oct-1582
Mon 04 Oct 1582 00:00:00 LMT
ldo@theon:~> date -d 15-oct-1582
Fri 15 Oct 1582 00:00:00 LMT
Proleptic Gregorian.
Not all countries switched at the same date.
ldo@theon:~> ncal -s IT oct 1582
October 1582
Mo 1 18 25
Tu 2 19 26
We 3 20 27
Th 4 21 28
Fr 15 22 29
Sa 16 23 30
Su 17 24 31
ldo@theon:~> ncal -s GB oct 1582
October 1582
Mo 1 8 15 22 29
Tu 2 9 16 23 30
We 3 10 17 24 31
Th 4 11 18 25
Fr 5 12 19 26
Sa 6 13 20 27
Su 7 14 21 28
ldo@theon:~> ncal -s GB sep 1752
September 1752
Mo 18 25
Tu 1 19 26
We 2 20 27
Th 14 21 28
Fr 15 22 29
Sa 16 23 30
Su 17 24
On Mon, 2 Feb 2026 21:02:51 +0100
Efc|Efc#Jacek Marcin JaworskiEfc|Efc# <jmj@energokod.gda.pl> wrote:
W dniu 24.01.2026 o-a04:35, Lynn McGuire pisze:
One of my programmers has been working on converting our Windows
user interface, written in 450,000 lines of C++, from Ascii to
Unicode for two years now.-a It was a one year project to start and
his latest estimate is another year to complete.
I think that this task should be named "rewrite". But I recommended
"clean up" instead. In the case "clean up" you have great opportunity
to make your app far better than previous. Modern industry approach,
is modularity. This is prove in many essential industry branch, and
especially in IIww years.
It seems to me that industry trend in GUI programming is to stay as far
away from C++ as possible.
JS is a king.
C#, Swift, Kotlin are second choice.
Even Java is still used for new development in this feild, despite technically being almost as unsuitable as C++.
W dniu 3.02.2026 o-a09:54, Michael S pisze:
On Mon, 2 Feb 2026 21:02:51 +0100
Efc|Efc#Jacek Marcin JaworskiEfc|Efc# <jmj@energokod.gda.pl> wrote:
W dniu 24.01.2026 o-a04:35, Lynn McGuire pisze:
One of my programmers has been working on converting our Windows
user interface, written in 450,000 lines of C++, from Ascii to
Unicode for two years now.-a It was a one year project to start and
his latest estimate is another year to complete.
I think that this task should be named "rewrite". But I recommended
"clean up" instead. In the case "clean up" you have great opportunity
to make your app far better than previous. Modern industry approach,
is modularity. This is prove in many essential industry branch, and
especially in IIww years.
It seems to me that industry trend in GUI programming is to stay as far
away from C++ as possible.
JS is a king.
C#, Swift, Kotlin are second choice.
Even Java is still used for new development in this feild, despite
technically being almost as unsuitable as C++.
This is just pure hype: Apps word does not end on Android (all its apps
are written in some scripts lang)!!!
There are many areas where normal C++ programs are needed, and are not replaceable due to their time critical nature.
Even on desktop such simple app like text editor must be coded in C++ because in JS (VS Code) programmers see noticeable lags. The same is
true for huge programs like Text Processors, CAD, 3D Modeling, Graphic Editors, and many more.
Summary: only silly apps can be write in JS (or in other scripting
lang). Normal and professional programs must be written in compiling
lang, like modern object-oriented C++.
Summary: only silly apps can be write in JS (or in other scriptingActually, Javascript is a decent language and even has some
lang). Normal and professional programs must be written in compiling
lang, like modern object-oriented C++.
object-oriented features. I had to use it pretty heavily in a
project at work years ago.
W dniu 3.02.2026 o-a09:54, Michael S pisze:
Even Java is still used for new development in this feild, despite
technically being almost as unsuitable as C++.
This is just pure hype: Apps word does not end on Android (all its
apps are written in some scripts lang)!!!
On Tue, 3 Feb 2026 10:44:17 +0100, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
W dniu 3.02.2026 o-a09:54, Michael S pisze:You can run code written in C, C++ and other languages that compile to machine code, on Android.
Even Java is still used for new development in this feild, despiteThis is just pure hype: Apps word does not end on Android (all its
technically being almost as unsuitable as C++.
apps are written in some scripts lang)!!!
<https://developer.android.com/ndk>
W dniu 24.01.2026 o-a04:35, Lynn McGuire pisze:
One of my programmers has been working on converting our Windows user
interface, written in 450,000 lines of C++, from Ascii to Unicode for
two years now.-a It was a one year project to start and his latest
estimate is another year to complete.
I think that this task should be named "rewrite". But I recommended
"clean up" instead. In the case "clean up" you have great opportunity to make your app far better than previous. Modern industry approach, is modularity. This is prove in many essential industry branch, and
especially in IIww years.
You can make your app "modular", by simply respect following rules:
1. Split your code in to 3 parts:
1) Business Logic classes;
2) Tool classes;
3) Window and widget classes.
This is my "programming pattern" which I call TLW "tools-logics-window" pattern, and it replace more specialised MVC "model-view-controler"
pattern.
2. Split your code in to few static libs.
NOTE: Do not push any "business logic" in to your libs. Libs must be
acted only as "tools". All "business logic" should remain in your core app. NOTE: When you have static libs, then you can develop your libs and
prog. simultaneously, because they will not interfere with other
projects (other projects can work normally and can be upgraded later).
3. Split your code in to many dynamically loaded plug-ins.
NOTE 1: Create your plug-ins only in 3 cases:
1) for file type and network protocol formats (for tool classes);
2) for new algorithms (for logic classes);
3) for new widgets (for windows classes).
Note 2: In many cases one plug-in provide together new widget and new algorithm;
4. Make your libs and plug-in rest code independent as far as possible
and make them to use minimal set of 3rd party libs dependencies.
NOTE: This mean that your libs and plug-ins (for tools and logic
classes) should not be depended of GUI libs, nor any platform specific
libs. In order to do this all build in types and used classes should be renamed. Then, if necessary, renamed type can be easily expanded by make
it normal class (with earlier renamed class as a parent).
NOTE: Above I invent and covered in my monograph under title "Arch.
Prog. Nieuprzywilejowanych" (in eng.: "Architecture of Unprivileged Programs"). I publish it in dec. 2024, on my WWW site under URL:
<https://energokod.gda.pl/monografie/Arch.%20Prog. %20Nieuprzywilejowanych.pdf>
One more hint: Buy great and thin Stroustrup book "A Tour of C++ (C++ In-Depth Series" - it is all about basic C++ concepts but focused on C+
+20. Then consider what "C++ modern parts" are worth to apply for your project.
On Mon, 2 Feb 2026 21:02:51 +0100
Efc|Efc#Jacek Marcin JaworskiEfc|Efc# <jmj@energokod.gda.pl> wrote:
W dniu 24.01.2026 o-a04:35, Lynn McGuire pisze:
One of my programmers has been working on converting our Windows
user interface, written in 450,000 lines of C++, from Ascii to
Unicode for two years now.-a It was a one year project to start and
his latest estimate is another year to complete.
I think that this task should be named "rewrite". But I recommended
"clean up" instead. In the case "clean up" you have great opportunity
to make your app far better than previous. Modern industry approach,
is modularity. This is prove in many essential industry branch, and
especially in IIww years.
It seems to me that industry trend in GUI programming is to stay as far
away from C++ as possible.
JS is a king.
C#, Swift, Kotlin are second choice.
Even Java is still used for new development in this feild, despite technically being almost as unsuitable as C++.
But C++ is strictly legacy, no new, from scratch GUI development is done
in this language for something like 15 years.
Of course, the statement above is "at large". The world is a big
place and one can always find one developer or one hundred or ten
thousands that make unusual sub-optimal choices.
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB.
Nothing besides C++ has the oomph and speed to make this happen.
W dniu 3.02.2026 o-a22:32, Lawrence DrCOOliveiro pisze:
On Tue, 3 Feb 2026 10:44:17 +0100, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
W dniu 3.02.2026 o-a09:54, Michael S pisze:
Even Java is still used for new development in this feild,
despite technically being almost as unsuitable as C++.
This is just pure hype: Apps word does not end on Android (all its
apps are written in some scripts lang)!!!
You can run code written in C, C++ and other languages that compile
to machine code, on Android.
<https://developer.android.com/ndk>
I can bet with you that you will failed when you ask your boss for that!
On Tue, 3 Feb 2026 17:28:35 -0600, Lynn McGuire wrote:
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB.
Nothing besides C++ has the oomph and speed to make this happen.
Lots of Pythoneers are doing data science at this sort of scale.
On 2/3/2026 6:14 PM, Lawrence DrCOOliveiro wrote:
On Tue, 3 Feb 2026 17:28:35 -0600, Lynn McGuire wrote:
I am swinging huge datasets for simulation models from 1 MB to
1,000 MB. Nothing besides C++ has the oomph and speed to make this
happen.
Lots of Pythoneers are doing data science at this sort of scale.
Been there, done that. I really doubt that any Python apps are doing
the level of what I do. I would be careful telling people that
Python apps run anywhere near the speed of C++.
On Tue, 3 Feb 2026 22:56:28 +0100, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
W dniu 3.02.2026 o-a22:32, Lawrence DrCOOliveiro pisze:
On Tue, 3 Feb 2026 10:44:17 +0100, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
W dniu 3.02.2026 o-a09:54, Michael S pisze:
Even Java is still used for new development in this feild,
despite technically being almost as unsuitable as C++.
This is just pure hype: Apps word does not end on Android (all its
apps are written in some scripts lang)!!!
You can run code written in C, C++ and other languages that compile
to machine code, on Android.
<https://developer.android.com/ndk>
I can bet with you that you will failed when you ask your boss for that!
I am my boss. And I have done it.
How much is your bet worth?
On 2/3/2026 2:54 AM, Michael S wrote:
On Mon, 2 Feb 2026 21:02:51 +0100
Efc|Efc#Jacek Marcin JaworskiEfc|Efc# <jmj@energokod.gda.pl> wrote:
W dniu 24.01.2026 o-a04:35, Lynn McGuire pisze:
One of my programmers has been working on converting our Windows
user interface, written in 450,000 lines of C++, from Ascii to
Unicode for two years now.-a It was a one year project to start and
his latest estimate is another year to complete.
I think that this task should be named "rewrite". But I recommended
"clean up" instead. In the case "clean up" you have great
opportunity to make your app far better than previous. Modern
industry approach, is modularity. This is prove in many essential
industry branch, and especially in IIww years.
It seems to me that industry trend in GUI programming is to stay as
far away from C++ as possible.
JS is a king.
C#, Swift, Kotlin are second choice.
Even Java is still used for new development in this feild, despite technically being almost as unsuitable as C++.
But C++ is strictly legacy, no new, from scratch GUI development is
done in this language for something like 15 years.
Of course, the statement above is "at large". The world is a big
place and one can always find one developer or one hundred or ten
thousands that make unusual sub-optimal choices.
I am swinging huge datasets for simulation models from 1 MB to 1,000
MB. Nothing besides C++ has the oomph and speed to make this happen.
Lynn
W dniu 3.02.2026 o-a15:47, Chris Ahlstrom pisze:
Summary: only silly apps can be write in JS (or in other scriptingActually, Javascript is a decent language and even has some
lang). Normal and professional programs must be written in compiling
lang, like modern object-oriented C++.
object-oriented features. I had to use it pretty heavily in a
project at work years ago.
That must be night mare! But apparently you gain some wisdom and decide
to learn C++.
We have good proverb in polish which illustrate your
experience:
"Nie ma tego z+eego co by na dobre nie wysz+eo."
, in eng.:
"There is not such evil which finally will not turn to be good".
On Tue, 3 Feb 2026 20:17:04 -0600, Lynn McGuire wrote:
On 2/3/2026 6:14 PM, Lawrence DrCOOliveiro wrote:
On Tue, 3 Feb 2026 17:28:35 -0600, Lynn McGuire wrote:
I am swinging huge datasets for simulation models from 1 MB to
1,000 MB. Nothing besides C++ has the oomph and speed to make this
happen.
Lots of Pythoneers are doing data science at this sort of scale.
Been there, done that. I really doubt that any Python apps are doing
the level of what I do. I would be careful telling people that
Python apps run anywhere near the speed of C++.
Python has number-crunching engines like NumPy to do the grunt work.
The question is, how long does the overall job take: the C++ code may
run a bit faster, but it takes several times longer to write.
You can
get a lot of analyses done in that time in Python. Particularly since
it is very easy to experiment with just a few lines of code, before committing yourself to more elaborate analyses along particular lines.
And then you have access to visualization tools like Matplotlib to
view the results. And again, it is much quicker to generate displays
from that in Python than it would be to write C++ code.
On Tue, 3 Feb 2026 17:28:35 -0600, Lynn McGuire wrote:
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB.
Nothing besides C++ has the oomph and speed to make this happen.
Lots of Pythoneers are doing data science at this sort of scale.
anything related to speed
that C++ can do, C can do as well, but I would be very surprised if
there no other options beyond C
at very least, anything related to speed
that C++ can do, C can do as well, but I would be very surprised if
there no other options beyond C
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB.
Nothing besides C++ has the oomph and speed to make this happen.
Lawrence DrCOOliveiro wrote this post by blinking in Morse code:
On Tue, 3 Feb 2026 20:17:04 -0600, Lynn McGuire wrote:
On 2/3/2026 6:14 PM, Lawrence DrCOOliveiro wrote:
On Tue, 3 Feb 2026 17:28:35 -0600, Lynn McGuire wrote:
I am swinging huge datasets for simulation models from 1 MB to
1,000 MB. Nothing besides C++ has the oomph and speed to make this
happen.
Lots of Pythoneers are doing data science at this sort of scale.
Been there, done that. I really doubt that any Python apps are doing
the level of what I do. I would be careful telling people that
Python apps run anywhere near the speed of C++.
Python has number-crunching engines like NumPy to do the grunt work.
The question is, how long does the overall job take: the C++ code may
run a bit faster, but it takes several times longer to write.
Bullshit.
You can
get a lot of analyses done in that time in Python. Particularly since
it is very easy to experiment with just a few lines of code, before
committing yourself to more elaborate analyses along particular lines.
You can
do that in any language.
And then you have access to visualization tools like Matplotlib to
view the results. And again, it is much quicker to generate displays
from that in Python than it would be to write C++ code.
AI Overview
Several C++ plotting libraries are available, ranging from
simple, header-only solutions to comprehensive, feature-rich
systems. Key options include general-purpose libraries,
wrappers for existing tools, and those designed for real-time
visualization.
Here are some popular C++ plotting libraries:
Matplotlib-cpp: This is possibly the simplest C++ plotting
library, designed to mimic the API of the popular Python
matplotlib library. It is a header-only library that acts as a
C++ wrapper around the Python matplotlib backend, so a Python
installation is required at runtime.
Matplot++: A modern C++ graphics library that offers
interactive plotting and a compact syntax, supporting generic
backends including gnuplot and the web-optimized Bokeh. It
provides a wide range of plot categories suitable for
scientific data visualization.
sciplot: Another modern, header-only library that aims to make
plotting in C++ as easy as in higher-level languages like
Python. It uses gnuplot as a backend dependency at runtime to
generate high-quality graphs and requires a C++17 capable
compiler.
Gnuplot (via C++ interface): You can directly interface with
the standalone, classic plotting program gnuplot using
libraries like gnuplot-iostream or similar wrappers. This
approach leverages gnuplot's powerful, domain-specific
plotting language.
Qt Charts: If you are already building a cross-platform
desktop application using the Qt framework, the Qt Charts
module is a well-integrated option that provides robust
charting capabilities.
ImPlot: An extension for the popular Dear ImGui library, ideal
for integrating plots directly into performance-oriented,
real-time GUI applications, such as internal tools or game
development debugging interfaces.
Visualization Toolkit (VTK): A powerful open-source library
for 3D graphics, image processing, and visualization. It is a
comprehensive, low-level option best suited for complex
scientific visualization needs.
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On Tue, 3 Feb 2026 17:28:35 -0600, Lynn McGuire wrote:
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB. >>> Nothing besides C++ has the oomph and speed to make this happen.
Lots of Pythoneers are doing data science at this sort of scale.
Even "R" can handle datasets larger than that.
On Tue, 3 Feb 2026 17:28:35 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
On 2/3/2026 2:54 AM, Michael S wrote:
On Mon, 2 Feb 2026 21:02:51 +0100
Efc|Efc#Jacek Marcin JaworskiEfc|Efc# <jmj@energokod.gda.pl> wrote:
W dniu 24.01.2026 o-a04:35, Lynn McGuire pisze:
One of my programmers has been working on converting our Windows
user interface, written in 450,000 lines of C++, from Ascii to
Unicode for two years now.-a It was a one year project to start and
his latest estimate is another year to complete.
I think that this task should be named "rewrite". But I recommended
"clean up" instead. In the case "clean up" you have great
opportunity to make your app far better than previous. Modern
industry approach, is modularity. This is prove in many essential
industry branch, and especially in IIww years.
It seems to me that industry trend in GUI programming is to stay as
far away from C++ as possible.
JS is a king.
C#, Swift, Kotlin are second choice.
Even Java is still used for new development in this feild, despite
technically being almost as unsuitable as C++.
But C++ is strictly legacy, no new, from scratch GUI development is
done in this language for something like 15 years.
Of course, the statement above is "at large". The world is a big
place and one can always find one developer or one hundred or ten
thousands that make unusual sub-optimal choices.
I am swinging huge datasets for simulation models from 1 MB to 1,000
MB. Nothing besides C++ has the oomph and speed to make this happen.
Lynn
I am not sure what "swinging" means in this context and whether other languages can do it or not (at very least, anything related to speed
that C++ can do, C can do as well, but I would be very surprised if
there no other options beyond C).
But all that sounds off topic.
The topic is user interface code (a.k.a. GUI) rather than "swinging".
C++ used to be a popular choice for coding user interfaces, but it
ceased to be popular long time ago.
W dniu 4.02.2026 o-a13:24, Michael S pisze:
at very least, anything related to speed
that C++ can do, C can do as well, but I would be very surprised if
there no other options beyond C
There is also FreePascal:
<https://www.freepascal.org>
But I am unsure if it has templates, but I am sure that D it has.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB.
Nothing besides C++ has the oomph and speed to make this happen.
Speed differences between compiled languages are reltively small.
But Fortran (where I am reading this) can certainly do so. A pity
you missed out on Fortran's development in the last 35 years.
On 2/4/2026 1:20 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB. >>> Nothing besides C++ has the oomph and speed to make this happen.
Speed differences between compiled languages are reltively small.
But Fortran (where I am reading this) can certainly do so. A pity
you missed out on Fortran's development in the last 35 years.
We will see.
When I finish converting the 800,000 lines of F77 code to
C++ in my calculation engine, I will run a timing test using my 659 +
100 = 759 benchmark files. I just restarted this project after a year
or two of working on customers problems and demands.
I have over 100,000 lines of F77 converted to C++ now and the input
parser of my chemical data regression tool is fully working.
We are not 64 bit yet. 1,000 MB is about the largest dataset we can
swing in Win32 due to our inefficiency in managing memory.
On 2/4/2026 10:16 AM, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
There is also FreePascal:
<https://www.freepascal.org>
But I am unsure if it has templates, but I am sure that D it has.
Nope. I moved from Turbo Pascal to C in 1987 and never looked back.
Parsers are a field where Fortran does not shine, although
allocatable characters have made this much easier.
We use gnuplot to generate graphs in our software.
Parsers are a field where Fortran does not shine, although allocatable characters have made this much easier.
On Wed, 4 Feb 2026 16:53:38 -0600, Lynn McGuire wrote:64-bit Windows supports 32-bit programs rather well. The user does not
We are not 64 bit yet. 1,000 MB is about the largest dataset we can
swing in Win32 due to our inefficiency in managing memory.
WouldnrCOt a rCLrealrCY computer (i.e. running Linux) do better? Have you compared?
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 2/4/2026 1:20 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB. >>>> Nothing besides C++ has the oomph and speed to make this happen.
Speed differences between compiled languages are reltively small.
But Fortran (where I am reading this) can certainly do so. A pity
you missed out on Fortran's development in the last 35 years.
We will see.
We will not see, because you made the decision to switch to C++
instead of gradually introducing modern Fortran features in your
code. There will be no benchmark to test against.
On 2/4/2026 6:24 AM, Michael S wrote:
On Tue, 3 Feb 2026 17:28:35 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
On 2/3/2026 2:54 AM, Michael S wrote:
On Mon, 2 Feb 2026 21:02:51 +0100
Efc|Efc#Jacek Marcin JaworskiEfc|Efc# <jmj@energokod.gda.pl> wrote:
W dniu 24.01.2026 o-a04:35, Lynn McGuire pisze:
One of my programmers has been working on converting our Windows
user interface, written in 450,000 lines of C++, from Ascii to
Unicode for two years now.-a It was a one year project to start
and his latest estimate is another year to complete.
I think that this task should be named "rewrite". But I
recommended "clean up" instead. In the case "clean up" you have
great opportunity to make your app far better than previous.
Modern industry approach, is modularity. This is prove in many
essential industry branch, and especially in IIww years.
It seems to me that industry trend in GUI programming is to stay
as far away from C++ as possible.
JS is a king.
C#, Swift, Kotlin are second choice.
Even Java is still used for new development in this feild, despite
technically being almost as unsuitable as C++.
But C++ is strictly legacy, no new, from scratch GUI development
is done in this language for something like 15 years.
Of course, the statement above is "at large". The world is a big
place and one can always find one developer or one hundred or ten
thousands that make unusual sub-optimal choices.
I am swinging huge datasets for simulation models from 1 MB to
1,000 MB. Nothing besides C++ has the oomph and speed to make this
happen.
Lynn
I am not sure what "swinging" means in this context and whether
other languages can do it or not (at very least, anything related
to speed that C++ can do, C can do as well, but I would be very
surprised if there no other options beyond C).
But all that sounds off topic.
The topic is user interface code (a.k.a. GUI) rather than
"swinging". C++ used to be a popular choice for coding user
interfaces, but it ceased to be popular long time ago.
My variant of "swinging" means to load an entire dataset into memory
which used to be very common for desktop software like mine.
Lynn
On Thu, 5 Feb 2026 07:23:41 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Parsers are a field where Fortran does not shine, although allocatable
characters have made this much easier.
Another field where Fortran "does not shine" is handling of huge uni-dimensional arrays.
On Wed, 4 Feb 2026 16:43:53 -0600, Lynn McGuire wrote:
We use gnuplot to generate graphs in our software.
Matplotlib examples gallery: <https://matplotlib.org/stable/gallery/index>
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 2/4/2026 1:20 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB. >>>> Nothing besides C++ has the oomph and speed to make this happen.
Speed differences between compiled languages are reltively small.
But Fortran (where I am reading this) can certainly do so. A pity
you missed out on Fortran's development in the last 35 years.
We will see.
We will not see, because you made the decision to switch to C++
instead of gradually introducing modern Fortran features in your
code. There will be no benchmark to test against.
When I finish converting the 800,000 lines of F77 code to
C++ in my calculation engine, I will run a timing test using my 659 +
100 = 759 benchmark files. I just restarted this project after a year
or two of working on customers problems and demands.
That could be interesting. With such a conversion test, it would
also be interesting to see how many bugs were uncovered in the
conversion process, and how many new ones were introduced. You
may know the first number (although I totally understand if you don't
want to share), but you may never know the second one.
Do you use tools like valgrind and sanitizers?
I have over 100,000 lines of F77 converted to C++ now and the input
parser of my chemical data regression tool is fully working.
Parsers are a field where Fortran does not shine, although allocatable characters have made this much easier.
On Thu, 5 Feb 2026 07:23:41 -0000 (UTC), Thomas Koenig wrote:
Parsers are a field where Fortran does not shine, although
allocatable characters have made this much easier.
On a *nix system, it is usual to delegate common janitorial tasks
(like parsing) to open-source libraries that already handle such jobs.
On 2/5/2026 3:14 AM, Lawrence DrCOOliveiro wrote:
On a *nix system, it is usual to delegate common janitorial tasks
(like parsing) to open-source libraries that already handle such
jobs.
Parsing is not just looking at input. It is also about converting
that input and storing it properly in the proper data storage areas
in the dataset.
On Thu, 5 Feb 2026 16:01:05 -0600, Lynn McGuire wrote:
On 2/5/2026 3:14 AM, Lawrence DrCOOliveiro wrote:
On a *nix system, it is usual to delegate common janitorial tasks
(like parsing) to open-source libraries that already handle such
jobs.
Parsing is not just looking at input. It is also about converting
that input and storing it properly in the proper data storage areas
in the dataset.
Look at common parser libraries. They are designed to deal with
precisely these sorts of issues.
Here <https://textx.github.io/Arpeggio/latest/> is one I have used.
I can tell that you have never worked on a large software package.
You do not rip it up just to modernize a section of the code.
On Thu, 5 Feb 2026 20:22:37 -0600, Lynn McGuire wrote:
I can tell that you have never worked on a large software package.
You do not rip it up just to modernize a section of the code.
Stop trying to cast aspersions on those offering advice.
If it can replace a bunch of code you have to rewrite anyway, it
should be worth it.
On 2/5/2026 4:30 PM, Lawrence DrCOOliveiro wrote:
I can tell that you have never worked on a large software package. You
do not rip it up just to modernize a section of the code.
What I meant is that the calender should be added in the output.
You are really telling me to rip out a working feature in my
software and spend months replacing it ???
The only conversion problem that I am worried about is that I have
Fortran 66 interpreter built into my software for my customers to write custom calculations embedded in their datasets attached to any type of object. I will need to write a converter for the F66 format statements
to C formats.
Not a big deal though. Some of my customers have over
10,000 lines of F66 code in their datasets. And yes, the F66 parser is written in F77 code, we wrote that back in 1982.
On 2/4/2026 9:44 AM, Scott Lurndal wrote:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On Tue, 3 Feb 2026 17:28:35 -0600, Lynn McGuire wrote:
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB. >>>> Nothing besides C++ has the oomph and speed to make this happen.
Lots of Pythoneers are doing data science at this sort of scale.
Even "R" can handle datasets larger than that.
We are not 64 bit yet. 1,000 MB is about the largest dataset we can
swing in Win32 due to our inefficiency in managing memory. We do
compress all strings above 1,000 bytes which means that our datasets are actually 2X to 3X bigger than the binary version of the dataset.
I haven't used your software, but I have used Aspen (only very
little) and found it horrible. How it is possible for a solution to
diverge when the starting solution is already converged is beyond
me, all explanations that occur to me could be considered insults,
so I am not toing to go into that. That was worst; I hope your
software does better.
But the F66 interpreter in Aspen was a close second; IIRC, it was
not even possible to declare variables. Argh.
On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:
I haven't used your software, but I have used Aspen (only very
little) and found it horrible. How it is possible for a solution to
diverge when the starting solution is already converged is beyond
me, all explanations that occur to me could be considered insults,
so I am not toing to go into that. That was worst; I hope your
software does better.
But the F66 interpreter in Aspen was a close second; IIRC, it was
not even possible to declare variables. Argh.
How do these tools compare to something like
<https://nwchemgit.github.io>?
Lawrence DrCOOliveiro <ldo@nz.invalid> schrieb:
On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:
I haven't used your software, but I have used Aspen (only very
little) and found it horrible. How it is possible for a solution to
diverge when the starting solution is already converged is beyond
me, all explanations that occur to me could be considered insults,
so I am not toing to go into that. That was worst; I hope your
software does better.
But the F66 interpreter in Aspen was a close second; IIRC, it was
not even possible to declare variables. Argh.
How do these tools compare to something like >><https://nwchemgit.github.io>?
How does a hacksaw compare to a screwdriver?
Thomas Koenig <tkoenig@netcologne.de> writes:
Lawrence DrCOOliveiro <ldo@nz.invalid> schrieb:
On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:
I haven't used your software, but I have used Aspen (only very
little) and found it horrible. How it is possible for a solution
to diverge when the starting solution is already converged is
beyond me, all explanations that occur to me could be considered
insults, so I am not toing to go into that. That was worst; I
hope your software does better.
But the F66 interpreter in Aspen was a close second; IIRC, it was
not even possible to declare variables. Argh.
How do these tools compare to something like >><https://nwchemgit.github.io>?
How does a hacksaw compare to a screwdriver?
A screwdriver is vodka and orange juice. A hacksaw has orange soda
as well.
Lawrence DrCOOliveiro <ldo@nz.invalid> schrieb:
On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:
I haven't used your software, but I have used Aspen (only very
little) and found it horrible. How it is possible for a solution
to diverge when the starting solution is already converged is
beyond me, all explanations that occur to me could be considered
insults, so I am not toing to go into that. That was worst; I hope
your software does better.
But the F66 interpreter in Aspen was a close second; IIRC, it was
not even possible to declare variables. Argh.
How do these tools compare to something like >><https://nwchemgit.github.io>?
How does a hacksaw compare to a screwdriver?
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 2/4/2026 9:44 AM, Scott Lurndal wrote:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On Tue, 3 Feb 2026 17:28:35 -0600, Lynn McGuire wrote:
I am swinging huge datasets for simulation models from 1 MB to 1,000 MB. >>>>> Nothing besides C++ has the oomph and speed to make this happen.
Lots of Pythoneers are doing data science at this sort of scale.
Even "R" can handle datasets larger than that.
We are not 64 bit yet. 1,000 MB is about the largest dataset we can
swing in Win32 due to our inefficiency in managing memory. We do
compress all strings above 1,000 bytes which means that our datasets are
actually 2X to 3X bigger than the binary version of the dataset.
Wow, this must hurt, both for speed and complexity...
Depending on what your database is like, it might make sense to
convert into a suitable binary format, map it into your address
space (I am fairly sure that Windows can do memory-mapped I/O,
although I am *not* a Windows person, at least not as far as
programming is concerned) and then immediately do things with it.
You could then reduce your startup time by only "recompiling"
from the text representation when needed.
If this makes sense to your application or not, I don't know (of course) because I do not know what exactly your database does and does not do.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
The only conversion problem that I am worried about is that I have
Fortran 66 interpreter built into my software for my customers to write
custom calculations embedded in their datasets attached to any type of
object. I will need to write a converter for the F66 format statements
to C formats.
I haven't used your software, but I have used Aspen (only very
little) and found it horrible. How it is possible for a solution to
diverge when the starting solution is already converged is beyond
me, all explanations that occur to me could be considered insults,
so I am not toing to go into that. That was worst; I hope your
software does better.
But the F66 interpreter in Aspen was a close second; IIRC, it was
not even possible to declare variables. Argh.
Not a big deal though. Some of my customers have over
10,000 lines of F66 code in their datasets. And yes, the F66 parser is
written in F77 code, we wrote that back in 1982.
If you used Fortran 77's runtime including internal formats,
that must have made your job a lot easier. Converting this to
C formats... well, that is tricky. Consider
REAL A
DIMENSION A(10)
READ (10,'(4F12.5)') A
It is not possible to translate this into C printf formats
(which you seem to imply above), you need logic to handle
the format reversion. Also, the handling of field overflow
(C just extends things, Fortran inserts asterisks) is tricky.
Why not just use the f2c runtime?
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:...
The only conversion problem that I am worried about is that I have
Fortran 66 interpreter built into my software for my customers to write
custom calculations embedded in their datasets attached to any type of
object. I will need to write a converter for the F66 format statements
to C formats.
I haven't used your software, but I have used Aspen (only very
little) and found it horrible. How it is possible for a solution to
diverge when the starting solution is already converged is beyond
me, all explanations that occur to me could be considered insults,
so I am not toing to go into that. That was worst; I hope your
software does better.
But the F66 interpreter in Aspen was a close second; IIRC, it was
not even possible to declare variables. Argh.
On Sat, 7 Feb 2026 19:15:07 -0000 (UTC), Thomas Koenig wrote:
I haven't used your software, but I have used Aspen (only very
little) and found it horrible. How it is possible for a solution to
diverge when the starting solution is already converged is beyond
me, all explanations that occur to me could be considered insults,
so I am not toing to go into that. That was worst; I hope your
software does better.
But the F66 interpreter in Aspen was a close second; IIRC, it was
not even possible to declare variables. Argh.
How do these tools compare to something like
<https://nwchemgit.github.io>?
On 2/7/2026 1:15 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:...
The only conversion problem that I am worried about is that I have
Fortran 66 interpreter built into my software for my customers to write
custom calculations embedded in their datasets attached to any type of
object. I will need to write a converter for the F66 format statements
to C formats.
I haven't used your software, but I have used Aspen (only very
little) and found it horrible. How it is possible for a solution to
diverge when the starting solution is already converged is beyond
me, all explanations that occur to me could be considered insults,
so I am not toing to go into that. That was worst; I hope your
software does better.
But the F66 interpreter in Aspen was a close second; IIRC, it was
not even possible to declare variables. Argh.
Huh, that does not make sense. One needs variables to decomplicate
complex calculations. We even support common blocks in our F66
interpreter user code so that variables can be stored from one iteration
to the next.
On 2/7/2026 1:15 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
I haven't used your software, but I have used Aspen (only very
little) and found it horrible. How it is possible for a solution to
diverge when the starting solution is already converged is beyond
me, all explanations that occur to me could be considered insults,
so I am not toing to go into that. That was worst; I hope your
software does better.
We force all loops in simulations to go through a minimum of three iterations. What appears to be converged may not be converged in reality.
We even support common blocks in our F66 interpreter user code so
that variables can be stored from one iteration to the next.
On 2/7/2026 2:34 PM, Lawrence DrCOOliveiro wrote:
How do these tools compare to something like
<https://nwchemgit.github.io>?
That is a different world. This is me.
https://www.winsim.com/design.html
On Mon, 9 Feb 2026 15:33:12 -0600, Lynn McGuire wrote:
On 2/7/2026 2:34 PM, Lawrence DrCOOliveiro wrote:
How do these tools compare to something like
<https://nwchemgit.github.io>?
That is a different world. This is me.
https://www.winsim.com/design.html
I noticed that it says rCLMicrosoft-< Windows-< has become the standard
for desktop graphical computingrCY, and it seems like the text hasnrCOt
been updated since about October 2014. I would say that assertion is
getting a bit long in the tooth, wouldnrCOt you agree?
I had a look around, and this popped up <https://dwsim.org/>. It
certainly seems to have better cross-platform support.
Also I see yourCOre listed here <https://en.wikipedia.org/wiki/List_of_chemical_process_simulators>,
along with a bunch of other alternatives. And here <https://www.simulatelive.com/product-reviews/simulation/review-of-open-source-process-simulators>
is a review of various open-source products (including DWSIM), which concludes that they lack nothing compared to the proprietary ones.
On Mon, 9 Feb 2026 15:32:10 -0600, Lynn McGuire wrote:
We even support common blocks in our F66 interpreter user code so
that variables can be stored from one iteration to the next.
I expect your customers would appreciate having an extension language
that works at a somewhat higher level than Fortran -- and an
antediluvian version of Fortran, at that.
One of my long term goals is to support a Basic interpreter in my calculation engine.
It is very hard to compete with the price of free.
DWSIM has a very loyal following and many of them participate in the programming of new features.
On Tue, 10 Feb 2026 18:57:21 -0600, Lynn McGuire wrote:
It is very hard to compete with the price of free.
Tell that to the sellers of bottled water. ;)
DWSIM has a very loyal following and many of them participate in the
programming of new features.
ThatrCOs the way Open Source should be. Too often we see people
complaining that some app doesnrCOt have features that they desperately
need, so they have to go back to paid proprietary software. Completely overlooking the fact that, if they put some of that money they would
pay the proprietary software vendor towards sponsoring the development
of some of the features they need, the result would benefit everybody.
On Tue, 10 Feb 2026 20:07:37 -0600, Lynn McGuire wrote:
One of my long term goals is to support a Basic interpreter in my
calculation engine.
Gosh. That would take you up to the Middle Ages.
On 11/02/2026 06:57, Lawrence DrCOOliveiro wrote:
On Tue, 10 Feb 2026 18:57:21 -0600, Lynn McGuire wrote:
It is very hard to compete with the price of free.
Tell that to the sellers of bottled water. ;)
DWSIM has a very loyal following and many of them participate in the
programming of new features.
ThatrCOs the way Open Source should be. Too often we see people
complaining that some app doesnrCOt have features that they desperately
need, so they have to go back to paid proprietary software. Completely
overlooking the fact that, if they put some of that money they would
pay the proprietary software vendor towards sponsoring the development
of some of the features they need, the result would benefit everybody.
But would that be an advantage to that user? Benefiting everybody means benefiting your competition as well. I have no idea how competitive or cooperative the users of chemical simulators is, but it is not always
the case that "benefits everyone" is a win for the person or company stumping up the cash.
kIn many markets, there is room for pure
closed-source commercial software, pure free and open source software,
and many combinations in between. Simplistic "everybody wins" arguments
are rarely applicable.
Thomas Koenig wrote:
Radey Shouman <shouman@comcast.net> schrieb:
The size of the integer type was specified to be the same as the
size of the real type. The real type need not be 32-bit floating
point, but that is certainly the way to bet.
A famous counter-example: Cray's 64-bit REALs.
And the Univac's 36 bit reals.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 19:26:12 |
| Calls: | 810 |
| Calls today: | 1 |
| Files: | 1,287 |
| D/L today: |
10 files (21,017K bytes) |
| Messages: | 193,989 |