On 02.02.2024 16:18, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:

(Ah, I spotted my person being addressed again by Bart.)

>
>> It certainly won't for your stuff, or SL's, or JP's, or TR's, as you
>> all seem to delight in wheeling out the most complex scenarios you can find.

No. The "complex" scenarios - I called them professional projects as
opposed to toy projects - I mentioned explicitly only because _you_
(for obvious argumentation manoeuvre) asked me how my projects would
look like. (You continuously expose such a lousy argumentation habit
that it hurts.)

Actually, all professional projects I did myself, or that I observed
others were doing, were non-trivial (some even complex, yes). One
point of professional software engineering and project management is
managing any existing complexity. (There's many means for that; one
had been talked about, modularization (or other divide and conquer
techniques).)

> [...]
>
>>
>> That is another aspect you might do well to learn how to do: KISS. [...]

I suppose we have a different view about what KISS is. In my book
it is (for example) to use existing, simple and established tools
instead of reinventing the wheel and (even needlessly) implement
my own version before I can start with my project.

>
> KISS is a good principle to follow, and while I cannot again speak
> for David, it's a principle followed by most programmers I've worked
> with. That doesn't mean throwing away perfectly usable tools
> (one can easily make KISS-compliant makefiles, for example).

Not all projects can be kept simple. But certainly we try to not
make it more complex than necessary.

>> I'm not suggesting replacing make, only to reduce its involvement.

(And yet I've seen no sensible argument from you why - only that
you don't know it, and that you don't like it, and that it don't
fit you.)

> [...]

Janis

On 02.02.2024 23:12, bart wrote:
> On 02/02/2024 21:42, Lawrence D'Oliveiro wrote:
>> On Fri, 2 Feb 2024 13:47:25 +0000, bart wrote:
>>
>>> That's true: only 47 years in computing, and 42 years of evolving,
>>> implementing and running my systems language.
>>
>> On how many different platforms?
>
> I started in 1976. I started using Windows for my products in 1995
> because all my potential customers could buy an off-the-shelf Windows
> PC.

And that is actually the problem that folks have tried to make clear
to you. Being so long in a bubble, working on an a technically lousy
inferior system that decades long did not even manage (maybe not even
intend) to catch up with any state-of-the-art techniques; what do you
expect?

> Linux was nowhere. Unix was only in academia, I think; nowhere
> relevant to me anyway.

There was a special license for academia that made it possible to
spread UNIX quickly through academia. But that is just one aspect
why it disseminated so fast.

I don't know about you, whether you have an academic technical
background, whether you had the chance to try out UNIX or the BSD
variant these days.

Myself I already knew a couple OSes (for PCs, some not even worth
to call them OS, for medium scale systems, and also for mainframes)
before I had my first contact with a Unix system. With that systems
and OS background it was easy to strive for the better ones; from
the ones I met it was Unix. (BTW, I observed a similar enthusiasm
with a friend of mine, a long year hardcore MS DOS user, when he
got his fingers onto a Unix system.) You might imagine what a joy
it thus was when Linux and the GNU tools appeared, a powerful and
reliable(!) system and OS base, and even (almost) for free.

(For you, I dare to say, it's obviously far too late. That ship has
sailed. If you'd have strived for a broader experience in your early
days it would certainly be a different situation. And I am not only
speaking about systems and OSes, also all project management, tools,
methods, and strategy themes. Just continue your way in your scope.)

> [...]
>
> Why do you consider that fair game, but people hate if when anyone
> criticises Unix?

I cannot speak for "people". Myself I name any issues I see; Unix
issues are not exempt from that. - I have even a printed version of
"The UNIX - HATERS Handbook" in my bookshelf (though a lot of its
content is meanwhile outdated, it doesn't apply any more). - And I
can certainly collect a page full of deficiencies I see with Linux.
But so what? (For the MS platforms I could probably "fill a book".)
Yet, in past decades, I haven't seen any serious competitor to Unix.
(Note: When I'm saying that I am not considering e.g. supercomputers
doing e.g. massive hydrodynamic computations. But even in this area
there's meanwhile also Linux clusters running.)

Janis

On 02.02.2024 16:26, David Brown wrote:
>
> [...] The Eclipse folk are experts at making an editor and IDE, [...]

I have to disagree with this bit.

At the time I used it[*] they were even incapable of integrating
an existing Vim editor (even a standard Vi would have been okay
for me, but no). - Instead they supported/embedded an own trashy
vi clone with a small subset of the vi feature (not to speak about
the vim features).

Janis

[*] Disclaimer: my Eclipse/Java episode was around 2005 and I
don't know the current state, whether that has changed meanwhile,
or got better.

On 03/02/2024 13:23, Janis Papanagnou wrote:
> On 02.02.2024 23:12, bart wrote:
>> On 02/02/2024 21:42, Lawrence D'Oliveiro wrote:
>>> On Fri, 2 Feb 2024 13:47:25 +0000, bart wrote:
>>>
>>>> That's true: only 47 years in computing, and 42 years of evolving,
>>>> implementing and running my systems language.
>>>
>>> On how many different platforms?
>>
>> I started in 1976. I started using Windows for my products in 1995
>> because all my potential customers could buy an off-the-shelf Windows
>> PC.
>
> And that is actually the problem that folks have tried to make clear
> to you. Being so long in a bubble, working on an a technically lousy
> inferior system that decades long did not even manage (maybe not even
> intend) to catch up with any state-of-the-art techniques; what do you
> expect?
>

Windows sucessfully rolled out to a mass market whilst Unix did not. And
if your customers are part of the mass market, you have to use it.
Whilst there is a point in discussing the technical merits of various
systems, only rarely can you choose systems, and often there no option
other than to make things work on Windows. And Windows does run a very
wide variety of programs successfully. And you are not an inferior order
of human being nor are the issues you face unimportant because you are
in the position of needing to do that. You are presumably not a
university undergraduate and grow up.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 03/02/2024 06:52, Malcolm McLean wrote:
> On 02/02/2024 22:12, bart wrote:
>>
>> Why do you consider that fair game, but people hate if when anyone
>> criticises Unix?
>>
> Because UNIX systems used to typically cost tens of thousands of
> dollars, whilst a PC could be had for under a thousand dollars.

I think you got stuck somewhere in the 1990's.

> So
> everyone could have a PC, but if you were given a UNIX system you were a
> bit special. And that gave UNIX programmers a sense of superiority.
>

Anyone who has used both *nix and Windows for development work knows
*nix is superior for that. (Windows has other advantages - I use both
Windows and Linux. Neither is perfect, each has their good points and
bad points.)

> It's a very silly attitude of course.

Fighting against a system that works against everything you are trying
to do is a very silly attitude. Bart has choices - no one is forcing
him to compile open source software that causes him trouble, no one is
forcing him to use Windows, or C, or make, or anything else. He has
completely free choices. He could use Linux and compile the projects
without trouble. He could use Windows and pre-built binaries. He could
use other projects, other languages, other tools. He could choose to
put his feet by the fireside and do Sudokus, or to travel the world and
see other places. He has worked hard, made his money, and has earned
the right to relax a bit. But he actively chooses to fight against
software tools that cause him nothing but anguish and frustration, and
then whines about them here. /That/ is a very silly attitude.

On 02.02.2024 16:31, David Brown wrote:
> On 02/02/2024 15:14, bart wrote:
>> Yes, I do. [...]
> [...]
>
> The whole world is out of step, except Bart.
>
> Has it never occurred to you that when you are in disagreement with
> everyone, /you/ might be the one that is wrong? I think you suffer from
> the "misunderstood genius" myth. It's surprisingly common amongst
> people who have invested heavily in going their own way, against common
> knowledge or common practice. It's a sort of psychological defence
> mechanism against realising you've been wrong all this time.

Indeed. It's reflected also in the ghost driver joke, for example.
But this is important to realize; everyone should be open minded
to that.

What if all my life was prevalently based on is void. (That's hard
in case of religious affairs; when only radicalism seems to help
maintaining mental stability. *shudder*)

There's of course also a couple other things that are noteworthy;
e.g. Mark Twain's "Whenever you find yourself on the side of the
majority, it is time to pause and reflect."
(Reflecting own opinions is certainly important in society. But
in Bart's case, where he's a minority - or even a singularity? -,
of course also.)

Or the "Millions of flies can't be wrong; eat more [...whatever]"

But of course all have to be seen in the Real World context. And
such metaphors can be applied and bent to ones own needs.

Janis

On 02.02.2024 22:15, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> [...]
> [...]
>
> But OK, let me drop everything and fix it for you. I can submit a patch
> for "as" so it behaves the way you want. I'll also submit patches for
> gcc so it invokes "as" with the new interface. It will still have to
> handle the old interface at least temporarily, so there will have to be
> a way to ask "as" which interface it uses. Nothing will ever generate a
> file named "a.out" unless it's explicitly told to do so. I'll also send
> the word out so everyone knows not to rely on the name "a.out" anymore.
> And I'll convince everyone that they've been doing it wrong for the last
> several decades.
>
> I'll let you know when that's done. Because nothing short of that would
> satisfy you.

He would still find something that is different from his tool so
that he anyway won't accept it.

Janis

On 03/02/2024 13:23, Janis Papanagnou wrote:
> On 02.02.2024 23:12, bart wrote:
>> On 02/02/2024 21:42, Lawrence D'Oliveiro wrote:
>>> On Fri, 2 Feb 2024 13:47:25 +0000, bart wrote:
>>>
>>>> That's true: only 47 years in computing, and 42 years of evolving,
>>>> implementing and running my systems language.
>>>
>>> On how many different platforms?
>>
>> I started in 1976. I started using Windows for my products in 1995
>> because all my potential customers could buy an off-the-shelf Windows
>> PC.
>
> And that is actually the problem that folks have tried to make clear
> to you. Being so long in a bubble,

Which bubble, the one before 1995, or after?

Don't you see that using only Unix-like systems is also a bubble?

> I don't know about you, whether you have an academic technical
> background,

I have a CS bachelor's degree.

> whether you had the chance to try out UNIX or the BSD
> variant these days.

I've tinkered only with various kinds of Linuxes. It was fun if your
idea of fun was spending 80% of your time getting things configured to
work properly, and doing apt-gets every 5 minutes for yet another
essential dependency.

But if absolutely necessary I could switch my bubble to Linux, after an
initial painful period of converting my tools. Then the bubble would
eventually look very similar to the Windows one. As I say below, I don't
care about OSes.

> Myself I already knew a couple OSes (for PCs, some not even worth
> to call them OS, for medium scale systems, and also for mainframes)
> before I had my first contact with a Unix system. With that systems
> and OS background it was easy to strive for the better ones; from
> the ones I met it was Unix. (BTW, I observed a similar enthusiasm
> with a friend of mine, a long year hardcore MS DOS user, when he
> got his fingers onto a Unix system.) You might imagine what a joy
> it thus was when Linux and the GNU tools appeared, a powerful and
> reliable(!) system and OS base, and even (almost) for free.
>
> (For you, I dare to say, it's obviously far too late. That ship has
> sailed. If you'd have strived for a broader experience in your early
> days it would certainly be a different situation.

I'd say using anything but Unix /is/ a broader experience than using
only Unix. That latter seems to give people the impression that unless
every OS should either be exactly like Unix, then it is worthless.

I used whatever OS DECSystem10/20 came with; MultiJob on ICL; RSX11M on
PDP11; a CP/M clone (that my company, not me, developed); then the
progression from MSDOS.

Personally I have no interest in OSes other than they a provide a file
system. Anything involving graphical apps in the 80s, I had to program
everything down to the last pixel. Using, naturally, my language and my
compiler.

I also worked for few years in hardware development where the products I
made didn't have an OS at all when I was working on them, but I needed
the means to put test programs into them.

There, you had to be resourceful. How would a Unix-like system (did they
even work on 8-bit machines) have benefited me?

> I cannot speak for "people". Myself I name any issues I see; Unix
> issues are not exempt from that. - I have even a printed version of
> "The UNIX - HATERS Handbook" in my bookshelf (though a lot of its
> content is meanwhile outdated, it doesn't apply any more). - And I
> can certainly collect a page full of deficiencies I see with Linux.
> But so what? (For the MS platforms I could probably "fill a book".)
> Yet, in past decades, I haven't seen any serious competitor to Unix.
> (Note: When I'm saying that I am not considering e.g. supercomputers
> doing e.g. massive hydrodynamic computations. But even in this area
> there's meanwhile also Linux clusters running.)

MSDOS and Windows were intended for direct use by ordinary consumers.
Unix was intended for developers.

Few ordinary consumers directly use a Unix-like system unless it is made
to look like MacOS or Android. Or they run a GUI desktop that makes it
look a bit like Windows.

On 03/02/2024 13:52, David Brown wrote:
> On 03/02/2024 06:52, Malcolm McLean wrote:
>> On 02/02/2024 22:12, bart wrote:
>>>
>>> Why do you consider that fair game, but people hate if when anyone
>>> criticises Unix?
>>>
>> Because UNIX systems used to typically cost tens of thousands of
>> dollars, whilst a PC could be had for under a thousand dollars.
>
> I think you got stuck somewhere in the 1990's.
>
>> So everyone could have a PC, but if you were given a UNIX system you
>> were a bit special. And that gave UNIX programmers a sense of
>> superiority.
>>
>
> Anyone who has used both *nix and Windows for development work knows
> *nix is superior for that.  (Windows has other advantages - I use both
> Windows and Linux.  Neither is perfect, each has their good points and
> bad points.)
>
>> It's a very silly attitude of course.
>
> Fighting against a system that works against everything you are trying
> to do is a very silly attitude.  Bart has choices - no one is forcing
> him to compile open source software that causes him trouble, no one is
> forcing him to use Windows, or C, or make, or anything else.  He has
> completely free choices.  He could use Linux and compile the projects
> without trouble.  He could use Windows and pre-built binaries.  He could
> use other projects, other languages, other tools.  He could choose to
> put his feet by the fireside and do Sudokus, or to travel the world and
> see other places.

I've done all that of course. At one point I was taking 30-40 holidays a
year (since there are only 52 weeks in a year, some of them had to be
short breaks!).

But when relaxing, even abroad, I /had/ to work on some project. I was
so used to years of working all day, 7 days a week, to meet some
deadline, that I couldn't switch off.

I'm concerned about increasing bloat and complexity everywhere. So I'm
just making a stand by developing my own small, human-scale products.

No, I don't /need/ to use some library. But I won't get far these days
without using any libraries; this is no longer the 80s/90s where you did
everything. And you can't do so now anyway; the hardware is too hard to
access.

Then I can rail about products that are unnecessarily hard to use, be
they APIs expressed in C, or stuff I need to build from source, just
because developers are based on Linux and they expect all users to use
Linux too.

bart <bc@freeuk.com> writes:

> On 03/02/2024 09:05, Tim Rentsch wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>>> Indeed it is the case that producing a complete program is one
>>>> part of my overall build process. But it is only one step out
>>>> of many, and it is easy to express without needing any special
>>>> considerations from the build system.
>>>
>>> So, will a specific build of such a project produce a single
>>> EXE/DLL//SO file? (The // includes the typical file extension of
>>> Linux executables.)
>>
>> No, there are several outputs of this kind, including object
>> files, static libraries, and dynamic libraries, and all for a C
>> environment. (There are also other outputs but of a different
>> kind than what you are asking about.)
>>
>> I have no expectation that you will incorporate these ideas or
>> capabilities into a tool you are building for yourself. I gave
>> the list in case other readers might have an interest.
>
> OK. You seem fairly level-headed and calm, so I'll try this
> explanation. [...]

You have no interest in what's important to me in a build system.

I have no interest in what's important to you in a build system.

And in any case the recent discussion of build systems has gone
beyond the bounds of comp.lang.c and should be conducted in some
other newsgroup, or perhaps some other venue.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> [.. various philosophical musings ..]

Please take this irrelevant crap somewhere else. Thank you.

On 03/02/2024 14:39, Janis Papanagnou wrote:
> On 02.02.2024 16:26, David Brown wrote:
>>
>> [...] The Eclipse folk are experts at making an editor and IDE, [...]
>
> I have to disagree with this bit.
>

My point is independent of whether or not you like Eclipse (people are
split on that), or what editor you think is best (people break out in
fights over that).

The point is that the editor and IDE people make the editor and IDE, the
compiler people make the compiler, the debugger people make the
debugger, and so on - while to the user, the package looks more or less
like a complete "do everything" development tool.

On 03/02/2024 13:52, David Brown wrote:
> On 03/02/2024 06:52, Malcolm McLean wrote:
>> On 02/02/2024 22:12, bart wrote:
>>>
>>> Why do you consider that fair game, but people hate if when anyone
>>> criticises Unix?
>>>
>> Because UNIX systems used to typically cost tens of thousands of
>> dollars, whilst a PC could be had for under a thousand dollars.
>
> I think you got stuck somewhere in the 1990's.
>
>> So everyone could have a PC, but if you were given a UNIX system you
>> were a bit special. And that gave UNIX programmers a sense of
>> superiority.
>>
>
> Anyone who has used both *nix and Windows for development work knows
> *nix is superior for that.  (Windows has other advantages - I use both
> Windows and Linux.  Neither is perfect, each has their good points and
> bad points.)
>
You right. On Unix you can fire up the system, launch an editor, type
"hello world" into it, type gcc or cc *.c -lm at the shell, type
../a.out, and yove got the outout "Hello world" and a template you can
then modify to do practically anything you want.

On Windows you've got the fire up Visual Studio, and set up a project
file. And then you've gt to fiddle with it to enable the standard
library. And then it will demand you include "stdafx.h" and you've got
to fiddle with it a bit more to sop it asking for that. Then, whilst you
will get an executable, when you launch it from the IDE, the output
window will disappear before you can read it. And you have to fiddle
with it a bit more. It's much less convenient.

On the other had, if you want a GUI, the Windows system is all set up
for you and you just have to call the right functions. On Unix you have
to configure some sort of front end to X, there's a lot more messing
about, and the GUI elements aren't consistent.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 03/02/2024 15:17, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
>
>> On 03/02/2024 09:05, Tim Rentsch wrote:
>>
>>> bart <bc@freeuk.com> writes:
>>>
>>>>> Indeed it is the case that producing a complete program is one
>>>>> part of my overall build process. But it is only one step out
>>>>> of many, and it is easy to express without needing any special
>>>>> considerations from the build system.
>>>>
>>>> So, will a specific build of such a project produce a single
>>>> EXE/DLL//SO file? (The // includes the typical file extension of
>>>> Linux executables.)
>>>
>>> No, there are several outputs of this kind, including object
>>> files, static libraries, and dynamic libraries, and all for a C
>>> environment. (There are also other outputs but of a different
>>> kind than what you are asking about.)
>>>
>>> I have no expectation that you will incorporate these ideas or
>>> capabilities into a tool you are building for yourself. I gave
>>> the list in case other readers might have an interest.
>>
>> OK. You seem fairly level-headed and calm, so I'll try this
>> explanation. [...]
>
> You have no interest in what's important to me in a build system.
>
> I have no interest in what's important to you in a build system.
>
> And in any case the recent discussion of build systems has gone
> beyond the bounds of comp.lang.c and should be conducted in some
> other newsgroup, or perhaps some other venue.

At what point does a discussion about C programming turn into a
discussion about general programming? But one of the criticisms of Bart
was that he was talking about a build system designed to produce
executables from flat C source, and ignoring the other functions of a
build system.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 03/02/2024 15:44, Malcolm McLean wrote:
> On 03/02/2024 13:52, David Brown wrote:
>> On 03/02/2024 06:52, Malcolm McLean wrote:
>>> On 02/02/2024 22:12, bart wrote:
>>>>
>>>> Why do you consider that fair game, but people hate if when anyone
>>>> criticises Unix?
>>>>
>>> Because UNIX systems used to typically cost tens of thousands of
>>> dollars, whilst a PC could be had for under a thousand dollars.
>>
>> I think you got stuck somewhere in the 1990's.
>>
>>> So everyone could have a PC, but if you were given a UNIX system you
>>> were a bit special. And that gave UNIX programmers a sense of
>>> superiority.
>>>
>>
>> Anyone who has used both *nix and Windows for development work knows
>> *nix is superior for that.  (Windows has other advantages - I use both
>> Windows and Linux.  Neither is perfect, each has their good points and
>> bad points.)
>>
> You right. On Unix you can fire up the system, launch an editor, type
> "hello world" into it, type gcc or cc *.c -lm at the shell, type
> ./a.out, and yove got the outout "Hello world" and a template you can
> then modify to do practically anything you want.
>
> On Windows you've got the fire up Visual Studio, and set up a project
> file. And then you've gt to fiddle with it to enable the standard
> library. And then it will demand you include "stdafx.h" and you've got
> to fiddle with it a bit more to sop it asking for that. Then, whilst you
> will get an executable, when you launch it from the IDE, the output
> window will disappear before you can read it. And you have to fiddle
> with it a bit more. It's much less convenient.

You're assuming VS has been installed. How about assuming Tiny C has
been installed instead. Then:

`On Windows, 'fire up the system', launch an editor, type "Hello world"
into it, type "tcc *.c" at the shell, type hello and you've got the
output "Hello world" and a simpler template.`

So there is little difference (eg. gcc is preinstalled on one, but if
you want to use tcc, it must be installed on both OSes).

You're not comparing like with like.

DB is saying Unix is superior because it comes with a million developer
tools either built-in or instantly available via apt-get or whatever.

That cuts no ice with me because I can work with a very spartan set of
tools.

> On the other had, if you want a GUI, the Windows system is all set up
> for you and you just have to call the right functions. On Unix you have
> to configure some sort of front end to X, there's a lot more messing
> about, and the GUI elements aren't consistent.

For GUI they're both a nightmare unless you use a simpler library that
sits on top. Or are you saying that X is even worse than WinAPI?

On 03/02/2024 15:17, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
>
>> On 03/02/2024 09:05, Tim Rentsch wrote:
>>
>>> bart <bc@freeuk.com> writes:
>>>
>>>>> Indeed it is the case that producing a complete program is one
>>>>> part of my overall build process. But it is only one step out
>>>>> of many, and it is easy to express without needing any special
>>>>> considerations from the build system.
>>>>
>>>> So, will a specific build of such a project produce a single
>>>> EXE/DLL//SO file? (The // includes the typical file extension of
>>>> Linux executables.)
>>>
>>> No, there are several outputs of this kind, including object
>>> files, static libraries, and dynamic libraries, and all for a C
>>> environment. (There are also other outputs but of a different
>>> kind than what you are asking about.)
>>>
>>> I have no expectation that you will incorporate these ideas or
>>> capabilities into a tool you are building for yourself. I gave
>>> the list in case other readers might have an interest.
>>
>> OK. You seem fairly level-headed and calm, so I'll try this
>> explanation. [...]
>
> You have no interest in what's imprtant to me in a build system.

Determining which files to submit to a compiler is not important to you?

OK... (I think the compiler will say otherwise!).

But whether that is actually the case, that's the only thing I was
addressing.

On 03.02.2024 16:26, David Brown wrote:
> On 03/02/2024 14:39, Janis Papanagnou wrote:
>> On 02.02.2024 16:26, David Brown wrote:
>>>
>>> [...] The Eclipse folk are experts at making an editor and IDE, [...]
>>
>> I have to disagree with this bit.
>>
>
> My point is independent of whether or not you like Eclipse (people are
> split on that), or what editor you think is best (people break out in
> fights over that).
>
> The point is that the editor and IDE people make the editor and IDE,

Yes, and my point was that they had no integration concept for that.
(Thus it wouldn't occur to me to call that "experts". But they likely
had just another agenda.) And this is of course completely independent
of anyones opinion on Eclipse or on any specific editor.

> the
> compiler people make the compiler, the debugger people make the
> debugger, and so on - while to the user, the package looks more or less
> like a complete "do everything" development tool.

Right. (Only they ignored the modularization on the "editor and IDE"
component.)

Janis

On 03/02/2024 16:03, bart wrote:
> On 03/02/2024 15:44, Malcolm McLean wrote:
>>
>> On the other had, if you want a GUI, the Windows system is all set up
>> for you and you just have to call the right functions. On Unix you
>> have to configure some sort of front end to X, there's a lot more
>> messing about, and the GUI elements aren't consistent.
>
> For GUI they're both a nightmare unless you use a simpler library that
> sits on top. Or are you saying that X is even worse than WinAPI?

I've programmed for both and Windows GUI is quite a bit easier to use.
You have to enter a library name explictly to get the common controls,
for some stupid reason, but once you do that the whole system is set up
for you. Just call the API more or less as you would any other C
function (except for tiny message loop interface), you've got a rich set
of controls, and they are well designed and harmonised with the rest of
the programs on the system.

X - if you try to program to Xlib directly you're messing about with
colur maps and goodness knows what just to get up a window. And if you
don't it's dependency land and all that that entails, with some popular
widget toolsets but no real standards. And often you find that these
will break. However nowadays you can use QT. Which is alot better but
still not very well designed with a non-canonical slot / message system
and poor facilites for layout. That's why I was driven to write Baby X.
A simple clean interface to Xlib that would allow you to get graphics up
quickly and easily. You shouldn't have to do that, of course.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2024-02-03, bart <bc@freeuk.com> wrote:
> On 03/02/2024 01:31, Lawrence D'Oliveiro wrote:
>> On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote:
>>
>>> What option is that, to have one command 'cc' that can deal with N
>>> different languages?
>>
>> Hint: it uses the filename extension to determine which language, and
>> which flavour of the language even, it is dealing with.
>
> This is the filename extension which Linux famously ignores, because you
> can use any extension you like?
>
> Hint: my tools KNOW which language they are dealing with:

You're arguing for a user-unfriendly system where you have to memorize
a separate command for processing each language.

Recognizing files by suffix is obviously superior.

> root@XXX:/mnt/c/c# cp hello.c hello.x
> root@XXX:/mnt/c/c# gcc hello.x
> hello.x: file not recognized: file format not recognized

This is good; it's one more little piece of resistance
against people using the wrong suffix.

It's not the only one. Editors won't bring up the correct syntax
formatting and coloring if the file suffix is wrong.

Tools for cross-referencing identifiers in source code may also get
things wrong due to the wrong suffix, or ignore the file entirely.

Your argument of "I can rename my C to any suffix and my compiler
still recognizes it" is completely childish.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-02-03, bart <bc@freeuk.com> wrote:
> On 03/02/2024 13:23, Janis Papanagnou wrote:
>> On 02.02.2024 23:12, bart wrote:
>>> On 02/02/2024 21:42, Lawrence D'Oliveiro wrote:
>>>> On Fri, 2 Feb 2024 13:47:25 +0000, bart wrote:
>>>>
>>>>> That's true: only 47 years in computing, and 42 years of evolving,
>>>>> implementing and running my systems language.
>>>>
>>>> On how many different platforms?
>>>
>>> I started in 1976. I started using Windows for my products in 1995
>>> because all my potential customers could buy an off-the-shelf Windows
>>> PC.
>>
>> And that is actually the problem that folks have tried to make clear
>> to you. Being so long in a bubble,
>
> Which bubble, the one before 1995, or after?
>
> Don't you see that using only Unix-like systems is also a bubble?

Don't you see that living on Earth is literally being in bubble?

Your bubble contains only one person.

The Unix-like bubble is pertty huge, full of economic opportunities,
spanning from embedded to server.

A lot of embedded systems are Unix-like (and those that aren't often
have Unix-like development environments). Phones, tables, routers, set
top boxes, IOT, remote sensing, robotics, yaddda yadda.

While you were dismissing Linux in 1995, it was actually going strong,
marching forward. Only fools ignored it.

A year before that, in 1994, I was doing contract work for Linux
already. My client used it for serving up pay-per-click web pages to
paying customers. I was working on the log processing and billing side
of it, and also created a text-UI (curses) admin tool.

> I'd say using anything but Unix /is/ a broader experience than using
> only Unix.

No, it isn't. That is fallacious. Working with anything else plus Unix
is a broader experience than only Unix. Otherwise, we can't say.

> That latter seems to give people the impression that unless
> every OS should either be exactly like Unix, then it is worthless.

Actually there are ways in which that is objectively true.

An OS that provides more or less the same semantics as POSIX, but using
interfaces that are gratuitously different, and incompatible, is
worthless in this day and age.

Something that doesn't conform to compatibility standards, and isn't
demonstrably better for it, is a dud.

There is good different and bad different. More or less same, but
incompatible, is bad different.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 03/02/2024 17:59, Kaz Kylheku wrote:
> On 2024-02-03, bart <bc@freeuk.com> wrote:
>> On 03/02/2024 01:31, Lawrence D'Oliveiro wrote:
>>> On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote:
>>>
>>>> What option is that, to have one command 'cc' that can deal with N
>>>> different languages?
>>>
>>> Hint: it uses the filename extension to determine which language, and
>>> which flavour of the language even, it is dealing with.
>>
>> This is the filename extension which Linux famously ignores, because you
>> can use any extension you like?
>>
>> Hint: my tools KNOW which language they are dealing with:
>
> You're arguing for a user-unfriendly system where you have to memorize
> a separate command for processing each language.

You have to impart that information to the tool in any case. It can
either be by file extension, or the name of the command.

So, 'cc' is some tool that looks at a file extension and selects a
suitable program based on that extension; well done.

But what is the point? Do you routinely invoke cc with multiple files of
mixed languages? Suppose you wanted a different C compiler on each .c
file? Oh, you then invoke it separately for each file. So you do that
anyway in that rare event.

> Recognizing files by suffix is obviously superior.
>
>> root@XXX:/mnt/c/c# cp hello.c hello.x
>> root@XXX:/mnt/c/c# gcc hello.x
>> hello.x: file not recognized: file format not recognized
>
> This is good; it's one more little piece of resistance
> against people using the wrong suffix.

> It's not the only one. Editors won't bring up the correct syntax
> formatting and coloring if the file suffix is wrong.
>
> Tools for cross-referencing identifiers in source code may also get
> things wrong due to the wrong suffix, or ignore the file entirely.

This completely contradicts what people have been saying about Linux
where file extensions are optional and only serve as a convenience.

For example, executables can have no extension, or .exe, or even .c.

It is Windows that places more store by file extensions, which Linux
people say is a bad thing.

But above you say that is the advantage of Linux.

> Your argument of "I can rename my C to any suffix and my compiler
> still recognizes it" is completely childish.

It only seems to be childish when one of my programs handles this better
than one of yours!

There is only thing my mcc program can't do, which is to compile a C
file named 'filename.'; that is, 'filename' followed by an actual '.',
not 'filename' with no extension.

And that's only when I run it under Linux. That's because under Linux,
'filename' and 'filename.' are distinct files; the "." is part of the
file name, not a notional separator.

So here's a summary of what I've recently learnt about Linux in the form
of an FAQ:

Q Why do Linux executables usually not have extensions?

A Because if they had an extension like .exe or .elf, you'd have to
invoke them as prog.exe or ./prog.elf, which would rapidly get tedious

Q Why do filenames specified in shell command lines tend to not have
default extensions?

A Because 'abc.' and 'abc' are distinct files, it can't tell whether
'abc' means a 'abc.x' (the default extension) or 'abc'. You can't use
'abc.' to indicate no extension, because that is an actual file name

Q Why do a lot of programs on Linux that default to stdin and stdout
for i/o, never display helpful prompts or messages?

A Because that output would screw up any data output that is sent to
stdout. So they are silent. (Imagine if Bash displayed no prompt!)

On 03/02/2024 18:17, Kaz Kylheku wrote:
> On 2024-02-03, bart <bc@freeuk.com> wrote:

>> Don't you see that using only Unix-like systems is also a bubble?
>
> Don't you see that living on Earth is literally being in bubble?
>
> Your bubble contains only one person.
>
> The Unix-like bubble is pertty huge, full of economic opportunities,
> spanning from embedded to server.

You're missing my point. Unix imposes a certain mindset, mainly that
there is only ONE way to things, and that is the Unix way.

That is pretty obvious from the passionate posts people make about it.
And it is obvious that they struggle outside it, which is why they hate
Windows - it just isn't Unix!

> While you were dismissing Linux in 1995, it was actually going strong,
> marching forward. Only fools ignored it.
>
> A year before that, in 1994, I was doing contract work for Linux
> already. My client used it for serving up pay-per-click web pages to
> paying customers. I was working on the log processing and billing side
> of it, and also created a text-UI (curses) admin tool.

Meanwhile, a decade before that, the question of OS in my first
commercial product was utterly irrelevant. It provided a file system and
it was used to launch my app.

What was it again? I can barely remember. I JUST DO NOT CARE.

Of all those OSes I have used, Windows might rank near the bottom, but
not for the reasons you think. That's because it operated in protected
mode so that lots of things which had been easy, became hard.

And now it is just monstrous. As I'm typing this, there are 240
processes and 2700 threads. In 1984, a machine running my app would have
exactly process: itself!

(I've just looked up that machine I used c.1985; it was a PCW 8256, an
8-bit machine running CP/M+. Why not Unix? I've no idea. Maybe it was
just not practical. Maybe CP/M+ was cheaper.

More pressing to me was how to get programs inside it, given its
non-standard 3" floppies, and how to display graphics, given that it was
a word processor with a text-mode display.

How would Unix have helped with that? It wouldn't.)

>> I'd say using anything but Unix /is/ a broader experience than using
>> only Unix.
>
> No, it isn't. That is fallacious. Working with anything else plus Unix
> is a broader experience than only Unix. Otherwise, we can't say.

Well, I've tinkered with Linux on and off since the late 90s. So yes, I
have used it. I have ported a few of my tools to it in the past.

So I have some experience of it. It's not as though I first used it last
week. I just don't care for it. But if I had a gun pointed at my head I
could use it.

> An OS that provides more or less the same semantics as POSIX, but using
> interfaces that are gratuitously different, and incompatible, is
> worthless in this day and age.

Because .... you say so?

I mean, are core OSes really so hard to write that everyone in the world
has to use the same one? There seems to plenty of amateur OS development
still.

> Something that doesn't conform to compatibility standards, and isn't
> demonstrably better for it, is a dud.
>
> There is good different and bad different. More or less same, but
> incompatible, is bad different.

I build a box where you feed in data in the form of byte-stream, and it
gives results in the form of a byte-stream. Or replace one of those by
something physical; say the box is a printer or scanner.

There is no OS specified, you've no idea whether it uses POSIX, or even
if there's a computer inside.

But if it performs a useful task, then what is the problem?

Same thing if you are working on a self-contained function, library or
app. It may have inputs or outputs. Do you need to care what OS is
running? No, only on the job it has to do.

Really you make too much of it. The main thing I don't like is when I
have some software that is hard to build on Windows when there is no
reason for it.

On 2/3/2024 4:02 AM, bart wrote:
> On 03/02/2024 01:29, Lawrence D'Oliveiro wrote:
>> On Fri, 2 Feb 2024 22:12:04 +0000, bart wrote:
>>
>>> On 02/02/2024 21:42, Lawrence D'Oliveiro wrote:
[...]

> See, I don't even know the difference. This is a collection of OSes
> without even a name. I was trying to avoid saying 'Linux' because of the
> preponderance of other Unix-related OSes. But I would rather shoot
> myself than resort to using '*nixes'.

Have you experimented with vcpkg yet? It manages to compile a lot of
libraries from scratch...

On 2/3/2024 7:44 AM, Malcolm McLean wrote:
> On 03/02/2024 13:52, David Brown wrote:
>> On 03/02/2024 06:52, Malcolm McLean wrote:
>>> On 02/02/2024 22:12, bart wrote:
[...]
> On Windows you've got the fire up Visual Studio, and set up a project
> file.

Not true. First of all you need to download MSVC first, its a fat one.
Fwiw, I have used several different compilers on Windows over the years.
Iirc, vcpkg uses some mingw, clang, or whatever compiler is needs to
build its packages from source...

> And then you've gt to fiddle with it to enable the standard
> library. And then it will demand you include "stdafx.h" and you've got
> to fiddle with it a bit more to sop it asking for that. Then, whilst you
> will get an executable, when you launch it from the IDE, the output
> window will disappear before you can read it. And you have to fiddle
> with it a bit more. It's much less convenient.
>
> On the other had, if you want a GUI, the Windows system is all set up
> for you and you just have to call the right functions. On Unix you have
> to configure some sort of front end to X, there's a lot more messing
> about, and the GUI elements aren't consistent.

On 2/3/2024 8:03 AM, bart wrote:
[...]

Do you have a windows installation with a recent version of MSVC
installed? Give vcpkg a go, and see how it builds things... Then
automatically integrates them into MSVC. It's pretty nice and about
time. ;^)