On 17/08/2023 17:16, Bart wrote:
> On 16/08/2023 14:16, David Brown wrote:
> > On 16/08/2023 13:15, Bart wrote:
> > Then there is the question of why it matters.  PC disks are big.  PC
> > CPUs are fast.  Network speeds are high.  Top quality development tools
> > and utilities are freely available - even on Windows.  Size and speed
> > matters very little for software on PC's.  (It matters a great deal on
> > small embedded systems.)
>
> And yet... when I reinstalled CMake, it took nearly 10 minutes to unzip
> 7300 files into 112MB, on an SSD. I don't why it took that long, but it
> did.
>
> (There's also the mystery of why it takes such a humungous program to
> ... turn a file-spec info into a makefile? I could do that by hand in
> less than 10 minutes! In the end CMake couldn't even complete the task:
> maybe 7300 files wasn't quite enough.
>
> But I think you're not keen on CMake anyway.)
>
> When I tried to install VS once, although on an older machine with a
> hard drive, it took 90 minutes. Each time it started up (usually
> inadvertently because of a file association), it took 90 seconds.
>
> On the same machine, my programs started instantly.
>
>
> >
> > So who are you fighting for?  Who are you fighting against?  Do you
> > really think you are making a difference for some greater good here, or
> > even just for your own personal benefit?
>
> There are a huge number of benefits to keeping things small and
> managable. You don't understand what they are because of using top-end
> hardware, and using systems and tools that many people use in your field
> so that things run smoothly; an issues will have been fixed or patches.
>
> Lots of people have also piled on extra complexity to get around
> problems of sluggishness: being extra clever in avoiding repeating the
> work.
>
> Or just throwing an extra 31 cores at the problem.
>
>
> > (There's nothing wrong with
> > doing it for your own benefit - I am not suggesting you have to fight
> > for other people.)
>
> This is an analogy I have used before regarding LLVM, which is a backend
> for language implementations. It is quite large and complex.
>
> Once I needed a side-gate for my house. I made it myself, and ended up
> with a 6' high wooden gate, of just the right size.
>
> Now if I'd gone to the LLVM shop as a solution, the gate would have been
> 9 miles high - if I could ever figure it out.
>
> >  Have you considered whether there are other battles
> > that would make more sense or have greater impact?  Have you considered
> > forgetting it all, splashing out £300 on a new mini-PC, installing Linux
> > Mint, and going back to having fun with computers, learning new things,
> > and creating software without bothering about how much space gcc
> takes up?
>
> Lots of people are having fun with retrocomputing, where they can be 99%
> responsible for what's going on rather than 1%. And there is it can
> challenging, in a fun way, to have limits on what is possible.
>
> However, you're wrong about space ceasing to be an issue: devices such
> as smartphones, despite having GBs of storage rapidly get filled up
> because every downloaded app is 10s of MB and sometimes 100s.
>
> Because nobody cares anymore.
>
> >>
> >> Of course, you are NEVER going to admit that doing:
> >>
> >>    mm lua
> >>
> >> might be a touch sweeter than those 330 lines of makefile crap below.
> >
> > I fail to see how that's better than "make" (or "make mingw" on
> > Windows).
>
> And here is the crux. You really believe that you can solve 'complexity'
> by hiding it away in a box and providing one simple launch button.
>
> My preference is to tackle complexity by actually (gasp!) making it
> simpler not just piling on even more stuff.
>
> (Here's the David Brown approach to editing a messy 10,000-page draft of
> a book down to 500 pages: just print it in a smaller font to fit into
> 500 pages; easy!
>
> Or publish it on Kindle: nobody has a clue how long anything is on one
> of those anyway. It will just take ages to get from 0% to 1%.
>
> You might object, but this is exactly what happens with software: there
> we now have unlimited amounts of program memory, and NOBODY apparently
> cases about size, bloat, inefficiency and gratuitous complexity.
>
> Well, until it comes to the difference between say Tcc and gcc/LLVM,
> where 99% of the latter's build time is spent making programs twice as
> fast as with the 180KB tcc.exe.
>
> Then that mere 2.0 factor becomes hugely important, it cutting down
> lesser compilers down to size.
>
>
> > I /do/ see how "make" is vastly superior, because the
> > makefile has lots more in it than just the dependencies that could be
> > found automatically.  Where does "mm lua" put all the compiler flags?
>
> If you wanted to build my 'qq' interpreter, I could provide these three
> files:
>
>   c:\demo>dir
>   17/08/2023  16:51                17 makefile
>   17/08/2023  16:54           438,272 mm.exe
>   17/08/2023  16:52           581,891 qq.ma
>
> Unlike a normal source bundle, I provide the compiler needed. This is
> one of many advantages of a small self-contained compiler. The source
> files have also been bundled into one file.
>
> The makefile contains this:
>
>   qq:
>       mm qq.qa
>
> (I can't test it because make disappeared with gcc. I tried downloading
> one but it had missing DLLs. So, forget it.)
>
> So to build, you can either do:
>
>    make                        # needs 'make' installed
>
> or:
>
>    mm qq.qa
>
> Satisfied? My compiler is intrinsically simple. The end result is a
> working interpreter.

Typo: those .qa extension should be .ma. (qq.exe can also generate
amalgamations with .qa extensions.)

Actually, those extensions aren't needed at all in this case: the
makefile can contain 'mm qq', and the command line is 'mm qq' too.

If mm.exe can't find prog.q, it will look for prog.qa.

On Thursday, August 17, 2023 at 7:21:02 PM UTC+3, Scott Lurndal wrote:
> Michael S <already...@yahoo.com> writes:
> >On Thursday, August 17, 2023 at 7:01:51=E2=80=AFPM UTC+3, Scott Lurndal wro=
> >te:
> >> Michael S <already...@yahoo.com> writes:=20
> >> >On Wednesday, August 16, 2023 at 1:52:46=3DE2=3D80=3DAFPM UTC+3, David B=
> >rown wrot=3D=20
> >> >e:=20
> >> >> Certainly embedding it within other applications is a major purpose of> >=3D20=20
> >> >> the language, yes. It is becoming more mature as a stand-alone=3D20=20
> >> >> language, with more libraries, but it is very popular for adding to=3D=
> >20=20
> >> >> other programs. As you say, Lua is a common choice for scripting in=3D=
> >20=20
> >> >> games. I used it myself as a scripting language in an embedded program=
> >,=3D=20
> >> >=3D20
> >> >> many moons ago.=20
> >> >=20
> >> >Did it work?=20
> >> >I mean, not an easy technical part of embedding an interpreter.=20
> >> >Did the "human" part work? Did people that were supposed to write=20
> >> >scripts bothered to learn the language and to start writing?
> >> We also have some stand-alone[*] software that runs on our CPUs=20
> >> that uses an embedded lua interpreter. Users have had no problems=20
> >> with it at all.=20
> >>=20
> >> [*] in this context, bare-metal sans OS.
> >
> >Who are users in this case?
> Firmware engineers, customer field support engineers and in some
> cases, customers.

I would think that in your case "customers" are also software or electronic
engineers, mostly developers of Telecom/datacom equipment.

Still your people are less lazy and more willing to learn than 80% of my
co-workers. Field support engineers that even contemplate an idea of
writing scripts by themselves are especially startling.

Michael S <already5chosen@yahoo.com> writes:
>On Thursday, August 17, 2023 at 7:21:02=E2=80=AFPM UTC+3, Scott Lurndal wro=
>te:
>> Michael S <already...@yahoo.com> writes:=20
>> >On Thursday, August 17, 2023 at 7:01:51=3DE2=3D80=3DAFPM UTC+3, Scott Lu=
>rndal wro=3D=20
>> >te:=20
>> >> Michael S <already...@yahoo.com> writes:=3D20=20
>> >> >On Wednesday, August 16, 2023 at 1:52:46=3D3DE2=3D3D80=3D3DAFPM UTC+3=
>, David B=3D=20
>> >rown wrot=3D3D=3D20=20
>> >> >e:=3D20
>> >> >> Certainly embedding it within other applications is a major purpose=
> of=3D
>> >=3D3D20=3D20=20
>> >> >> the language, yes. It is becoming more mature as a stand-alone=3D3D=
>20=3D20=20
>> >> >> language, with more libraries, but it is very popular for adding to=
>=3D3D=3D=20
>> >20=3D20=20
>> >> >> other programs. As you say, Lua is a common choice for scripting in=
>=3D3D=3D=20
>> >20=3D20=20
>> >> >> games. I used it myself as a scripting language in an embedded prog=
>ram=3D=20
>> >,=3D3D=3D20=20
>> >> >=3D3D20=20
>> >> >> many moons ago.=3D20=20
>> >> >=3D20=20
>> >> >Did it work?=3D20=20
>> >> >I mean, not an easy technical part of embedding an interpreter.=3D20=
>=20
>> >> >Did the "human" part work? Did people that were supposed to write=3D2=
>0
>> >> >scripts bothered to learn the language and to start writing?
>> >> We also have some stand-alone[*] software that runs on our CPUs=3D20=
>=20
>> >> that uses an embedded lua interpreter. Users have had no problems=3D20=
>=20
>> >> with it at all.=3D20=20
>> >>=3D20
>> >> [*] in this context, bare-metal sans OS.=20
>> >=20
>> >Who are users in this case?
>> Firmware engineers, customer field support engineers and in some=20
>> cases, customers.
>
>I would think that in your case "customers" are also software or electronic
>engineers, mostly developers of Telecom/datacom equipment.
>
>Still your people are less lazy and more willing to learn than 80% of my
>co-workers. Field support engineers that even contemplate an idea of
>writing scripts by themselves are especially startling.

We have really good FEs, that's a fact.

On 16/08/2023 11:52, David Brown wrote:
> On 16/08/2023 11:34, Malcolm McLean wrote:
>> My understanding of Lua is that, whilst it can be used as a standalone
>> language, it's really meant for adding scripting to applications.
>
> Certainly embedding it within other applications is a major purpose of
> the language, yes.

And to that end, Lua is a small language that can be implemented in a
few 100KB, including as one DLL file.

I think Tiny C can also be used as a bundled backend.

But, I'm confused: according to you, it doesn't matter at all how big
any product is, since hardware resources are essentially unlimited.

So why is it better that a product like Lua is small and self-contained?

Why would it matter if it was 100MB and embedding it involved grappling
with 25,000 source files across 3,000 nested folders and took an hour
extra to build, dwarfing half the products it was used with?

Yet, when *I* try and keep my products small, compact and streamlined,
then it is apparently totally pointless.

You told me my aims are so futile, I should give up, and buy a Linux
machine and become just another cog.

A bit like telling an amateur film-maker to give that up and buy a
cinema season-ticket instead.

> It is becoming more mature as a stand-alone
> language, with more libraries, but it is very popular for adding to
> other programs. As you say, Lua is a common choice for scripting in
> games. I used it myself as a scripting language in an embedded program,
> many moons ago.
>
>> If you're
>> writing the game level editor then of course the programmer works
>> closely with the users, and it's acceptable to have the level editor
>> call a binary executable. But if you want scripting in the game itself
>> then
>> you have to include the Lua source code.
>>
>> S yes, users rather than developers of Lua itself have to be able to
>> incorporate it into a project and compile it easily.
>>
>
> Sure. But if you want to do that, you read the relevant sections of the
> manual and see which files you need, which options you want, what
> configuration you want, and how you should combine it with your own
> code.

I'm working on something like that right now. A much smaller, more
dynamic, more easily embeddable version of my current scripting language.

Totally futile of course. But it is my choice. Making things small,
compact, simple and fast isn't that easy.

Bart <bc@freeuk.com> writes:

> On 17/08/2023 02:56, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:

>>> I just say it like it is.
>>
>> You say it like you see it (as do I). To consider that as "like it is"
>> takes more self confidence than I can muster.
>
> Make seems to mostly use a local file called 'makefile' for its primary
> data. Certainly that's what it will use if no alternate is provided.
>
> That's like 'it is'.

But, as you know perfectly well, that is not the remark you were
claiming to have stated as it is. The claim -- to be just saying it as
it is -- was in relation to quite a rude remark about me (and others).

--
Ben.

On Mon, 14 Aug 2023 02:44:16 -0000 (UTC), Kenny McCormack wrote:
> In article <8fb22829-9b5e-4108-a513-df3b72391405n@googlegroups.com>,
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> ...
>>> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
>>> development environment, so arguing that it doesn't have "make" is kind of
>>> pointless.
>
> I may actually have mis-spoken here. DOS did originally come with GWBASIC,
> so you could, at least write and run programs back then.

Later DOS version (I think 6+) came with QBASIC which was pretty close to
an early IDE, reasoned individuals may debate whether it is a development
environment but I believe I recall single-stepping in it.

> Does modern Windows come with VB.NET ready-to-go, or do you have to
> download it?

The latest version of Windows 10 Home does not come with any development
tools that I'm aware of. Even WSL requires installation after the fact.

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh

On 17/08/2023 21:26, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 17/08/2023 02:56, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>
>>>> I just say it like it is.
>>>
>>> You say it like you see it (as do I). To consider that as "like it is"
>>> takes more self confidence than I can muster.
>>
>> Make seems to mostly use a local file called 'makefile' for its primary
>> data. Certainly that's what it will use if no alternate is provided.
>>
>> That's like 'it is'.
>
> But, as you know perfectly well, that is not the remark you were
> claiming to have stated as it is. The claim -- to be just saying it as
> it is -- was in relation to quite a rude remark about me (and others).
>

You said this:

>oh dear, I typed the above before reading this, but I'll post the
explanation anyway...

I called that a snide remark. Is that what you mean by 'rude'? And your
own dismissive comment wasn't?

OK. I try very hard to not get personal on forums, and attack only ideas
and attitudes.

However too many do get personal and insulting. Or incredibly
patronising like David Brown. Then I /will/ make a rude response.

I take it you don't have a personal opinion about 'make'? You would have
written it in the same way? But you'd rather write ad hominem remarks
instead.

>
> But, as you know perfectly well, that is not the remark you were
> claiming to have stated as it is.

This is a puzzle now. What the hell did I say that is the problem now>

You have a habit of dissecting and analysing every chance turn of phrase
I use. That seems to be more important to you, being able to attack me,
than the presumably less interesting topic of where 'make' takes its
input from and whether that was a good way or bad.

In my view it is bad; your view, I don't actually know other than you
seem to be defending it.

On 17/08/2023 14:45, David Brown wrote:
> On 16/08/2023 19:07, Bart wrote:
>> On 16/08/2023 14:16, David Brown wrote:
>> > Tell me what you see as the advantage here, and why /you/ think it
>> would
>> > be a jolly good idea, and maybe I'll agree. But you have to say
>> why it
>> > would be better for everyone, not just for you personally - you need
>> > good reasons to change 50 year old conventions.
>>
>> [Giving names to makefiles]
>>
>> * You can have more than one project in the same folder
>
> Makefiles can have multiple targets - that is, in fact, very common. But
> usually it's a bad idea to have multiple different projects in the same
> folder.
>
>>
>> * You can have different configurations of the same project
>
> I do that all the time with a single makefile.
>
>>
>> * You can have different makefiles customised to different compilers
>> (Seed7 has nearly 20 different makefiles)
>
> You can do that with a single makefile.

Yes, you can do quite a lot with a single, large, elaborate file. But
sometimes it's better to have several simpler, dedicated files.

But this sounds familiar: wasn't it you castigating me in the past for
distributing software as a single C file?

You got the incorrect idea that that was how I developed the software
(as a single 40,000-line module).

It sounds a lot like double standards: when I use a single file, even
though it has its own name that must be submitted to the tool, it's bad.

But when makefiles do it, it's good! And they're all allowed to have the
same name no matter what the project.

A bit like the Lua product in my other post. When I make a 300KB
self-contained language, it's bad, it's pointless, it's rubbish, it's a toy.

When Lua does the same thing, then what a great product!

> Call the main one "makefile", and the other one "other_bit.mak" - this
> is fine and perfectly normal.

In the Lua project, the two files were called 'makefile'. I suspect that
if 'make' required an explicit name, they would not both be called
'makefile'.

>>
>> * If you expected to build X according to the build instructions,
>> but the makefile is called Y, then you know something may be wrong
>
> So making things more difficult for the user, flouting decades-old
> conventions and expectations, is a good thing in your eyes?

What, needing one extra parameter? Typing two words instead of one? This
is what you call being more difficult?

> For some programs it is common practice - such as for "make". And also,
> I believe, for "CMake", "ant", "bake", "nmake", and all other build
> tools I have seen. Basically, people building a project find it really
> easy to go to the project directory and type "make" (or whatever).
> Typing "make -f project_name.mk" would be an unnecessary inconvenience.
> But of course you are free to do that if you want.

I'm not used to seeing major, industrial-grade software being so sloppy.

Imagine if two distinct makefiles somehow get mixed up. Type 'make', and
it will use the wrong makefile. Maybe it will go obviously wrong, maybe not.

> I think you should get some experience with project organisation and
> build tools - then you will understand better. Otherwise, just accept
> that the way these things are done by other people makes a lot of sense
> to everyone else.

Answer honestly: if 'make' had required an explicit filename from the
start (probably it wouldn't have needed '-f'), would anyone have cared
about having to type it?

Bart <bc@freeuk.com> writes:
[...]
> In the Lua project, the two files were called 'makefile'. I suspect
> that if 'make' required an explicit name, they would not both be
> called 'makefile'.

In the tarball distributed from lua.org, the two files are called
"Makefile" and "src/Makefile". (The git repo and the "release"
files available on GitHub are organized differently, as I've already
explained to you. You have no reason to care about those unless
you plan to work on Lua development. I will not discuss them
further here.)

[...]
> What, needing one extra parameter? Typing two words instead of one?
> This is what you call being more difficult?

The file name Makefile implies that it's a file to be used by the make
tool to build one or more artifacts *from the contents of the directory
containing the Makefile*.

Typing "make" is typically one of the steps used to build a software
package from source and install it. Not having a default makefile name
would mean figuring out what name the maintainer chose and then typing
"make arbitrary-file-name".

Most developers organize their directories in a way that works well with
this. If you prefer to use some different organization, well, the "-f"
option is there for you. Nobody's telling you not to use it.

[...]

> I'm not used to seeing major, industrial-grade software being so sloppy.

It's not sloppy. It's optimized for the vastly more common use case.

> Imagine if two distinct makefiles somehow get mixed up. Type 'make',
> and it will use the wrong makefile. Maybe it will go obviously wrong,

So don't do that.

[...]

> Answer honestly: if 'make' had required an explicit filename from the
> start (probably it wouldn't have needed '-f'), would anyone have cared
> about having to type it?

Having to type it? No. Having to figure out what arbitrary name the
author chose? Yes.

The vast majority of the time, there is one Makefile in a directory, and
you just "cd" to that directory and type "make", possibly with some
argument(s) to provide more information. That's why having a default
name is a good thing. And you don't have to use the default if you
don't want to. (There's a common convention to use a ".mk" suffix for
non-default makefiles.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On Friday, 18 August 2023 at 01:47:11 UTC+1, Keith Thompson wrote:
> Bart <b...@freeuk.com> writes:
> [...]
> > In the Lua project, the two files were called 'makefile'. I suspect
> > that if 'make' required an explicit name, they would not both be
> > called 'makefile'.
> In the tarball distributed from lua.org, the two files are called
> "Makefile" and "src/Makefile". (The git repo and the "release"
> files available on GitHub are organized differently, as I've already
> explained to you. You have no reason to care about those unless
> you plan to work on Lua development. I will not discuss them
> further here.)
>
> [...]
> > What, needing one extra parameter? Typing two words instead of one?
> > This is what you call being more difficult?
> The file name Makefile implies that it's a file to be used by the make
> tool to build one or more artifacts *from the contents of the directory
> containing the Makefile*.
>
> Typing "make" is typically one of the steps used to build a software
> package from source and install it. Not having a default makefile name
> would mean figuring out what name the maintainer chose and then typing
> "make arbitrary-file-name".
>
> Most developers organize their directories in a way that works well with
> this. If you prefer to use some different organization, well, the "-f"
> option is there for you. Nobody's telling you not to use it.
>
> [...]
> > I'm not used to seeing major, industrial-grade software being so sloppy.
> It's not sloppy. It's optimized for the vastly more common use case.
> > Imagine if two distinct makefiles somehow get mixed up. Type 'make',
> > and it will use the wrong makefile. Maybe it will go obviously wrong,
> So don't do that.

OK. I won't make any inadvertent mistakes. Got it!

> [...]
> > Answer honestly: if 'make' had required an explicit filename from the
> > start (probably it wouldn't have needed '-f'), would anyone have cared
> > about having to type it?
> Having to type it? No. Having to figure out what arbitrary name the
> author chose? Yes.

Yeah. Figuring out what the executable is called in order to run it afterwards must be a problem too.

Or maybe it's just a.out every time, of course!

Honestly these are ridiculous excuses.The quibble you have is that when you type the name of a program that has a big and important task to do, and usually do that just once, that you have to tell it the name of a file?

However do you manage to run even a text editor?

On 2023-08-17, Bart <bc@freeuk.com> wrote:
> Answer honestly: if 'make' had required an explicit filename from the
> start (probably it wouldn't have needed '-f'), would anyone have cared
> about having to type it?

Yes. You.

bart c <bart4858@gmail.com> writes:
> On Friday, 18 August 2023 at 01:47:11 UTC+1, Keith Thompson wrote:
[...]
>> [...]
>> > Answer honestly: if 'make' had required an explicit filename from the
>> > start (probably it wouldn't have needed '-f'), would anyone have cared
>> > about having to type it?
>> Having to type it? No. Having to figure out what arbitrary name the
>> author chose? Yes.
>
> Yeah. Figuring out what the executable is called in order to run it
> afterwards must be a problem too.

Executables have to have unique names. Makefiles don't.

[...]

> Honestly these are ridiculous excuses.The quibble you have is that
> when you type the name of a program that has a big and important task
> to do, and usually do that just once, that you have to tell it the
> name of a file?

I'm not making excuses. I'm offering explanations.

Those of us who actually use, and sometimes create, Makefiles rarely
have any reason to name them something other than "Makefile". Do you
not understand that? Do you think we're all lying about it? Why would
we bother?

The make command already has an option to use a name other than than
"Makefile". You apparently advocate making it mandatory, which would
require uncounted users to alter the way they work. What exactly would
be the advantage of that?

Do you want to put files for all your projects in a single directory,
with a distinct makefile for each? You can do that.

> However do you manage to run even a text editor?

Be serious.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On Friday, 18 August 2023 at 02:49:38 UTC+1, Kaz Kylheku wrote:
> On 2023-08-17, Bart <b...@freeuk.com> wrote:
> > Answer honestly: if 'make' had required an explicit filename from the
> > start (probably it wouldn't have needed '-f'), would anyone have cared
> > about having to type it?
> Yes. You.

So, nobody who actually uses it. Yet the way it does work is absolutely indispensible and could not possibly be done any other way (like every other C misfeature).

That is, you want to be able to type:

X

and not:

X Y

like nearly every other command line program. Yet being able to do

X Y

instead of:

X Y.Z

on those other programs is anathema.

So either 'X Y' is too much to type, or `X Y' is not enough! Even though you will be using the latter case more often.

It's fascinating watching psychology and group-think at work.

On Friday, August 18, 2023 at 1:01:07 AM UTC+3, Matthew Ernisse wrote:
> On Mon, 14 Aug 2023 02:44:16 -0000 (UTC), Kenny McCormack wrote:
> > In article <8fb22829-9b5e-4108...@googlegroups.com>,
> > Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> > ...
> >>> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
> >>> development environment, so arguing that it doesn't have "make" is kind of
> >>> pointless.
> >
> > I may actually have mis-spoken here. DOS did originally come with GWBASIC,
> > so you could, at least write and run programs back then.
>
> Later DOS version (I think 6+) came with QBASIC which was pretty close to
> an early IDE, reasoned individuals may debate whether it is a development
> environment but I believe I recall single-stepping in it.
>
> > Does modern Windows come with VB.NET ready-to-go, or do you have to
> > download it?
>
> The latest version of Windows 10 Home does not come with any development
> tools that I'm aware of. Even WSL requires installation after the fact.
>
> --
> "The avalanche has started, it is too late for the pebbles to vote."
> --Kosh

They still have a primitive text editor preinstalled and at least two script
engines - cmd.exe and powershell.exe.
I didn't check, but it seems that WSH is here too with JScript and VBScript
engines.

Taking away all traces of user's ability to write his own scripts is probably
very desirable in some corporate environments, but it seems that MS
didn't figure out yet how to do it without breaking few things that corporations
do want.
Or, may be, they did and, I don't know. I have no exposure to desktop OSes
used but big enterprises.

On Thursday, 17 August 2023 at 23:01:07 UTC+1, Matthew Ernisse wrote:
> On Mon, 14 Aug 2023 02:44:16 -0000 (UTC), Kenny McCormack wrote:
> > In article <8fb22829-9b5e-4108...@googlegroups.com>,
> > Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> > ...
> >>> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
> >>> development environment, so arguing that it doesn't have "make" is kind of
> >>> pointless.
> >
> > I may actually have mis-spoken here. DOS did originally come with GWBASIC,
> > so you could, at least write and run programs back then.
>
> Later DOS version (I think 6+) came with QBASIC which was pretty close to
> an early IDE, reasoned individuals may debate whether it is a development
> environment but I believe I recall single-stepping in it.
>
> > Does modern Windows come with VB.NET ready-to-go, or do you have to
> > download it?
>
> The latest version of Windows 10 Home does not come with any development
> tools that I'm aware of. Even WSL requires installation after the fact.

I have WSL but I don't remember having to install it.

Windows is meant as a consumer end-product not for development. Do Android or Mac machines (or Chrome laptops) come with programming tools? Or do those tools only exist because there is some underlying Unix-like system?

On 18/08/2023 01:24, Bart wrote:
> On 17/08/2023 14:45, David Brown wrote:
> > On 16/08/2023 19:07, Bart wrote:
> >> On 16/08/2023 14:16, David Brown wrote:
> >>  > Tell me what you see as the advantage here, and why /you/ think it
> >> would
> >>  > be a jolly good idea, and maybe I'll agree.  But you have to say
> >> why it
> >>  > would be better for everyone, not just for you personally - you need
> >>  > good reasons to change 50 year old conventions.
> >>
> >> [Giving names to makefiles]
> >>
> >> * You can have more than one project in the same folder
> >
> > Makefiles can have multiple targets - that is, in fact, very common. But
> > usually it's a bad idea to have multiple different projects in the same
> > folder.
> >
> >>
> >> * You can have different configurations of the same project
> >
> > I do that all the time with a single makefile.
> >
> >>
> >> * You can have different makefiles customised to different compilers
> >>    (Seed7 has nearly 20 different makefiles)
> >
> > You can do that with a single makefile.
>
> Yes, you can do quite a lot with a single, large, elaborate file. But
> sometimes it's better to have several simpler, dedicated files.

I agree entirely.

Different projects go in different directories, each with their own
makefile. Simple and clear.

And if you need a complex makefile, split it up and have your main
"makefile" include the others.

I am at a loss to see a situation where I would want multiple top-level
makefiles in the same directory. Even if I had a directory containing
sources for programs "foo", "bar" and "wibble", I'd expect a single
top-level "makefile" (which may include extra makefiles if that's
convenient), and I would expect to be able to write "make foo", "make
bar", and "make wibble". I would also expect "make all" to build all
the programs, "make" to build an appropriate default set (maybe all
files, maybe missing a few), and "make clean" to delete all the
generated files. I can't see how "make -f wibble.mak" and "make -f
foo.mak" would be of any advantage.

If you really wanted to do this - perhaps you have pulled together
different projects into one directory and each has a complicated or
specialised makefile - the simple method would be to have a common
"makefile" like this:

default : foo bar

all : foo bar wibble

foo:
$(MAKE) -f foo.mak

bar:
$(MAKE) -f bar.mak

wibble:
$(MAKE) -f wibble.mak

>
> But this sounds familiar: wasn't it you castigating me in the past for
> distributing software as a single C file?

/Distributing/ software as a single C file has some advantages - though
I'd rarely see them as outweighing the many disadvantages. But unless
the code is very small, /developing/ it as a single C file is a terrible
idea. Modular design and dividing code into logically structured parts
is popular for good reason. A single huge C file can be fine if it is
not considered "source" - it is not intended to be read, understood or
modified by human programmers except perhaps while debugging the code
generation tool that made it.

I am not advocating for having monolithic huge makefiles. I am
advocating for having a makefile called "makefile" as the user-accessed
makefile. If you have a complex project and it's too big to be easily
understood or handled as a single file, by all means split it up - then
"makefile" is your top-level file that users use with "make", and other
makefiles are either included, or called by the main makefile.

>
> You got the incorrect idea that that was how I developed the software
> (as a single 40,000-line module).
>
> It sounds a lot like double standards: when I use a single file, even
> though it has its own name that must be submitted to the tool, it's bad.
>
> But when makefiles do it, it's good! And they're all allowed to have the
> same name no matter what the project.
>
> A bit like the Lua product in my other post. When I make a 300KB
> self-contained language, it's bad, it's pointless, it's rubbish, it's a
> toy.
>
> When Lua does the same thing, then what a great product!
>

Your language is a volatile person-specific creation that is made by one
person, made with just one person's needs, wants, preferences,
experiences, and abilities, as stable or unstable as that one person's
mood takes them, undocumented, unspecified, unmaintainable, unused by
others. The day you are unwilling or unable to do anything with it, the
language dies. That won't matter to any other developers, because there
are no other developers using it - but it might be a disaster for your
customers if they have not moved on.

Perhaps, if circumstances (and your interests and focus) had been
different, your language could have taken off and become popular and a
serious language. Clearly you are convinced it is far superior to
anything else, and maybe there are others who would agree with you -
maybe it had great potential as the start of a major programming
language. But the fact is, your language has not gone beyond its larval
stage.

Lua is a major language with perhaps hundreds of thousands of users,
solid academic and commercial backing, and - crucially - is created and
developed by many people with feedback from many users.

There is simply no comparison.

>
> > Call the main one "makefile", and the other one "other_bit.mak" - this
> > is fine and perfectly normal.
>
> In the Lua project, the two files were called 'makefile'. I suspect that
> if 'make' required an explicit name, they would not both be called
> 'makefile'.
>

On what basis do you assume that? Even when explicit names are
required, there are often conventions. Every Python class uses "self"
as the reference to the object, despite it being completely arbitrary in
the language.

The two "makefile" files are different, in different directories, and
serving different purposes. This is normal - it is not something
unexpected or unusual.

> >>
> >> * If you expected to build X according to the build instructions,
> >>    but the makefile is called Y, then you know something may be wrong
> >
> > So making things more difficult for the user, flouting decades-old
> > conventions and expectations, is a good thing in your eyes?
>
> What, needing one extra parameter? Typing two words instead of one? This
> is what you call being more difficult?
>

A major point of build tools is to avoid having to type more when doing
your builds - "make" is sufficient. Adding a filename does not make
anything simpler or less error-prone - it makes it /more/ error-prone.

>
> > For some programs it is common practice - such as for "make".  And also,
> > I believe, for "CMake", "ant", "bake", "nmake", and all other build
> > tools I have seen.  Basically, people building a project find it really
> > easy to go to the project directory and type "make" (or whatever).
> > Typing "make -f project_name.mk" would be an unnecessary inconvenience.
> > But of course you are free to do that if you want.
>
> I'm not used to seeing major, industrial-grade software being so sloppy.
>

You are not used to seeing major, industrial-grade software at all. You
are used to condemning software out of hand, without more than the
briefest glance.

> Imagine if two distinct makefiles somehow get mixed up. Type 'make', and
> it will use the wrong makefile. Maybe it will go obviously wrong, maybe
> not.

You go to the right directory, and type "make". If you are in the wrong
directory, all kinds of things can go wrong with all kinds of commands.
Why are you worried about "make" ? You really are getting worked up
about absolutely nothing.

>
> > I think you should get some experience with project organisation and
> > build tools - then you will understand better.  Otherwise, just accept
> > that the way these things are done by other people makes a lot of sense
> > to everyone else.
>
> Answer honestly: if 'make' had required an explicit filename from the
> start (probably it wouldn't have needed '-f'), would anyone have cared
> about having to type it?
>

Most people would probably not.

On 18/08/2023 04:13, Keith Thompson wrote:
> bart c <bart4858@gmail.com> writes:
>> On Friday, 18 August 2023 at 01:47:11 UTC+1, Keith Thompson wrote:
> [...]
>>> [...]
>>>> Answer honestly: if 'make' had required an explicit filename from the
>>>> start (probably it wouldn't have needed '-f'), would anyone have cared
>>>> about having to type it?
>>> Having to type it? No. Having to figure out what arbitrary name the
>>> author chose? Yes.
>>
>> Yeah. Figuring out what the executable is called in order to run it
>> afterwards must be a problem too.
>
> Executables have to have unique names. Makefiles don't.
>
> [...]
>
>> Honestly these are ridiculous excuses.The quibble you have is that
>> when you type the name of a program that has a big and important task
>> to do, and usually do that just once, that you have to tell it the
>> name of a file?
>
> I'm not making excuses. I'm offering explanations.
>
> Those of us who actually use, and sometimes create, Makefiles rarely
> have any reason to name them something other than "Makefile". Do you
> not understand that? Do you think we're all lying about it? Why would
> we bother?
>
> The make command already has an option to use a name other than than
> "Makefile". You apparently advocate making it mandatory, which would
> require uncounted users to alter the way they work. What exactly would
> be the advantage of that?

Note that it is very simple to make it mandatory for any given project
(or jumble of projects thrown together in one directory) - simply do not
have a makefile called "makefile" (or "Makefile"), and have a selection
of different ".mk" files instead. So if Bart wants that, "make" already
supports it.

>
> Do you want to put files for all your projects in a single directory,
> with a distinct makefile for each? You can do that.
>
>> However do you manage to run even a text editor?
>
> Be serious.
>

On Fri, 18 Aug 2023 04:58:53 -0700 (PDT), bart c wrote:
>
> Windows is meant as a consumer end-product not for development. Do
> Android or Mac machines (or Chrome laptops) come with programming tools?
> Or do those tools only exist because there is some underlying Unix-like
> system?

I don't use Android or Chrome systems so I do not know. Modern versions of
macOS ship with several interpreted language parsers as well as several
scriptable shells but the major development environment and tooling
(XCode in this case) require a separate download.

I think it all comes down to how nitpicky you want to get about the various
values of 'development tools' and 'come with'. As far as I'm aware all
modern operating system installations can be customized to some extent.
I'm certain I can produce a Debian Linux install devoid of a C compiler
and I could probably produce a Windows installation that comes with Visual
Studio.

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh

On Fri, 18 Aug 2023 14:50:28 +0200, David Brown wrote:
[snip]

> I am at a loss to see a situation where I would want multiple top-level
> makefiles in the same directory.

In projects that support multiple disparate platforms, it is common to see
multiple top-level makefiles, such that there is one makefile for each platform.

For example, the "lame" project (https://lame.sourceforge.io/) includes
- a Unix Makefile for systems that use the configure script,
- a Unix Makefile for systems that do not use the configure script, and
- a Windows Makefile for systems with MSVC

[snip]

--
Lew Pitcher
"In Skills We Trust"

On 17/08/2023 18:16, Bart wrote:
> On 16/08/2023 14:16, David Brown wrote:
> > On 16/08/2023 13:15, Bart wrote:
> > Then there is the question of why it matters.  PC disks are big.  PC
> > CPUs are fast.  Network speeds are high.  Top quality development tools
> > and utilities are freely available - even on Windows.  Size and speed
> > matters very little for software on PC's.  (It matters a great deal on
> > small embedded systems.)
>
> And yet... when I reinstalled CMake, it took nearly 10 minutes to unzip
> 7300 files into 112MB, on an SSD. I don't why it took that long, but it
> did.

If those 10 minutes matter to you so much, I recommend cutting down on
posting nonsense to Usenet. It would save you a lot more than 10 minutes.

(But note that I am not a CMake user - I don't know why it is so big,
because I don't know its features.)

>
> (There's also the mystery of why it takes such a humungous program to
> ... turn a file-spec info into a makefile? I could do that by hand in
> less than 10 minutes! In the end CMake couldn't even complete the task:
> maybe 7300 files wasn't quite enough.
>
> But I think you're not keen on CMake anyway.)
>
> When I tried to install VS once, although on an older machine with a
> hard drive, it took 90 minutes. Each time it started up (usually
> inadvertently because of a file association), it took 90 seconds.
>

MSVC is a /huge/ set of programs with a massive feature list. I'm not
going to try to argue why they are necessary - I don't use it myself,
because it is not for the kind of programming I do. But you seem to be
surprised that it is faster to take a bicycle out of your garage than to
prepare a 747 for flight.

> On the same machine, my programs started instantly.
>
>
> >
> > So who are you fighting for?  Who are you fighting against?  Do you
> > really think you are making a difference for some greater good here, or
> > even just for your own personal benefit?
>
> There are a huge number of benefits to keeping things small and
> managable. You don't understand what they are because of using top-end
> hardware, and using systems and tools that many people use in your field
> so that things run smoothly; an issues will have been fixed or patches.
>
> Lots of people have also piled on extra complexity to get around
> problems of sluggishness: being extra clever in avoiding repeating the
> work.
>
> Or just throwing an extra 31 cores at the problem.
>

I note you didn't answer my questions - you've just told us that
software has grown bigger over time.

>
> > (There's nothing wrong with
> > doing it for your own benefit - I am not suggesting you have to fight
> > for other people.)
>
> This is an analogy I have used before regarding LLVM, which is a backend
> for language implementations. It is quite large and complex.
>
> Once I needed a side-gate for my house. I made it myself, and ended up
> with a 6' high wooden gate, of just the right size.
>
> Now if I'd gone to the LLVM shop as a solution, the gate would have been
> 9 miles high - if I could ever figure it out.
>

As analogies go, that's a particularly silly one.

> >  Have you considered whether there are other battles
> > that would make more sense or have greater impact?  Have you considered
> > forgetting it all, splashing out £300 on a new mini-PC, installing Linux
> > Mint, and going back to having fun with computers, learning new things,
> > and creating software without bothering about how much space gcc
> takes up?
>
> Lots of people are having fun with retrocomputing, where they can be 99%
> responsible for what's going on rather than 1%. And there is it can
> challenging, in a fun way, to have limits on what is possible.

Sure.

One of the things I like about working with small microcontrollers is
that I can be 100% responsible for what is going on.

I can fully understand the interest in doing things yourself, or
creating things from scratch, or writing your own little tools - just as
I understand people making a box to run old Atari games.

What I /don't/ understand is how enjoying that kind of thing turns into
a hatred and condemnation of all other kinds of systems, software,
languages, tools and developers. I like low-level embedded programming
- that doesn't mean I think Perl is an abomination, that people who
write Oracle database scripts are living in denial, or that I should
join a Sketch forum and tell all the kids that they are doing it all wrong.

>
> However, you're wrong about space ceasing to be an issue: devices such
> as smartphones, despite having GBs of storage rapidly get filled up
> because every downloaded app is 10s of MB and sometimes 100s.

99% of that space is media - graphics, videos, sounds - not code.

>
> Because nobody cares anymore.

It makes sense to care appropriately. Worry more about kids spending
hours every day on their phones, not about apps taking megabytes of
space. Or even better - worry about something where you can actually
make a difference, even a small one.

>
> >>
> >> Of course, you are NEVER going to admit that doing:
> >>
> >>    mm lua
> >>
> >> might be a touch sweeter than those 330 lines of makefile crap below.
> >
> > I fail to see how that's better than "make" (or "make mingw" on
> > Windows).
>
> And here is the crux. You really believe that you can solve 'complexity'
> by hiding it away in a box and providing one simple launch button.

Yes, that is correct. The way to deal with inevitable complexity is to
compartmentalise and organise - divide and conquer. Put complex bits in
boxes and close the lids, so that you can have a simpler overview. That
is /exactly/ how you deal with things that must be complex.

Perhaps you are under the mistaken impression that the build process for
Lua does not have to be complex, and therefore you want to solve it by
simplifying it? If that's the case, you are simply wrong - as you'd see
by actually looking at the makefiles rather than obsessing about their
size and assuming anything over your own totally arbitrary limits is
useless.

>
> My preference is to tackle complexity by actually (gasp!) making it
> simpler not just piling on even more stuff.
>

Oh, look - I was right. I had correctly guessed you had misunderstood
the situation entirely.

> (Here's the David Brown approach to editing a messy 10,000-page draft of
> a book down to 500 pages: just print it in a smaller font to fit into
> 500 pages; easy!
>
> Or publish it on Kindle: nobody has a clue how long anything is on one
> of those anyway. It will just take ages to get from 0% to 1%.
>
> You might object, but this is exactly what happens with software: there
> we now have unlimited amounts of program memory, and NOBODY apparently
> cases about size, bloat, inefficiency and gratuitous complexity.
>

Your mistake is to assume that complexity is necessarily gratuitous.

I'm not going to deny that /some/ complexity may be gratuitous. But a
lot is not - things can be big and complex because they do many things,
or have many features, or are used by many people. Sometimes things
appear complex because that is actually the simplest way to handle them
- simple to use may mean complex to implement, or vice versa.

And very often, things are big and complex because that is the cheapest
or fastest way to make it happen.

If I have a customer than needs a Windows executable that finds the most
common word in a text file, I might supply a program that is some 10 MB
or more. Why? Because the /simplest/ solution to develop would be a
few lines of Python code, packed up with "py2exe" in a bundle that
includes the Python interpreter and libraries. Viewed as naïvely as you
look at the work, it would be bloat, inefficiency and complexity -
viewed by the customer it would be simple to use and cheap to buy, and
viewed by the developer it would be simple to make and maintain.

Yes, MSVC is huge, bloated and inefficient - and I have no doubt MS
could produce tools with the same features at a tenth of the size. But
doing so would cost ten times as much.

It's not that other people don't care about complexity - it is that you
have such a blinkered, self-centred view of software that you can't see
the bigger picture.

> Well, until it comes to the difference between say Tcc and gcc/LLVM,
> where 99% of the latter's build time is spent making programs twice as
> fast as with the 180KB tcc.exe.
>

Most programs are run more than 50 times as often as they are compiled,
so that's a big win for gcc/llvm.

On Friday, August 18, 2023 at 4:33:08 PM UTC+3, David Brown wrote:
> On 17/08/2023 18:16, Bart wrote:
> > On 16/08/2023 14:16, David Brown wrote:
> > > On 16/08/2023 13:15, Bart wrote:
> > > Then there is the question of why it matters. PC disks are big. PC
> > > CPUs are fast. Network speeds are high. Top quality development tools
> > > and utilities are freely available - even on Windows. Size and speed
> > > matters very little for software on PC's. (It matters a great deal on
> > > small embedded systems.)
> >
> > And yet... when I reinstalled CMake, it took nearly 10 minutes to unzip
> > 7300 files into 112MB, on an SSD. I don't why it took that long, but it
> > did.
> If those 10 minutes matter to you so much, I recommend cutting down on
> posting nonsense to Usenet. It would save you a lot more than 10 minutes.
>

10 minutes to unzip 7300 files into 112MB, on an SSD is certainly unusual.

I had seen a similar extremely slow unzip (I think, it was even slower) few
years ago unzipping ARM's suit "embedded" suit. By now I don't remember
whether it came from ARM Inc or from one of the other common places
like code sorcery. But in my case it was a self-extracted exe.

What it shows is lack of care on part of packagers, because it is very
easy to avoid such slow unzip times. Most likely just unzipping on
Windows and then re-zipping with native tool like 7zip will speed the
unzip process for a user by factor of 10 or more with no impact on
archive size.

> (But note that I am not a CMake user - I don't know why it is so big,
> because I don't know its features.)
> >
> > (There's also the mystery of why it takes such a humungous program to
> > ... turn a file-spec info into a makefile? I could do that by hand in
> > less than 10 minutes! In the end CMake couldn't even complete the task:
> > maybe 7300 files wasn't quite enough.
> >
> > But I think you're not keen on CMake anyway.)
> >
> > When I tried to install VS once, although on an older machine with a
> > hard drive, it took 90 minutes. Each time it started up (usually
> > inadvertently because of a file association), it took 90 seconds.
> >
> MSVC is a /huge/ set of programs with a massive feature list. I'm not
> going to try to argue why they are necessary - I don't use it myself,
> because it is not for the kind of programming I do. But you seem to be
> surprised that it is faster to take a bicycle out of your garage than to
> prepare a 747 for flight.
> > On the same machine, my programs started instantly.
> >
> >
> > >
> > > So who are you fighting for? Who are you fighting against? Do you
> > > really think you are making a difference for some greater good here, or
> > > even just for your own personal benefit?
> >
> > There are a huge number of benefits to keeping things small and
> > managable. You don't understand what they are because of using top-end
> > hardware, and using systems and tools that many people use in your field
> > so that things run smoothly; an issues will have been fixed or patches.
> >
> > Lots of people have also piled on extra complexity to get around
> > problems of sluggishness: being extra clever in avoiding repeating the
> > work.
> >
> > Or just throwing an extra 31 cores at the problem.
> >
> I note you didn't answer my questions - you've just told us that
> software has grown bigger over time.
> >
> > > (There's nothing wrong with
> > > doing it for your own benefit - I am not suggesting you have to fight
> > > for other people.)
> >
> > This is an analogy I have used before regarding LLVM, which is a backend
> > for language implementations. It is quite large and complex.
> >
> > Once I needed a side-gate for my house. I made it myself, and ended up
> > with a 6' high wooden gate, of just the right size.
> >
> > Now if I'd gone to the LLVM shop as a solution, the gate would have been
> > 9 miles high - if I could ever figure it out.
> >
> As analogies go, that's a particularly silly one.
> > > Have you considered whether there are other battles
> > > that would make more sense or have greater impact? Have you considered
> > > forgetting it all, splashing out £300 on a new mini-PC, installing Linux
> > > Mint, and going back to having fun with computers, learning new things,
> > > and creating software without bothering about how much space gcc
> > takes up?
> >
> > Lots of people are having fun with retrocomputing, where they can be 99%
> > responsible for what's going on rather than 1%. And there is it can
> > challenging, in a fun way, to have limits on what is possible.
> Sure.
>
> One of the things I like about working with small microcontrollers is
> that I can be 100% responsible for what is going on.
>
> I can fully understand the interest in doing things yourself, or
> creating things from scratch, or writing your own little tools - just as
> I understand people making a box to run old Atari games.
>
> What I /don't/ understand is how enjoying that kind of thing turns into
> a hatred and condemnation of all other kinds of systems, software,
> languages, tools and developers. I like low-level embedded programming
> - that doesn't mean I think Perl is an abomination, that people who
> write Oracle database scripts are living in denial, or that I should
> join a Sketch forum and tell all the kids that they are doing it all wrong.
> >
> > However, you're wrong about space ceasing to be an issue: devices such
> > as smartphones, despite having GBs of storage rapidly get filled up
> > because every downloaded app is 10s of MB and sometimes 100s.
> 99% of that space is media - graphics, videos, sounds - not code.
>
> >
> > Because nobody cares anymore.
>
> It makes sense to care appropriately. Worry more about kids spending
> hours every day on their phones, not about apps taking megabytes of
> space. Or even better - worry about something where you can actually
> make a difference, even a small one.
> >
> > >>
> > >> Of course, you are NEVER going to admit that doing:
> > >>
> > >> mm lua
> > >>
> > >> might be a touch sweeter than those 330 lines of makefile crap below..
> > >
> > > I fail to see how that's better than "make" (or "make mingw" on
> > > Windows).
> >
> > And here is the crux. You really believe that you can solve 'complexity'
> > by hiding it away in a box and providing one simple launch button.
> Yes, that is correct. The way to deal with inevitable complexity is to
> compartmentalise and organise - divide and conquer. Put complex bits in
> boxes and close the lids, so that you can have a simpler overview. That
> is /exactly/ how you deal with things that must be complex.
>
> Perhaps you are under the mistaken impression that the build process for
> Lua does not have to be complex, and therefore you want to solve it by
> simplifying it? If that's the case, you are simply wrong - as you'd see
> by actually looking at the makefiles rather than obsessing about their
> size and assuming anything over your own totally arbitrary limits is
> useless.
> >
> > My preference is to tackle complexity by actually (gasp!) making it
> > simpler not just piling on even more stuff.
> >
> Oh, look - I was right. I had correctly guessed you had misunderstood
> the situation entirely.
> > (Here's the David Brown approach to editing a messy 10,000-page draft of
> > a book down to 500 pages: just print it in a smaller font to fit into
> > 500 pages; easy!
> >
> > Or publish it on Kindle: nobody has a clue how long anything is on one
> > of those anyway. It will just take ages to get from 0% to 1%.
> >
> > You might object, but this is exactly what happens with software: there
> > we now have unlimited amounts of program memory, and NOBODY apparently
> > cases about size, bloat, inefficiency and gratuitous complexity.
> >
> Your mistake is to assume that complexity is necessarily gratuitous.
>
> I'm not going to deny that /some/ complexity may be gratuitous. But a
> lot is not - things can be big and complex because they do many things,
> or have many features, or are used by many people. Sometimes things
> appear complex because that is actually the simplest way to handle them
> - simple to use may mean complex to implement, or vice versa.
>
> And very often, things are big and complex because that is the cheapest
> or fastest way to make it happen.
>
> If I have a customer than needs a Windows executable that finds the most
> common word in a text file, I might supply a program that is some 10 MB
> or more. Why? Because the /simplest/ solution to develop would be a
> few lines of Python code, packed up with "py2exe" in a bundle that
> includes the Python interpreter and libraries. Viewed as naïvely as you
> look at the work, it would be bloat, inefficiency and complexity -
> viewed by the customer it would be simple to use and cheap to buy, and
> viewed by the developer it would be simple to make and maintain.
>
> Yes, MSVC is huge, bloated and inefficient - and I have no doubt MS
> could produce tools with the same features at a tenth of the size. But
> doing so would cost ten times as much.
>

On 17/08/2023 20:51, Bart wrote:
> On 16/08/2023 11:52, David Brown wrote:
> > On 16/08/2023 11:34, Malcolm McLean wrote:
> >> My understanding of Lua is that, whilst it can be used as a standalone
> >> language, it's really meant for adding scripting to applications.
> >
> > Certainly embedding it within other applications is a major purpose of
> > the language, yes.
>
> And to that end, Lua is a small language that can be implemented in a
> few 100KB, including as one DLL file.
>
> I think Tiny C can also be used as a bundled backend.
>
> But, I'm confused: according to you, it doesn't matter at all how big
> any product is, since hardware resources are essentially unlimited.

If you are confused, that is because you either don't read what I write,
or you infer incorrectly from what you imagine I wrote. And sometimes I
might be unclear in what I write.

But I thought I was really quite explicit in saying that size rarely
matters on big systems (like PC's), but is very important on most small
embedded systems. To be fair, however, "embedded" can mean two things
here - "included inside another program" or "electronics in some object,
usually much less powerful than a PC or modern mobile telephone".

So if I have a program on my Linux or Windows system that has use of an
embedded scripting language, I really don't care if it uses an so or DLL
that is 100 KB or 100 MB. If I am adding a scripting language to an
embedded microcontroller, I /do/ care.

>
> So why is it better that a product like Lua is small and self-contained?
>
> Why would it matter if it was 100MB and embedding it involved grappling
> with 25,000 source files across 3,000 nested folders and took an hour
> extra to build, dwarfing half the products it was used with?
>

It matters depending on the target system - PC's have no problem with
100MB of files, but a small microcontroller /does/ have a problem with it.

Of course for any system you will also want to have modularisation and
compartmentalisation. If you have a program that is getting big enough,
you will usually want to split it into DLL's / so files - that makes
development far easier as different teams will work on different parts,
and communicate through well-defined interfaces. That does not apply in
the same way to most small embedded systems, where dynamic linking is
not an option. But if you wanted Python as a scripting language in your
PC application, you'd have Python DLL's (and probably not bother
compiling them yourself at all), whereas Lua is small enough that you
might choose to build it directly with your application instead.

This is all common sense - I don't know why you find it difficult to
understand.

> Yet, when *I* try and keep my products small, compact and streamlined,
> then it is apparently totally pointless.

Write your own programs the way you want to.

But don't try to tell others that your programs are great because they
are small, and others are terrible because they are big. If size
doesn't matter on the target system, then being small - as an aim in
itself - is pointless. It really is that simple.

Size of the source code can, of course, have an influence on its
maintainability and how easy it is to work with the source. But it is
not close to being the most important aspect - how well the code is
written, organised and documented are much more important.

It's the same with speed. Unless you are competing in some benchmark
competition, then speed is not helpful as an overriding concern. If
something is fast enough, it is fast enough - faster will then not be
better. It is only when the speed translates to something important
that it is relevant. So if faster software on your fitness armband
means the microcontroller can spend more time in sleep mode and thus
your battery lasts longer, then speed is important. But if it means
your compile time is 0.1 seconds instead of 0.2 seconds, it does not
matter at all. And if the advanced compiler time on the PC takes an
hour, but reduces the run-time on the armband by 10%, saving 10% battery
power, then the advanced compiler is much better. Can you understand
the difference here?

>
> You told me my aims are so futile, I should give up, and buy a Linux
> machine and become just another cog.

I'm just suggesting something that you might enjoy more than endlessly
tilting at windmills.

>
> A bit like telling an amateur film-maker to give that up and buy a
> cinema season-ticket instead.
>
>
> > It is becoming more mature as a stand-alone
> > language, with more libraries, but it is very popular for adding to
> > other programs.  As you say, Lua is a common choice for scripting in
> > games.  I used it myself as a scripting language in an embedded program,
> > many moons ago.
> >
> >> If you're
> >> writing the game level editor then of course the programmer works
> >> closely with the users, and it's acceptable to have the level editor
> >> call a binary executable. But if you want scripting in the game itself
> >> then
> >> you have to include the Lua source code.
> >>
> >> S yes, users rather than developers of Lua itself have to be able to
> >> incorporate it into a project and compile it easily.
> >>
> >
> > Sure.  But if you want to do that, you read the relevant sections of the
> > manual and see which files you need, which options you want, what
> > configuration you want, and how you should combine it with your own
> > code.
>
> I'm working on something like that right now. A much smaller, more
> dynamic, more easily embeddable version of my current scripting language.
>
> Totally futile of course. But it is my choice. Making things small,
> compact, simple and fast isn't that easy.
>

The futility or not depends on your aims, what you try to do with it,
and how you market it.

If you make a simple little language then go to the Lua forums and tell
everyone how crap and bloated Lua is, then your effort is futile.

If you make a decent little language with documentation, examples and
information, gather users and feedback (and listen to that feedback),
and build it as a community and a new alternative as an embeddable
scripting language with enthusiasts using it, maintaining it, improving
it, and supporting it, then that would be fantastic. I'd be happy to
consider it for my own use - and certainly happy for your achievement.

I know you are capable of taking the second path here. I worry, based
on years of Usenet posting, that you will take the first path.

There is a third option - you do this just as a hobby for your own
interests and enjoyment, and understand its limitations, and that's
great too.

It's only futile when you build yourself a tree-house and tell people
it's better than the Empire State Building, and that you are fighting
against bloated and inefficient houses.

On Friday, 18 August 2023 at 14:33:08 UTC+1, David Brown wrote:
> On 17/08/2023 18:16, Bart wrote:
> > On 16/08/2023 14:16, David Brown wrote:
> > > On 16/08/2023 13:15, Bart wrote:
> > > Then there is the question of why it matters. PC disks are big. PC
> > > CPUs are fast. Network speeds are high. Top quality development tools
> > > and utilities are freely available - even on Windows. Size and speed
> > > matters very little for software on PC's. (It matters a great deal on
> > > small embedded systems.)
> >
> > And yet... when I reinstalled CMake, it took nearly 10 minutes to unzip
> > 7300 files into 112MB, on an SSD. I don't why it took that long, but it
> > did.
> If those 10 minutes matter to you so much, I recommend cutting down on
> posting nonsense to Usenet. It would save you a lot more than 10 minutes.
>
> (But note that I am not a CMake user - I don't know why it is so big,
> because I don't know its features.)
> >
> > (There's also the mystery of why it takes such a humungous program to
> > ... turn a file-spec info into a makefile? I could do that by hand in
> > less than 10 minutes! In the end CMake couldn't even complete the task:
> > maybe 7300 files wasn't quite enough.
> >
> > But I think you're not keen on CMake anyway.)
> >
> > When I tried to install VS once, although on an older machine with a
> > hard drive, it took 90 minutes. Each time it started up (usually
> > inadvertently because of a file association), it took 90 seconds.
> >
> MSVC is a /huge/ set of programs with a massive feature list. I'm not
> going to try to argue why they are necessary - I don't use it myself,
> because it is not for the kind of programming I do. But you seem to be
> surprised that it is faster to take a bicycle out of your garage than to
> prepare a 747 for flight.
> > On the same machine, my programs started instantly.
> >
> >
> > >
> > > So who are you fighting for? Who are you fighting against? Do you
> > > really think you are making a difference for some greater good here, or
> > > even just for your own personal benefit?
> >
> > There are a huge number of benefits to keeping things small and
> > managable. You don't understand what they are because of using top-end
> > hardware, and using systems and tools that many people use in your field
> > so that things run smoothly; an issues will have been fixed or patches.
> >
> > Lots of people have also piled on extra complexity to get around
> > problems of sluggishness: being extra clever in avoiding repeating the
> > work.
> >
> > Or just throwing an extra 31 cores at the problem.
> >
> I note you didn't answer my questions - you've just told us that
> software has grown bigger over time.
> >
> > > (There's nothing wrong with
> > > doing it for your own benefit - I am not suggesting you have to fight
> > > for other people.)
> >
> > This is an analogy I have used before regarding LLVM, which is a backend
> > for language implementations. It is quite large and complex.
> >
> > Once I needed a side-gate for my house. I made it myself, and ended up
> > with a 6' high wooden gate, of just the right size.
> >
> > Now if I'd gone to the LLVM shop as a solution, the gate would have been
> > 9 miles high - if I could ever figure it out.
> >
> As analogies go, that's a particularly silly one.

LLVM in concept is simple: feed it some IL (or it calls it IR), and it turns it into a runnable binary. The actuality is very different.

I created my own similar product in 2021, which was a 0.2MB binary. The downloads needs to get started with LLVM are some 2.3GB. That's how you get from 6 feet to 9 miles. But the biggest obstacle is the sheer complexity, with 100 /sets/ of documentation.

(I have another experiment product now which interprets such an IL. It is 80KB.)

> What I /don't/ understand is how enjoying that kind of thing turns into
> a hatred and condemnation of all other kinds of systems, software,
> languages, tools and developers.

Not all. I quite admire Tiny C for example. When I was transpiling to C, the generated output required a C compiler to produce a runnable binary. The simplest and smallest such product comprises 3 files of Tiny C totalling 0.23MB (the compiler, a library and I forget what else), out of a 1.6MB tcc installation. It can easily be bundled if the licensing allows, and it allows for a fast and transparent backend.

A version of GHC that bundled gcc was 2.8GB in total; it didn't work.

While there are lots of command line tools I use and admire because they are small, simple and do the job, like PKZIP and UPX for example.

> > And here is the crux. You really believe that you can solve 'complexity'
> > by hiding it away in a box and providing one simple launch button.
> Yes, that is correct. The way to deal with inevitable complexity is to
> compartmentalise and organise - divide and conquer. Put complex bits in
> boxes and close the lids, so that you can have a simpler overview. That
> is /exactly/ how you deal with things that must be complex.

I call that 'brushing things under the carpet'!

> Perhaps you are under the mistaken impression that the build process for
> Lua does not have to be complex, and therefore you want to solve it by
> simplifying it? If that's the case, you are simply wrong - as you'd see
> by actually looking at the makefiles rather than obsessing about their
> size and assuming anything over your own totally arbitrary limits is
> useless.

Building Lua as a self-contained interpreter involves compiling 33 .c files into lua.exe, end of. (A binary Lua installation will also have a 3.5MB lua51.dll file. I don't know where that comes from; there aren't enough C files in the .tar.gz source bundle to account for that amount of code. But lua..exe can run Lua programs.)

> Your mistake is to assume that complexity is necessarily gratuitous.

Everybody knows about bloat and knows it happens. MS are masters at this, but others are giving them a run for their money.

I remember reading, and this was maybe 20 years ago, that VS comprised 1.5 million files, and took 60 hours to build, optimised. I guess people using such tools would have a shock developing on an 8-bit microcomputer. (*I* would have a shock now, and I used to do it!)

> And very often, things are big and complex because that is the cheapest
> or fastest way to make it happen.
>
> If I have a customer than needs a Windows executable that finds the most
> common word in a text file, I might supply a program that is some 10 MB
> or more. Why? Because the /simplest/ solution to develop would be a
> few lines of Python code, packed up with "py2exe" in a bundle that
> includes the Python interpreter and libraries. Viewed as naïvely as you
> look at the work, it would be bloat, inefficiency and complexity -
> viewed by the customer it would be simple to use and cheap to buy, and
> viewed by the developer it would be simple to make and maintain.

I can take complexity if it's properly packaged, doesn't get in the way, and doesn't expose its workings in ways that can cause failures. And it works.. In short, it doesn't cause me grief.

After all OSes are pretty complex now. But those things aren't always the case.

I liked another analogy, a light-bulb one: you flick a switch and the light would come on. That's how lots of things used to work. Then they started getting microprocessors inside. And now, you have delays, and things going wrong.

When I turn on my internet-connected TV, I usually have a book to read as a backup.

On 18/08/2023 16:48, bart c wrote:
> On Friday, 18 August 2023 at 14:33:08 UTC+1, David Brown wrote:
>> On 17/08/2023 18:16, Bart wrote:

>>> This is an analogy I have used before regarding LLVM, which is a backend
>>> for language implementations. It is quite large and complex.
>>>
>>> Once I needed a side-gate for my house. I made it myself, and ended up
>>> with a 6' high wooden gate, of just the right size.
>>>
>>> Now if I'd gone to the LLVM shop as a solution, the gate would have been
>>> 9 miles high - if I could ever figure it out.
>>>
>> As analogies go, that's a particularly silly one.
>
> LLVM in concept is simple: feed it some IL (or it calls it IR), and it turns it into a runnable binary. The actuality is very different.
>
> I created my own similar product in 2021, which was a 0.2MB binary. The downloads needs to get started with LLVM are some 2.3GB. That's how you get from 6 feet to 9 miles. But the biggest obstacle is the sheer complexity, with 100 /sets/ of documentation.
>

Doesn't the quantity of documentation in llvm give you a hint that
perhaps your product is /not/ similar?

On Friday, 18 August 2023 at 15:44:21 UTC+1, David Brown wrote:\>
>But if you wanted Python as a scripting language in your
> PC application, you'd have Python DLL's (and probably not bother
> compiling them yourself at all), whereas Lua is small enough that you
> might choose to build it directly with your application instead.
>
Exactly. Weight matters. Lua is embeddable as scripting language whilst
Python is not.
>
> It's the same with speed. Unless you are competing in some benchmark
> competition, then speed is not helpful as an overriding concern. If
> something is fast enough, it is fast enough - faster will then not be
> better
>
it's very important for us because we write interactive tools to deal with
vector artwork. The more artwork the artists can throw at us whilst
keeping the tool smooth and responsive, the more they will use it.
>
> If you make a decent little language with documentation, examples and
> information, gather users and feedback (and listen to that feedback),
> and build it as a community and a new alternative as an embeddable
> scripting language with enthusiasts using it, maintaining it, improving
> it, and supporting it, then that would be fantastic. I'd be happy to
> consider it for my own use - and certainly happy for your achievement.
>
I did that with MiniBasic. I expected it to be used as a scripting language
for big hosted applications. But in fact it found its niche on micro-
controllers. I did consider getting a Raspberry PI. But electronics isn't
my game.