On Mon, 8 Apr 2024 14:35:48 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
>> On Sun, 07 Apr 2024 06:04:16 -0400
>> Alan Bawden <alan@csail.mit.edu> wrote:
>>> If acknowledging the existence of female developers makes you
>>> uncomfortable, you're just going to have to learn to deal with that
>>> yourself. I'm not going to adjust my language to cater to your
>>> insecurities.
>>
>> If my insecurities you mean acknowledging reality then fine. The thing about
>> people like you is (and I don't believe the 50% thing, sorry) is that you
>> would never use a male pronoun if talking about nurses or pre school teachers
>
>> who are heavily biased towards women.
>>
>
>What makes you so sure about that? Are you assuming that because /you/
>are sexist, everyone else is?

An immediate fallacious ad hominem no doubt in order to prop up whatever
straw men follow.

tl;dr, bugger off.

On Sun, 07 Apr 2024 00:01:43 +0000
Javier <invalid@invalid.invalid> wrote:

> It certainly encourages the writing of small modular tools. The
> downside is the loss of performance because of disk access for trivial
> things like 'nfiles=$(ls | wc -l)'. I suspect disk access times where
> one of the reasons for the development of perl in the early 90s.

You really want either built-ins for a lot of basic commands, or a good
scheme for caching commonly-used executables. AmigaDOS (a TriPOS
derivative) made it pretty trivial to set up a RAM disk and add that to
the search path, which made a big difference in performance since
almost nothing was built-in. Wouldn't be hard to do in *nix-land,
either, but it's an open question whether you'd gain anything over
modern generalized disk caching.

On Sat, 6 Apr 2024 00:25:45 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> It’s like, I don’t know ... you’re trying to save space. Why?
>
> It’s like programming inside an apartment block, instead of having a
> bungalow with a yard of your own.

It's a matter of balance. Needlessly crunching things to fit onto a
single line is hard to read, yes - but compulsively indenting and
splitting across lines can get out of hand, too. It seems to me that a
lot of people in this age of "cinematic" aspect ratios and super-sized
displays in personal computing forget that eye-travel isn't free, and
spreading information across maximal space can make it *harder* to keep
track of context.

Better, IMHO, to group operations in a way that logically reflects the
structure of the program, to whatever extent that *A.* is syntactically
feasible in $LANGUAGE, and *B.* doesn't crowd things to the point of
hampering basic readability.

(Of course, whether or not the ternary operator is fundamentally
confusing is an entirely separate question.)

In article <uv0v7l$3i0l6$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
....
>An immediate fallacious ad hominem no doubt in order to prop up whatever
>straw men follow.

When you find yourself in a hole, the first thing to do is to stop digging.

--
Genesis 2:7 And the LORD God formed man of the dust of the ground, and
breathed into his nostrils the breath of life; and man became a living soul.

On Mon, 8 Apr 2024 15:20:57 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>In article <uv0v7l$3i0l6$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>....
>>An immediate fallacious ad hominem no doubt in order to prop up whatever
>>straw men follow.
>
>When you find yourself in a hole, the first thing to do is to stop digging.

Thats fine, I'll keep watching you lot dig your holes while I stand at the
side.

In comp.unix.shell John Ames <commodorejohn@gmail.com> wrote:
> On Sun, 07 Apr 2024 00:01:43 +0000
> Javier <invalid@invalid.invalid> wrote:
>
>> the loss of performance because of disk access for trivial
>> things like 'nfiles=$(ls | wc -l)'. I suspect disk access times where
>> one of the reasons for the development of perl in the early 90s.
>
> You really want either built-ins for a lot of basic commands, or a good
> scheme for caching commonly-used executables. AmigaDOS (a TriPOS
> derivative) made it pretty trivial to set up a RAM disk and add that to
> the search path, which made a big difference in performance since
> almost nothing was built-in. Wouldn't be hard to do in *nix-land,
> either, but it's an open question whether you'd gain anything over
> modern generalized disk caching.

I don't worry about that anymore. My bash scripts run blazing fast
in my laptop with an SSD. I guess it was an issue at the time Perl
appeared (1987), although TBH I didn't experience it myself, since at
that time I wasn't a Unix user.

Also, I suspect HD caching and the increase in HD speed was one of the
reasons for the fall in popularity of Perl for writing small system
automation tasks that could be done with just shell. But there were
another reasons, like the disapearance of diversity in the Unix OS ecosystem.
Perl made easy to write portable scripts that could run on propietary Unixen
that came with slight incompatibilities in the command line tools
(IRIX/Solaris/HP-UX/AIX, etc.)

Perhaps somebody here who uses (or used to use) Perl for system
automation tasks can tell us more about their personal reasons
for prefering (or used to prefer) Perl over shell.

On 2024-04-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Mon, 8 Apr 2024 14:35:48 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>>On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
>>> On Sun, 07 Apr 2024 06:04:16 -0400
>>> Alan Bawden <alan@csail.mit.edu> wrote:
>>>> If acknowledging the existence of female developers makes you
>>>> uncomfortable, you're just going to have to learn to deal with that
>>>> yourself. I'm not going to adjust my language to cater to your
>>>> insecurities.
>>>
>>> If my insecurities you mean acknowledging reality then fine. The thing about
>>> people like you is (and I don't believe the 50% thing, sorry) is that you
>>> would never use a male pronoun if talking about nurses or pre school teachers
>>
>>> who are heavily biased towards women.
>>>
>>
>>What makes you so sure about that? Are you assuming that because /you/
>>are sexist, everyone else is?
>
> An immediate fallacious ad hominem no doubt in order to prop up whatever
> straw men follow.

You wrote, "people like you ... would never use a male pronoun if
talking about nurses", written by you, is already ad hominem;
it's a direct accusation of hypocrisy, rather than focusing on the
argument content.

If you can't handle the ad-hominem ball returned to your court,
don't serve it!

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

In article <20240408122937.339@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
....
>You wrote, "people like you ... would never use a male pronoun if
>talking about nurses", written by you, is already ad hominem;
>it's a direct accusation of hypocrisy, rather than focusing on the
>argument content.
>
>If you can't handle the ad-hominem ball returned to your court,
>don't serve it!

We'd all be better off if nobody ever used the phrase 'ad hominem' ever
again on Usenet.

This also goes for the rest of those fancy Latin phrases that people use to
argue about arguing.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/CLCtopics

On Mon, 8 Apr 2024 08:20:37 -0700, John Ames wrote:

> ... compulsively indenting and
> splitting across lines can get out of hand, too. It seems to me that a
> lot of people in this age of "cinematic" aspect ratios and super-sized
> displays in personal computing forget that eye-travel isn't free, and
> spreading information across maximal space can make it *harder* to keep
> track of context.

There it is again: “maximal space”. The “space” is there to be used.
Code may be one-dimensional, but you have a two-dimensional screen to
display it, why not make use of that, if it makes a complex structure
clearer?

Another example:

def fill_in_depreciations(tax_year) :
"(re)inserts depreciation entries for the specified tax year," \
" based on currently-entered assets."
sql.cursor.execute \
(
"delete from payments where kind = %s and tax_year = %s",
["D", tax_year]
)
for \
entry \
in \
get_each_record \
(
table_name = "assets, asset_depreciations",
fields =
[
"assets.description as description",
"assets.initial_value as initial_value",
"assets.when_purchased as when_purchased",
"assets.depreciation_rate as rate",
"assets.depreciation_method as method",
"asset_depreciations.depreciation_amount as amount",
],
condition =
"assets.asset_id = asset_depreciations.asset_id and"
" asset_depreciations.tax_year = %s",
values = [tax_year]
) \
:
sql.cursor.execute \
(
"insert into payments set when_made = %(when_made)s,"
" description = %(description)s, other_party_name = \"\","
" amount = %(amount)d, kind = \"D\", tax_year = %(tax_year)d"
%
{
"when_made" : end_for_tax_year(tax_year) - 1,
"description" :
sql_string
(
"%s: %s $%s at %d%% from %s"
%
(
entry["description"],
entry["method"],
format_amount(entry["initial_value"]),
entry["rate"],
format_date(entry["when_purchased"]),
)
),
"amount" : - entry["amount"],
"tax_year" : tax_year,
}
)
#end for
#end fill_in_depreciations

On Mon, 8 Apr 2024 07:44:27 -0000 (UTC), Muttley wrote:

> Hmm, wonder why hardly anyone outside academia used the language even back in
> the day, never mind now....

*cough* AutoCAD *cough*

(Even if they did end up doing it wrong.)

On Mon, 08 Apr 2024 17:54:42 +0000, Javier wrote:

> Also, I suspect HD caching and the increase in HD speed was one of the
> reasons for the fall in popularity of Perl for writing small system
> automation tasks that could be done with just shell. But there were
> another reasons, like the disapearance of diversity in the Unix OS
> ecosystem.

Systems that can legally be called “Unix®” may be essentially extinct, but
Linux on its own offers more diversity than they could manage, anyway.

And yes, Perl may not be the Hot New Thing™, but it still lives on.

On my Debian system:

ldo@theon:~> apt-cache rdepends perl | sort | uniq | wc -l
1115

> Perl made easy to write portable scripts that could run on propietary
> Unixen that came with slight incompatibilities in the command line tools
> (IRIX/Solaris/HP-UX/AIX, etc.)

I thought the usual way any self-respecting Unix sysadmin fixed that
problem was by installing the GNU tools.

On Mon, 8 Apr 2024 22:14:16 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> There it is again: “maximal space”. The “space” is there to be used.
> Code may be one-dimensional, but you have a two-dimensional screen to
> display it, why not make use of that, if it makes a complex structure
> clearer?

Like I said: eye-travel. If the same amount of information is spread
out over a larger space, there comes a point where it's actually *more*
work to read, and it eventually becomes harder for the brain to keep
track of the relevant context as a result; the "flow" is broken.

Of course, it's entirely possible (and arguably more common) to err in
the other direction, and the best thing is to find a good balance - but
I maintain that a because-it's-there approach to screen space has its
own pitfalls as well.

> for \
> entry \
> in \
> get_each_record \

This, for example. Most of your example is quite reasonable, but what
Earthly purpose is served by breaking up a straightforward construct:

for entry in get_each_record

into semantic atoms, let alone staggering them all across the page?
Splitting components into logical groupings is one thing, but the parts
here *belong* together; why separate them!?

(Obviously, there's an element of "de gustibus non est disputandum"
here, but I am legitimately both baffled by and curious about your line
of thinking.)

On 2024-04-08, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> There it is again: “maximal space”. The “space” is there to be used.
> Code may be one-dimensional, but you have a two-dimensional screen to
> display it, why not make use of that, if it makes a complex structure
> clearer?

A canvas is two dimensional. That doesn't mean that a chimpanzee with
a brush is Rembrandt.

>
> Another example:
>
> def fill_in_depreciations(tax_year) :
> "(re)inserts depreciation entries for the specified tax year," \
> " based on currently-entered assets."
> sql.cursor.execute \
> (
> "delete from payments where kind = %s and tax_year = %s",
> ["D", tax_year]
> )
> for \
> entry \
> in \
> get_each_record \

This ain't Rembrandt.

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

On 08.04.2024 21:44, Kenny McCormack wrote:
> In article <20240408122937.339@kylheku.com>,
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> ...
>> You wrote, "people like you ... would never use a male pronoun if
>> talking about nurses", written by you, is already ad hominem;
>> it's a direct accusation of hypocrisy, rather than focusing on the
>> argument content.
>>
>> If you can't handle the ad-hominem ball returned to your court,
>> don't serve it!
>
> We'd all be better off if nobody ever used the phrase 'ad hominem' ever
> again on Usenet.
>
> This also goes for the rest of those fancy Latin phrases that people use to
> argue about arguing.

Id est, exempli gratia, focussing on the argument per se, as
Kaz sensibly suggested. :-)

(It's good that in English most of the Latin is hidden behind
abbreviations like i.e. and e.g.; but there's no abbreviation
for "per se"? Probably because p.s. is already occupied?)

Janis

PS: Of course I disagree for the "banning phrases" suggestion.
Pointing out (in whatever way) to stay on the argument is fine.

On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>On 2024-04-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> On Mon, 8 Apr 2024 14:35:48 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>>On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
>>>What makes you so sure about that? Are you assuming that because /you/
>>>are sexist, everyone else is?
>>
>> An immediate fallacious ad hominem no doubt in order to prop up whatever
>> straw men follow.
>
>You wrote, "people like you ... would never use a male pronoun if
>talking about nurses", written by you, is already ad hominem;
>it's a direct accusation of hypocrisy, rather than focusing on the
>argument content.

Mine was correct in general, yours shows you don't understand the difference
between sexism and realism. But then the woke mindset is simply a secular
religion so logic doesn't apply.

>If you can't handle the ad-hominem ball returned to your court,
>don't serve it!

In tennis spectators don't generally jump onto the court and return the ball.

John Ames <commodorejohn@gmail.com> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> There it is again: “maximal space”. The “space” is there to be used.
>> Code may be one-dimensional, but you have a two-dimensional screen to
>> display it, why not make use of that, if it makes a complex structure
>> clearer?
>
> Like I said: eye-travel. If the same amount of information is spread
> out over a larger space, there comes a point where it's actually *more*
> work to read, and it eventually becomes harder for the brain to keep
> track of the relevant context as a result; the "flow" is broken.

Also, the more it’s spread out, the less of it you can get on one
screen, and the resulting need for paging makes the medium-scale
structure a lot less clear.

--
https://www.greenend.org.uk/rjk/

On 2024-04-09, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>On 2024-04-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> On Mon, 8 Apr 2024 14:35:48 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
>>>>What makes you so sure about that? Are you assuming that because /you/
>>>>are sexist, everyone else is?
>>>
>>> An immediate fallacious ad hominem no doubt in order to prop up whatever
>>> straw men follow.
>>
>>You wrote, "people like you ... would never use a male pronoun if
>>talking about nurses", written by you, is already ad hominem;
>>it's a direct accusation of hypocrisy, rather than focusing on the
>>argument content.
>
> Mine was correct in general, yours shows you don't understand the difference
> between sexism and realism.

I've not addressed myself to that topic whatsoever, let alone revealed
a position.

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

On 09.04.2024 09:45, Muttley@dastardlyhq.com wrote:
> On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>
>> If you can't handle the ad-hominem ball returned to your court,
>> don't serve it!
>
> In tennis spectators don't generally jump onto the court and return the ball.

If players missed the goal and hit the net there's ball kids that
jump onto the court to fetch the misguided balls.

Janis

On 09.04.2024 09:47, Richard Kettlewell wrote:
> John Ames <commodorejohn@gmail.com> writes:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> There it is again: “maximal space”. The “space” is there to be used.
>>> Code may be one-dimensional, but you have a two-dimensional screen to
>>> display it, why not make use of that, if it makes a complex structure
>>> clearer?
>>
>> Like I said: eye-travel. If the same amount of information is spread
>> out over a larger space, there comes a point where it's actually *more*
>> work to read, and it eventually becomes harder for the brain to keep
>> track of the relevant context as a result; the "flow" is broken.
>
> Also, the more it’s spread out, the less of it you can get on one
> screen, and the resulting need for paging makes the medium-scale
> structure a lot less clear.

Add structuring code (e.g. using functions) to manage complexity
and make it possible to keep entities in appropriate sizes.

Janis

On 09/04/2024 09:47, Richard Kettlewell wrote:
> John Ames <commodorejohn@gmail.com> writes:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> There it is again: “maximal space”. The “space” is there to be used.
>>> Code may be one-dimensional, but you have a two-dimensional screen to
>>> display it, why not make use of that, if it makes a complex structure
>>> clearer?
>>
>> Like I said: eye-travel. If the same amount of information is spread
>> out over a larger space, there comes a point where it's actually *more*
>> work to read, and it eventually becomes harder for the brain to keep
>> track of the relevant context as a result; the "flow" is broken.
>
> Also, the more it’s spread out, the less of it you can get on one
> screen, and the resulting need for paging makes the medium-scale
> structure a lot less clear.
>

And if you need line continuation characters - ending the line in "\" in
this case - it's a sure sign that you are doing something questionable.
In some cases it is unavoidable, such as for complex macros in C or for
long lists in bash, but it is extremely rare that it is necessary in
Python code.

Comments to say when your loop or functions end is another big red flag
that the layout is bad.

On Tue, 9 Apr 2024 10:11:09 +0200, David Brown wrote:

> Comments to say when your loop or functions end is another big red flag
> that the layout is bad.

Without #end comments: how easy is it to tell which lines belong to
the inner function, and which to the outer?

def set_message(self, message) :

w_self = weak_ref(self)

def wrap_message(c_conn, c_message, c_user_data) :
self = _wderef(w_self, "vtable")
conn = Connection(dbus.dbus_connection_ref(c_conn))
msg = Message(dbus.dbus_message_ref(c_message))
user_data = conn._user_data.get(c_user_data)
result = message(conn, msg, user_data)
if asyncio.iscoroutine(result) :
self.create_task(result)
result = DBUS.HANDLER_RESULT_HANDLED
return \
result

if message != None :
self._wrap_message_func = DBUS.ObjectPathMessageFunction(wrap_message)
else :
self._wrap_message_func = None
self._dbobj.message_function = self._wrap_message_func
return \
self

Now, with #end comments (and a #begin as well, for good measure):

def set_message(self, message) :

w_self = weak_ref(self)

def wrap_message(c_conn, c_message, c_user_data) :
self = _wderef(w_self, "vtable")
conn = Connection(dbus.dbus_connection_ref(c_conn))
msg = Message(dbus.dbus_message_ref(c_message))
user_data = conn._user_data.get(c_user_data)
result = message(conn, msg, user_data)
if asyncio.iscoroutine(result) :
self.create_task(result)
result = DBUS.HANDLER_RESULT_HANDLED
#end if
return \
result
#end wrap_message

#begin set_message
if message != None :
self._wrap_message_func = DBUS.ObjectPathMessageFunction(wrap_message)
else :
self._wrap_message_func = None
#end if
self._dbobj.message_function = self._wrap_message_func
return \
self
#end set_message

On Tue, 9 Apr 2024, Janis Papanagnou wrote:

> On 08.04.2024 21:44, Kenny McCormack wrote:
>> In article <20240408122937.339@kylheku.com>,
>> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>> ...
>>> You wrote, "people like you ... would never use a male pronoun if
>>> talking about nurses", written by you, is already ad hominem;
>>> it's a direct accusation of hypocrisy, rather than focusing on the
>>> argument content.
>>>
>>> If you can't handle the ad-hominem ball returned to your court,
>>> don't serve it!
>>
>> We'd all be better off if nobody ever used the phrase 'ad hominem' ever
>> again on Usenet.
>>
>> This also goes for the rest of those fancy Latin phrases that people use to
>> argue about arguing.
>
> Id est, exempli gratia, focussing on the argument per se, as
> Kaz sensibly suggested. :-)
>
> (It's good that in English most of the Latin is hidden behind
> abbreviations like i.e. and e.g.; but there's no abbreviation
> for "per se"? Probably because p.s. is already occupied?)
>
> Janis
>
> PS: Of course I disagree for the "banning phrases" suggestion.
> Pointing out (in whatever way) to stay on the argument is fine.

In todays day and world, it is not very difficult to look up phrases such
as ad hominem. I do it from time to time. I learn something by doing that,
and should thank the other person for bringing it to my attention.

Then, the next time I encounter it, I do not have to look it up again.

On 09/04/2024 10:38, Lawrence D'Oliveiro wrote:
> On Tue, 9 Apr 2024 10:11:09 +0200, David Brown wrote:
>
>> Comments to say when your loop or functions end is another big red flag
>> that the layout is bad.
>
> Without #end comments: how easy is it to tell which lines belong to
> the inner function, and which to the outer?
>

You could try doing what almost every other Python programmer does - use
smaller functions and drop the silly line continuations.

When you see that you have a style that is very different from all the
others you see around you, you have to consider what is more likely -
are you a lone genius that sees what no one else does, or are you doing
something weird and unhelpful?

Now, I know there are plenty of people who think Python's method of
determining blocks is not ideal. But look up some statistics comparing
Pascal and Python usage, and it should be quite clear that begin/end is
not something many people find necessary.

Muttley@dastardlyhq.com writes:
>On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
>Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>On 2024-04-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> On Mon, 8 Apr 2024 14:35:48 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
>>>>What makes you so sure about that? Are you assuming that because /you/
>>>>are sexist, everyone else is?
>>>
>>> An immediate fallacious ad hominem no doubt in order to prop up whatever
>>> straw men follow.
>>
>>You wrote, "people like you ... would never use a male pronoun if
>>talking about nurses", written by you, is already ad hominem;
>>it's a direct accusation of hypocrisy, rather than focusing on the
>>argument content.
>
>Mine was correct in general

Only in your worldview.

FWIW, at the local A&E, the split is about 50-50.

On Tue, 09 Apr 2024 15:01:46 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
>>Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>>On 2024-04-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>>> On Mon, 8 Apr 2024 14:35:48 +0200
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
>>>>>What makes you so sure about that? Are you assuming that because /you/
>>>>>are sexist, everyone else is?
>>>>
>>>> An immediate fallacious ad hominem no doubt in order to prop up whatever
>>>> straw men follow.
>>>
>>>You wrote, "people like you ... would never use a male pronoun if
>>>talking about nurses", written by you, is already ad hominem;
>>>it's a direct accusation of hypocrisy, rather than focusing on the
>>>argument content.
>>
>>Mine was correct in general
>
> Only in your worldview.
>
> FWIW, at the local A&E, the split is about 50-50.

What local A&E? Here in the UK the vast majority of nurses are female whereas
with doctors its a more even mix.