On 08/02/2024 13:15, Malcolm McLean wrote:
> On 08/02/2024 11:45, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> No. It means writing the code in a way which is common in C and has
>>> certain
>>> advantages, but is not so in other languages.
>>
>> Where do you get your superior knowledge of English from, and is there a
>> way anyone else can hope to achieve your level of competence?
>>
> Degree in English literature.

I would never have guessed that from the way you write and from how
often you fail to read other people's posts.

On 08/02/2024 12:29, David Brown wrote:
> On 08/02/2024 13:15, Malcolm McLean wrote:
>> On 08/02/2024 11:45, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> No. It means writing the code in a way which is common in C and has
>>>> certain
>>>> advantages, but is not so in other languages.
>>>
>>> Where do you get your superior knowledge of English from, and is there a
>>> way anyone else can hope to achieve your level of competence?
>>>
>> Degree in English literature.
>
> I would never have guessed that from the way you write and from how
> often you fail to read other people's posts.
>

What an Oxford English tutor mostly cares about is that the essay is
produced. Not so much what it says. You'll always get some marks for
writing something and will therefore pass, but you can get no marks for
nothing and can only fail. So handing in a stupid essay is acceptable
but not handing in the essay at all is a big no no and tutors really
hate that. It's all about pulling something together in a tight deadline
on a subject about which you knew absolutely nothing last week, and
that's what they value. So it does encourage a rather slapdash approach
and reading things quickly, and maybe that is a fault.

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

On 08/02/2024 12:24, David Brown wrote:
> On 08/02/2024 13:10, Malcolm McLean wrote:
>> On 08/02/2024 11:37, Ben Bacarisse wrote:
>>> bart <bc@freeuk.com> writes:
>>>
>>>> That sounds like your opinion against mine. It's nothing to do with
>>>> spin,
>>>> whatever that means.
>>>
>>> It's spin, because the term is emotive.  "Cluttering up" is how you feel
>>> about it.  The phrase is just a mildly pejorative one about appearances.
>>> There's no substance there.  To make a technical point you would have to
>>> explain how, for example,
>>>
>>>     struct item *items;
>>>     ...
>>>     n_elements = get_number_of_items(...);
>>>     items = malloc(n_elements * sizeof *items);
>>>     ...
>>>
>>> is technically better than
>>>
>>>     n_elements = get_number_of_items(...);
>>>     struct item *items = malloc(n_elements * sizeof *items);
>>>
>>> I've explained (more than once) how I find reasoning about the direct
>>> initialise at first use style easier with fewer distractions.
>>>
>> items = malloc(n_elements * sizeof *items);
>>
>> is shorter than
>>
>> struct item *items = malloc(n_elements * sizeof *items);
>>
>> and that is an objective statement about which there can be no dispute.
>>
>
> But that is not the comparison.
>
>     struct item *items = malloc(n_elements * sizeof *items);
>
> is shorter than:
>
>     struct item *items;
>     items = malloc(n_elements * sizeof *items);
>
> You have to define the variable somewhere.  Doing so when you initialise
> it when you first need it, is, without doubt, objectively shorter.
> Opinions may differ on whether it is clearer, or "cluttered", but which
> is shorter is not in doubt.  (What relevance that might have, is much
> more in doubt.)
>

Sure. But it doesn't look like that. The first line is squirrelled away
at the top and you don't read it.
Of course you can say that you now don't now know that items is a
pointer to the right type of structure, and so the shortening makes it
harder rather than easier to understand. But the claim that the second
one is more "cluttered" is fair.

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

On 08/02/2024 12:24, David Brown wrote:
> On 08/02/2024 13:10, Malcolm McLean wrote:
>> On 08/02/2024 11:37, Ben Bacarisse wrote:
>>> bart <bc@freeuk.com> writes:
>>>
>>>> That sounds like your opinion against mine. It's nothing to do with
>>>> spin,
>>>> whatever that means.
>>>
>>> It's spin, because the term is emotive.  "Cluttering up" is how you feel
>>> about it.  The phrase is just a mildly pejorative one about appearances.
>>> There's no substance there.  To make a technical point you would have to
>>> explain how, for example,
>>>
>>>     struct item *items;
>>>     ...
>>>     n_elements = get_number_of_items(...);
>>>     items = malloc(n_elements * sizeof *items);
>>>     ...
>>>
>>> is technically better than
>>>
>>>     n_elements = get_number_of_items(...);
>>>     struct item *items = malloc(n_elements * sizeof *items);
>>>
>>> I've explained (more than once) how I find reasoning about the direct
>>> initialise at first use style easier with fewer distractions.
>>>
>> items = malloc(n_elements * sizeof *items);
>>
>> is shorter than
>>
>> struct item *items = malloc(n_elements * sizeof *items);
>>
>> and that is an objective statement about which there can be no dispute.
>>
>
> But that is not the comparison.
>
>     struct item *items = malloc(n_elements * sizeof *items);
>
> is shorter than:
>
>     struct item *items;
>     items = malloc(n_elements * sizeof *items);
>
> You have to define the variable somewhere.  Doing so when you initialise
> it when you first need it, is, without doubt, objectively shorter.
> Opinions may differ on whether it is clearer, or "cluttered", but which
> is shorter is not in doubt.  (What relevance that might have, is much
> more in doubt.)
>
>

If you want to isolate the executable code then you'd write it like this:

struct item *items;
...
items = malloc(n_elements * sizeof *items);

That code is now cleaner. It also doesn't have that somewhat confusing
(partly due to spacing) '... *items = malloc ...' which makes it look
like an indirect assignment to a pointer called 'item' (compounded by
that '*items' term as the sizeof operand).

It doesn't have the distracting juxtasposition in 'item * items'.

If there was a subsequence assignment to 'items':

items = malloc(n_elements * sizeof *items);
...
items = malloc(m_elements * sizeof *items);

the two look the same; you don't have one pushed over to the right. (I
was able to copy&paste with only a small tweak.)

If I decided I didn't need that first assignment, I don't now need to
transfer that declaration to the next use.

If the assinment is within a nested block, but I decide it needs to be
visible outside the block, I don't need to refactor; it is already visible.

If I decided to change the type of 'items', it's easier if it's at the
top; perhaps there are related variables whose types need changing.

This is especially the case if I have 'aitems' and 'bitems' of the same
type:

struct item *aitems, *bitems;

* I don't need a separate declaration for each

* I can instantly see they are the same type without needing to infer

* I can change the type of both in one place; they can't get out of step

Shall I go on?

Did you see my post where I established that C programs typically have
only 3 locals per function on average?

On 08/02/2024 03:07, Kaz Kylheku wrote:
> On 2024-02-08, bart <bc@freeuk.com> wrote:
>> On 08/02/2024 01:13, Kaz Kylheku wrote:
>>> On 2024-02-07, bart <bc@freeuk.com> wrote:
>>
>>>> This is to me is all a bit mixed up. Much as you dislike other languages
>>>> being brought in, they can give an enlightening perspective.
>>>
>>> Right, nobody here knows anything outside of C, or can think outside of
>>> the C box, except for you.
>>
>> Well, quite. AFAIK, nobody here HAS (1) used a comparable language to C;
>> (2) over such a long term; (3) which they have invented themselves; (4)
>> have implemented themselves; (5) is similar enough to C yet different
>> enough in how it works to give that perspective.
>
> You've taken a perspective is not transferrable to others.
>
> If one can only see something after using your own invention for many
> years, and other people don't have that same invention and
> implementation experience, then they just cannot see what you see.
>
> You cannot teach (2) through (4), just like a basketball coach cannot
> teach a player to be seven foot tall.
>
>> See, I gave an interesting comparison of how my module scheme works
>> orthogonally across all kinds of entities, compared with the confusing
>> mess of C, and you shut down that view.
>>
>> You're never in a million years going to admit that my language has some
>> good points are you? Exactly as I said in my OP.
>
> I have no idea what it is;

You can't understand the concept of having local/exported/imported
attributes apply to any kind of top-level identifier?

C is just an incredible mess when it comes to this. If you can at least
see how it ought to be done, it can be easier to see how to apply that to C.

For example (here I'm using English pseudo-code if you can't stomach my
using examples from a real, working, tested language):

Local int A static int A;

Import int B [extern] int B; // do not initialise

Export int C [extern] int C; // can initialise

Local typedef int D typedef int D;

Import typedef int E typedef int E; // in shared header, or duplicate

Export typedef int F typedef int F; // in shared header

Local #define G #define G

It's poor. 'extern' is generally optional. There is weak separation
between imported and exported names. It's often not clear which module,
if any, 'owns' a entity that uses resources such as code or data memory.

Often any entity that is imported or exported has two declarations: one
inside the module (if it's a defined function, or initialised variable),
and a declaration-only in a shared header.

A typedef like E may be shared across 3 modules (by arranging for them
all to see the same definition), but you can also have a different
typedef 'E' shared across 4 other modules.

If a module includes a header that defines typedef E, it can't shadow
that at file-scope with a different E, only inside a function (which
will allow one million different E's).

If a module wants to use headers from all those 7 headers mentioned,
than that E will clash.

C allows you to have multiple declarations of many of these entities
visible in the same module. You can mix up static and extern versions
provided they're in a certain order.

Did I say it was an incredible mess?

Anyway, very little of this is actually to do with 'linking'; that is
more to do with implementation.

See, you can take a idealised model of how this stuff ought to work, and
from that see how to emulate the needs in C. And also see where C has
weak points, of which there are many.

On 08/02/2024 14:17, bart wrote:
> On 08/02/2024 12:24, David Brown wrote:
>> On 08/02/2024 13:10, Malcolm McLean wrote:
>>> On 08/02/2024 11:37, Ben Bacarisse wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>
>>>>> That sounds like your opinion against mine. It's nothing to do with
>>>>> spin,
>>>>> whatever that means.
>>>>
>>>> It's spin, because the term is emotive.  "Cluttering up" is how you
>>>> feel
>>>> about it.  The phrase is just a mildly pejorative one about
>>>> appearances.
>>>> There's no substance there.  To make a technical point you would
>>>> have to
>>>> explain how, for example,
>>>>
>>>>     struct item *items;
>>>>     ...
>>>>     n_elements = get_number_of_items(...);
>>>>     items = malloc(n_elements * sizeof *items);
>>>>     ...
>>>>
>>>> is technically better than
>>>>
>>>>     n_elements = get_number_of_items(...);
>>>>     struct item *items = malloc(n_elements * sizeof *items);
>>>>
>>>> I've explained (more than once) how I find reasoning about the direct
>>>> initialise at first use style easier with fewer distractions.
>>>>
>>> items = malloc(n_elements * sizeof *items);
>>>
>>> is shorter than
>>>
>>> struct item *items = malloc(n_elements * sizeof *items);
>>>
>>> and that is an objective statement about which there can be no dispute.
>>>
>>
>> But that is not the comparison.
>>
>>      struct item *items = malloc(n_elements * sizeof *items);
>>
>> is shorter than:
>>
>>      struct item *items;
>>      items = malloc(n_elements * sizeof *items);
>>
>> You have to define the variable somewhere.  Doing so when you
>> initialise it when you first need it, is, without doubt, objectively
>> shorter. Opinions may differ on whether it is clearer, or "cluttered",
>> but which is shorter is not in doubt.  (What relevance that might
>> have, is much more in doubt.)
>>
>>
>
> If you want to isolate the executable code then you'd write it like this:
>
>      struct item *items;
>      ...
>      items = malloc(n_elements * sizeof *items);
>

Yes - /if/ you want to do this.

But I don't see a reason to make such a distinction - I see no benefit
in "isolating the executable code". Both lines are essential parts of
the program, they are used together, and IMHO they belong together.

I appreciate that you prefer to keep them separate. I believe the
arguments for keeping them separate are far weaker than the arguments
for declaring and defining variables only when you are ready to use
them, and within the smallest practical scope.

> That code is now cleaner.

That is an opinion, and no more than that.

> It also doesn't have that somewhat confusing
> (partly due to spacing) '... *items = malloc ...' which makes it look
> like an indirect assignment to a pointer called 'item' (compounded by
> that '*items' term as the sizeof operand).

I personally put spaces on either side of the "*", whether the
declaration is separate or not. But spacing habits are /definitely/ a
matter of personal preference. (And I'd also typedef the struct, which
is again a personal preference.)

>
> It doesn't have the distracting juxtasposition in 'item * items'.
>
> If there was a subsequence assignment to 'items':
>
>      items = malloc(n_elements * sizeof *items);
>      ...
>      items = malloc(m_elements * sizeof *items);
>
> the two look the same; you don't have one pushed over to the right. (I
> was able to copy&paste with only a small tweak.)

Agreed - but it is not something you actually have very often.

I can accept that there are occasions when the particular format of the
code or repetitive patterns would make the code clearer to have a single
declaration at the top and multiple assignments like this. But it is
not a common situation. I am quite happy for general rules to be
overridden on a case-by-case basis if it significantly improves clarity.

> This is especially the case if I have 'aitems' and 'bitems' of the same
> type:
>
>      struct item *aitems, *bitems;

A trick to writing clear and maintainable code is not to do that. It is
very rare IME that it is a good idea with multiple declarations on one
line, and it is never a good thing if there are pointers, arrays, or
other bits and pieces involved.

So if the only benefit from "only declare your variables when you have
an initial value" is that you never again write such multiple
declaration lines, then it would be a good thing.

>
> * I don't need a separate declaration for each

That doesn't matter when the declaration is part of the initialisation.

>
> * I can instantly see they are the same type without needing to infer
>

No, you can't. You have to look further up the function and find it in
the list of variables. With the declare and initialise pattern, the
type is right there in the relevant code - not elsewhere.

> * I can change the type of both in one place; they can't get out of step
>

And you have to re-arrange things if you want to change the type of just
one of them.

> Shall I go on?
>

No. We've heard all these arguments before. They are not new. I don't
think the points are worthless, I simply think they are not nearly
enough to sway the balance.

> Did you see my post where I established that C programs typically have
> only 3 locals per function on average?

I ignored that one. I can't reply to everything!

David Brown <david.brown@hesbynett.no> writes:
>On 08/02/2024 13:15, Malcolm McLean wrote:
>> On 08/02/2024 11:45, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> No. It means writing the code in a way which is common in C and has
>>>> certain
>>>> advantages, but is not so in other languages.
>>>
>>> Where do you get your superior knowledge of English from, and is there a
>>> way anyone else can hope to achieve your level of competence?
>>>
>> Degree in English literature.
>
>I would never have guessed that from the way you write and from how
>often you fail to read other people's posts.

And Malcolm doesn't apparently recognize sarcasm.

On 08/02/2024 16:09, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 08/02/2024 13:15, Malcolm McLean wrote:
>>> On 08/02/2024 11:45, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> No. It means writing the code in a way which is common in C and has
>>>>> certain
>>>>> advantages, but is not so in other languages.
>>>>
>>>> Where do you get your superior knowledge of English from, and is there a
>>>> way anyone else can hope to achieve your level of competence?
>>>>
>>> Degree in English literature.
>>
>> I would never have guessed that from the way you write and from how
>> often you fail to read other people's posts.
>
> And Malcolm doesn't apparently recognize sarcasm.

I think they only teach that at Cambridge.

scott@slp53.sl.home (Scott Lurndal) writes:

> David Brown <david.brown@hesbynett.no> writes:
>>On 08/02/2024 13:15, Malcolm McLean wrote:
>>> On 08/02/2024 11:45, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> No. It means writing the code in a way which is common in C and has
>>>>> certain
>>>>> advantages, but is not so in other languages.
>>>>
>>>> Where do you get your superior knowledge of English from, and is there a
>>>> way anyone else can hope to achieve your level of competence?
>>>>
>>> Degree in English literature.
>>
>>I would never have guessed that from the way you write and from how
>>often you fail to read other people's posts.
>
> And Malcolm doesn't apparently recognize sarcasm.

I think it's extremely unlikely that he missed it.

--
Ben.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On 08/02/2024 11:37, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> That sounds like your opinion against mine. It's nothing to do with spin,
>>> whatever that means.
>> It's spin, because the term is emotive. "Cluttering up" is how you feel
>> about it. The phrase is just a mildly pejorative one about appearances.
>> There's no substance there. To make a technical point you would have to
>> explain how, for example,
>> struct item *items;
>> ...
>> n_elements = get_number_of_items(...);
>> items = malloc(n_elements * sizeof *items);
>> ...
>> is technically better than
>> n_elements = get_number_of_items(...);
>> struct item *items = malloc(n_elements * sizeof *items);
>> I've explained (more than once) how I find reasoning about the direct
>> initialise at first use style easier with fewer distractions.
>>
> items = malloc(n_elements * sizeof *items);
>
> is shorter than
>
> struct item *items = malloc(n_elements * sizeof *items);
>
> and that is an objective statement about which there can be no
> dispute.

Yes, but is it relevant or even interesting?

--
Ben.

On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
> $ /mingw32/bin/as.exe --version
> GNU assembler (GNU Binutils) 2.40
> Copyright (C) 2023 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms
> of the GNU General Public License version 3 or later.
> This program has absolutely no warranty.
> This assembler was configured for a target of `i686-w64-mingw32'.
>
> $ size /mingw32/bin/as.exe
> text data bss dec hex filename
> 2941952 10392 43416 2995760 2db630
> C:/bin/msys64a/mingw32/bin/as.exe

LOL, even a 400 kilobyte assembler is bat shit crazy.

Can you imagine working with that on a 512 Kb IBM PC?

GNU as probably doesn't have half the features of, say, Randy Hyde's
LISA for APPLE II. (Lazer Systems Interactive Symbolic Assembler).

Might that be statically linking numerous libraries, like libbfd and
whatnot? Possibly it supports unnecessary object formats that the MinGW
user will never use.

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

On Thu, 8 Feb 2024 17:48:38 -0000 (UTC)
Kaz Kylheku <433-929-6894@kylheku.com> wrote:

> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
> > $ /mingw32/bin/as.exe --version
> > GNU assembler (GNU Binutils) 2.40
> > Copyright (C) 2023 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the
> > terms of the GNU General Public License version 3 or later.
> > This program has absolutely no warranty.
> > This assembler was configured for a target of `i686-w64-mingw32'.
> >
> > $ size /mingw32/bin/as.exe
> > text data bss dec hex filename
> > 2941952 10392 43416 2995760 2db630
> > C:/bin/msys64a/mingw32/bin/as.exe
>
> LOL, even a 400 kilobyte assembler is bat shit crazy.
>
> Can you imagine working with that on a 512 Kb IBM PC?
>
> GNU as probably doesn't have half the features of, say, Randy Hyde's
> LISA for APPLE II. (Lazer Systems Interactive Symbolic Assembler).
>
> Might that be statically linking numerous libraries, like libbfd and
> whatnot? Possibly it supports unnecessary object formats that the
> MinGW user will never use.
>

I am pretty sure that it is because of static libraries (which by
itself is a reasonable choice on platform like msys2) but don't want to
guess which library is in fault.

On 08/02/2024 17:48, Kaz Kylheku wrote:
> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
>> $ /mingw32/bin/as.exe --version
>> GNU assembler (GNU Binutils) 2.40
>> Copyright (C) 2023 Free Software Foundation, Inc.
>> This program is free software; you may redistribute it under the terms
>> of the GNU General Public License version 3 or later.
>> This program has absolutely no warranty.
>> This assembler was configured for a target of `i686-w64-mingw32'.
>>
>> $ size /mingw32/bin/as.exe
>> text data bss dec hex filename
>> 2941952 10392 43416 2995760 2db630
>> C:/bin/msys64a/mingw32/bin/as.exe
>
> LOL, even a 400 kilobyte assembler is bat shit crazy.

That's how I feel about a lot of programs.

You think it's crazy because you understand the task that is to be done
and know that 4MB or 40MB would be over the top.

The code part section of my own x64 assembler, if I strip out exraneous
things like the disassembler, is 70KB. That includes a .EXE target. If I
take that out (so only .OBJ target) then it's 61KB, of which 21KB is the
standard library of the language anyway.

So code just for the assembler is about 40KB, which is for a subset of x64.

> Can you imagine working with that on a 512 Kb IBM PC?

Can you imagine working with any of the compilers that are highly
regarded here on such a machine? And with floppy disks?

On 2/8/2024 9:48 AM, Kaz Kylheku wrote:
> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
[...]
> LOL, even a 400 kilobyte assembler is bat shit crazy.
>
> Can you imagine working with that on a 512 Kb IBM PC?

This assembler was pretty small... ;^D

https://youtu.be/bCSDkjhVM2A

>
> GNU as probably doesn't have half the features of, say, Randy Hyde's
> LISA for APPLE II. (Lazer Systems Interactive Symbolic Assembler).
>
> Might that be statically linking numerous libraries, like libbfd and
> whatnot? Possibly it supports unnecessary object formats that the MinGW
> user will never use.
>

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 2/8/2024 9:48 AM, Kaz Kylheku wrote:
>> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
> [...]
>> LOL, even a 400 kilobyte assembler is bat shit crazy.
>> Can you imagine working with that on a 512 Kb IBM PC?
>
> This assembler was pretty small... ;^D
>
> https://youtu.be/bCSDkjhVM2A

Please stop doing this.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

In article <87il2yfvmp.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 2/8/2024 9:48 AM, Kaz Kylheku wrote:
>>> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
>> [...]
>>> LOL, even a 400 kilobyte assembler is bat shit crazy.
>>> Can you imagine working with that on a 512 Kb IBM PC?
>>
>> This assembler was pretty small... ;^D
>>
>> https://youtu.be/bCSDkjhVM2A
>
>Please keep doing this.

"Introduction to Assembly Language Programming on the Apple IIgs - Lesson 1"

--
"He is exactly as they taught in KGB school: an egoist, a liar, but talented - he
knows the mind of the wrestling-loving, under-educated, authoritarian-admiring
white male populous."
- Malcolm Nance, p59. -

On 2/8/2024 2:29 PM, Kenny McCormack wrote:
> In article <87il2yfvmp.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 2/8/2024 9:48 AM, Kaz Kylheku wrote:
>>>> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
>>> [...]
>>>> LOL, even a 400 kilobyte assembler is bat shit crazy.
>>>> Can you imagine working with that on a 512 Kb IBM PC?
>>>
>>> This assembler was pretty small... ;^D
>>>
>>> https://youtu.be/bCSDkjhVM2A
>>
>> Please keep doing this.
>
> "Introduction to Assembly Language Programming on the Apple IIgs - Lesson 1"
>

Yup. I forgot to put in the title. Sorry everybody. ;^o

bart <bc@freeuk.com> writes:

> You're never in a million years going to admit that my language
> has some good points are you?

Where can I get a user manual for it?

On 09/02/2024 00:02, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
>
>> You're never in a million years going to admit that my language
>> has some good points are you?
>
> Where can I get a user manual for it?

Why? I haven't read a language manual since the 1980s.

I can still appreciate interesting ideas another language might have, or
even just ideas in isolation.

This is just churlishness.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> The most common meaning of "idiomatic", and the one I usually
> associate with it in [the context of some C coding conventions],
> is "containing expressions that are natural and correct". [...]

It surprised me to read this. In my lexicon "idiomatic" usually
means something more like "easily understood by a native speaker
but resistant to literal translation". An example might be
"raining cats and dogs".

Looking up "idiom" and "idiomatic" in several online dictionaries,
the meanings are definitely multi-valued. In C we might say that
Duff's Device is idiomatic. On the other hand we could say K&R
style function definitions are unusual in contemporary C idiom
(and so by implication ANSI/ISO C style function definitions are
idiomatic). So one meaning is more or less "normal practice"
whereas another meaning is more like "strange although often used
construction".

Please note that I am expressing no opinion on which meaning is
"better" or "worse", or anything along those lines. I just found
it interesting that these words have somewhat divergent meanings.

On 09/02/2024 01:48, bart wrote:
> On 09/02/2024 00:02, Tim Rentsch wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> You're never in a million years going to admit that my language
>>> has some good points are you?
>>
>> Where can I get a user manual for it?
>
> Why? I haven't read a language manual since the 1980s.
>

It's perhaps uncommon to read entire language manuals, but it is
extremely common to read parts, and use other parts for reference. I
have read large parts of the C standards from C99 to C23. More
relevantly here is the tools manuals - I have read much of the gcc
manual (and the manuals for ld, as, and make), and re-read parts that
change for new versions. For all the C compilers I have used in my
professional work, I have read at least the parts covering
compatibility, flags, options, C standard versions, and extensions.

I expect I read more manuals than most developers, but it would be
inconceivable for me to use a language tool seriously if it did not have
a manual that I could at least refer to as needed.

> I can still appreciate interesting ideas another language might have, or
> even just ideas in isolation.

Sure.

>
> This is just churlishness.
>

I can't speak for Tim's motives, but for my own part, the lack of good
documentation and specifications would rule out a language or compiler
for my use on anything beyond play and experimentation.

On 08/02/2024 13:55, Malcolm McLean wrote:
> On 08/02/2024 12:29, David Brown wrote:
>> On 08/02/2024 13:15, Malcolm McLean wrote:
>>> On 08/02/2024 11:45, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> No. It means writing the code in a way which is common in C and has
>>>>> certain
>>>>> advantages, but is not so in other languages.
>>>>
>>>> Where do you get your superior knowledge of English from, and is
>>>> there a
>>>> way anyone else can hope to achieve your level of competence?
>>>>
>>> Degree in English literature.
>>
>> I would never have guessed that from the way you write and from how
>> often you fail to read other people's posts.
>>
>
> What an Oxford English tutor mostly cares about is that the essay is
> produced. Not so much what it says. You'll always get some marks for
> writing something and will therefore pass, but you can get no marks for
> nothing and can only fail. So handing in a stupid essay is acceptable
> but not handing in the essay at all is a big no no and tutors really
> hate that. It's all about pulling something together in a tight deadline
> on a subject about which you knew absolutely nothing last week, and
> that's what they value. So it does encourage a rather slapdash approach
> and reading things quickly, and maybe that is a fault.
>

I guess there are good tutors and bad tutors, even at Oxford. What you
describe bears no relation to the experiences of friends at Oxford
university who studied English literature. My /maths/ tutor would have
failed someone who handed in work as carelessly and thoughtlessly
written as some of your posts, regardless of whether the mathematics
itself were correct.

Are you really suggesting your tutor merely counted the number of pages
you handed in, and didn't care if you had read the texts or not? He/she
didn't care if you talked about Shakespeare's plays, or if you called
them "actions" since that's what actors perform, and because you
consider the use of standard terms to be beneath you?

On 08/02/2024 23:43, Chris M. Thomasson wrote:
> On 2/8/2024 2:29 PM, Kenny McCormack wrote:
>> In article <87il2yfvmp.fsf@nosuchdomain.example.com>,
>> Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 2/8/2024 9:48 AM, Kaz Kylheku wrote:
>>>>> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
>>>> [...]
>>>>> LOL, even a 400 kilobyte assembler is bat shit crazy.
>>>>> Can you imagine working with that on a 512 Kb IBM PC?
>>>>
>>>> This assembler was pretty small... ;^D
>>>>
>>>> https://youtu.be/bCSDkjhVM2A
>>>
>>> Please keep doing this.
>>
>> "Introduction to Assembly Language Programming on the Apple IIgs -
>> Lesson 1"
>>
>
> Yup. I forgot to put in the title. Sorry everybody. ;^o

Be assured that almost no one will want to follow these links, even if
they know the title. And I think everyone here is capable of using
google, and of using Youtube's search. If someone reads a post here
mentioning assembly and thinks they'd like to spend a half hour watching
a history video on assembly programming on old computers, then they will
manage that fine.

Please do not post these links - with or without titles - unless they
are extremely relevant and somehow outstanding videos that add so much
to the thread that they are worth watching. And even then, accompany
the link with information, a summary and justification for the link.

I appreciate your many positive contributions to discussions in c.l.c.
and c.l.c++, and your knowledge and opinions on threading and
synchronisation. But I doubt if anyone is interested in yet another
"This made me think of <https://youtu.be..." post. (And while we are at
it, please stop the pissing contests with Bonita on c.l.c++. Take your
pantomime fights to email, or drop them altogether.)

Thanks.

(Cue stupid comment from Kenny as a follow-up.)

On Thu, 8 Feb 2024 08:52:12 +0100
David Brown <david.brown@hesbynett.no> wrote:
>
> You are just a rounding error :-)
>
> But it is interesting to hear of exceptions to the general trend.
>

That is one option.
Another one is you pulling your statistics out of one of your major
anatomical features.

On 09/02/2024 14:55, Michael S wrote:
> On Thu, 8 Feb 2024 08:52:12 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>>
>> You are just a rounding error :-)
>>
>> But it is interesting to hear of exceptions to the general trend.
>>
>
> That is one option.
> Another one is you pulling your statistics out of one of your major
> anatomical features.
>

You do know that embedded Windows - "WinCE" - had its last version
release in 2013, and ended extended support last year? It's share of
the market (whatever market you choose) was never particularly
significant despite significant effort from MS, which is why they
dropped it.

Clearly my comment about "two or three unfortunate people" was not meant
as a serious statistic.

And of course people also make systems that can be classified as
"embedded", but with a desktop (or even server) version of Windows.