Re: Seeking computer-programming job (Sunnyvale, CA)

[Series Expansion]

Hereunto.

Incoherent.

 

[Series Expansion]

Yes.

It is gratifying that that point has now been settled.

It adds expressivity and easiness of extensibility to the language.
Not magical, but useful nevertheless.

Useful, perhaps, but, as I stated, not magical.

Choose your terminology as you wish.  Lisp and Scheme (and Dylan and
few other ones) have macro systems better integrated in the language
than any other one.  This integration does give you more power.

Yet it does not grant some of the magical capabilities that have been
attributed to it previously in this thread.

But that is not the point.

But that is exactly the point. Source code is source code. Where it
physically resides is irrelevant, except to the matter of its
preservation across sessions, for which reason unpreprocessed source
code should exist on disk.

However, its preservation across sessions was not the original issue
here, until you brought it up apparently as a diversionary tactic.

Fine.  We are all grown up and can tell the difference.

If this is meant to imply a personal attack, I should alert you to the
fact that such attacks do not constitute logical arguments in favor of
either Lisp or Java. However, the tendency of Lispers to frequently
make such remarks might itself be regarded as circumstantial evidence
favoring Java; Lisp may be tarnished in the estimation of some readers
by the company it keeps.

I said no.  You should explain why I am wrong.

You are contradicting this earlier claim, posted by your own side:

If you and Alessio disagree as to which macros operate upon, source
code or object code, then perhaps you should work that out between the
two of you before either of you continues to press your attack upon
Java. Otherwise, we on the Java side can logically be expected to
seize upon such internal inconsistencies in your position and exploit
them to destroy your side's credibility, thus inexorably swaying the
audience in favor of Java. You are therefore in danger of losing the
debate. United you may prevail; divided you court defeat.

Then why don't you read exclusively the files produced by gcc -E?
They are as "raw source code" as they get.

That is an issue of readability.

 Or maybe we should just program everything in raw assembly.

That is an apples-to-oranges comparison; the translation from C to
assembly is a matter of compilation, not just preprocessing the
compiler's input.

 Macros give you expressive power.

That is not in dispute, but it is also irrelevant to the current point
of contention.

Noted.



You just griped about macros generating "source code" at the end.

You seem to be confused.

Yes.  But the point is that macros - especially when well integrated
in a programming language - improve the overall language usability.

What they are not, in the vernacular, is a "silver bullet", contrary
to claims fronted here earlier.

And while we are on the subject of Java's superiority to Lisp, when I
did a bit of digging I turned up an arguably even larger skeleton in
Common Lisp's closet: catch and throw. While these may share the names
of well-behaved constructs in the Java programming language, a cursory
examination of their definition clearly establishes that they are
anything but. Indeed, it seems they can be used to implement the worst
spaghettifying feature ever to disgrace the BASIC programming
language: a computed "goto".

I rest my case, though I will continue to provide rebuttal evidence
and testimony at need.

 

[Series Expansion]

It doesn't get "flattened again into source code prior to
compilation"

That would be incorrect behavior, if so. The compiler, after all, by
definition of "compiler" deals in source code, so if your statement
were correct, the output of a macro would not be in a form amenable to
being compiled.

the "macro processor"(that is, Lisp)'s "internal
representation of the code" /is/ the source code.

This statement is incoherent. The source code, by definition, is the
contents of the source files fed to the compiler, in the case of
Common Lisp e.g. by executing compile-file on them from a REPL.

 The compiler operates on that very same "internal representation" (i.e., the
source code).

This, too, is incoherent, for largely the same reasons. Source code
and compiler internal representations differ by definition, unless the
internal representation at issue is something trivial, such as an
ASCII buffer read from a source file.

ROTFL

I do not find your incoherent arguments, random personal attacks, and
other behaviors amusing. Rather, they concern me, as they may be early
signs of any of a number of serious degenerative neurological
conditions, for which you appear to be making no effort to seek
treatment.

I have deleted your misquotation of the remainder of my post. Suffice
it to say, you are doing a poor job of proving Lisp superior to Java.
And to add to your troubles, now the Lisp version of "computed goto"
has come to light. You have, as my colleagues would put it, "your work
cut out for you".

 

[thomas.mertes]

FYI: Vista 64 with seed7, VS2008, HP Z800 Workstation 6GB RAM

D:\p\seed7\prg>d:\cygwin\bin\time -p ..\src\hi chk_all.sd7

HI INTERPRETER Version 4.5.4853  Copyright (c) 1990-2009 Thomas Mertes
    262 D:/p/seed7/lib/syntax.s7i
   3518 D:/p/seed7/lib/seed7_05.s7i
     70 D:/p/seed7/lib/shell.s7i
    227 chk_all.sd7
   4077 lines total
271800 lines per second
1755374 bytes
compiling the compiler - okay
chkint - okay
chkstr - okay
chkprc - okay
chkbig - okay
chkbool - okay
chkset - okay
chkexc - okay

real 17.59
user 0.00
sys 0.10

Great. Good to know that Seed7 works also under Vista.
Which compiler and which makefile did you use?

Have you tried some of the example programs?

When you write a Seed7 program just ask me for support.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[anonymous.c.lisper]

That would be incorrect behavior, if so. The compiler, after all, by
definition of "compiler" deals in source code, so if your statement
were correct, the output of a macro would not be in a form amenable to
being compiled.

Most compilers tokenize the source file prior to compilation.
You can think of macros as manipulating the tokens.
(It just happens that lisp is very amenable to this sort of thing).

This statement is incoherent. The source code, by definition, is the
contents of the source files fed to the compiler, in the case of
Common Lisp e.g. by executing compile-file on them from a REPL.
Right.


This, too, is incoherent, for largely the same reasons. Source code
and compiler internal representations differ by definition, unless the
internal representation at issue is something trivial, such as an
ASCII buffer read from a source file.

Right, but the internal representations are isomorphic to the source
file, so with lisp the line is 'blurry'.

(Java is to JVM as lisp is to lisp.)

(Although lisp then goes through another pass to a lower level
'virtual machine' (i.e. assembler, JVM, gcc in some cases))

 

[java.oke]

Incoherent.

Last One Wins!

Your answer:

 

[Marco Antoniotti]

First of all apologies for the cross posting. Follow ups to
comp.lang.lisp

It is gratifying that that point has now been settled.



Useful, perhaps, but, as I stated, not magical.

Never said magical. Powerful yes.

Yet it does not grant some of the magical capabilities that have been
attributed to it previously in this thread.

I don't know anything about magic. I know about Java (at least as
much as you) and Common Lisp.

But that is exactly the point. Source code is source code. Where it
physically resides is irrelevant, except to the matter of its
preservation across sessions, for which reason unpreprocessed source
code should exist on disk.

However, its preservation across sessions was not the original issue
here, until you brought it up apparently as a diversionary tactic.

I was under the impression that you did not understand how Lisp macros
work. I am still under that impression. I tried to help.

If this is meant to imply a personal attack, I should alert you to the
fact that such attacks do not constitute logical arguments in favor of
either Lisp or Java. However, the tendency of Lispers to frequently
make such remarks might itself be regarded as circumstantial evidence
favoring Java; Lisp may be tarnished in the estimation of some readers
by the company it keeps.

I restate... we should all (meaning: all) be able to tell the
difference.

You are contradicting this earlier claim, posted by your own side:


If you and Alessio disagree as to which macros operate upon, source
code or object code, then perhaps you should work that out between the
two of you before either of you continues to press your attack upon
Java. Otherwise, we on the Java side can logically be expected to
seize upon such internal inconsistencies in your position and exploit
them to destroy your side's credibility, thus inexorably swaying the
audience in favor of Java. You are therefore in danger of losing the
debate. United you may prevail; divided you court defeat.

Lisp macros, and Alessio, who is sitting right now in the same room,
agrees with me and with many people who actually know Java, operate on
the equivalent of the AST of the program. In Java you do not have
anything similar.

That is an issue of readability.

Yes. And that is the reason why Lisp macros give you power you do not
have in Java.

That is an apples-to-oranges comparison; the translation from C to
assembly is a matter of compilation, not just preprocessing the
compiler's input.

Yes. And Lisp macros are on par. They can do (almost) arbitrary
source-to-source transformations. As such they are more powerful than
the C preprocessor and derivatives and something that simply is not
there in Java.

That is not in dispute, but it is also irrelevant to the current point
of contention.



You seem to be confused.

Of course I am. I have few ideas but confused.

What they are not, in the vernacular, is a "silver bullet", contrary
to claims fronted here earlier.

They are a "very good thing"TM which give the programmer power.
Again, in Java there is nothing similar.

And while we are on the subject of Java's superiority to Lisp, when I
did a bit of digging I turned up an arguably even larger skeleton in
Common Lisp's closet: catch and throw. While these may share the names
of well-behaved constructs in the Java programming language, a cursory
examination of their definition clearly establishes that they are
anything but. Indeed, it seems they can be used to implement the worst
spaghettifying feature ever to disgrace the BASIC programming
language: a computed "goto".

If you took the time to get your level of knowledge of Common Lisp
near the level of competence I or Alessio or many other people here
(in comp.lang.lisp) have with Java, you would have dug out prog,
tagbody and go, not to speak of other cockraches in CL (every
cockroach is beautiful to his mother). What you completely missed are
handler-bind, handler-case, restart-bind etc etc and in general the
whole exception handling machinery which inspired C++ and - you
guessed it - Java. You also missed with-open-file, which (1) is a
macro and (2) it clearly states the intent of the programmer, and (3)
it is far better than theBufferedReader x ... try { x = new
BufferedReader(...); } finally { ... x.close(); ... } idiom.

I rest my case, though I will continue to provide rebuttal evidence
and testimony at need.

Suit yourself. We'll be waiting for you to get up to speed on CL.
Remember - and I am not apologizing for sounding patronizing; I am
patronizing - I know at least as much Java as you do and I know that
many lispers are in the same situation. The opposite, with you and CL
does not seem to be true.

Cheers

 

[Seamus MacRae]

Oh look, the troll

Personal attack. Not a rational argument in favor of either language.

is now permuting his From: header

I changed it once.

to evade killfiles.

Nope. I had another reason.

 

[Seamus MacRae]

To whom are you writing? *I* know what it is because *I* wrote it all by
myself, so not to me.

Are you claiming it's not a personal attack? Implying that reading my
posts is "stooping" certainly seems to be.

Certainly I couldn't tarnish your reputation further

This, of course, is another personal attack.

It seems you're attempting to deflect attention from the substance of
the posts in this thread by frantically pursuing other topics.

I think you made a spelling error there. It should have read:

It seems I'm attempting to deflect attention from the substance of
the posts in this thread by frantically pursuing other topics.

That, I'd agree with -- instead of discussing Lisp vs. Java, you're
frantically pursuing the topic of what a fuckhead you think Seamus
MacRae is, even though it's completely irrelevant.

I would advise you to debate with substance rather than resorting
to that tactic if you want to get anywhere.

Follow your own advice. When you have something relevant to Lisp or Java
to say, I will debate it "with substance". Until then, there is nothing
to debate. Whether or not I am whatever nasty things you're thinking of
is non-negotiable -- I am not, and that's the end of it. Is that clear?

 

[Paul Donnelly]

Are you claiming it's not a personal attack? Implying that reading my
posts is "stooping" certainly seems to be.

No, I'm asking why you're whining about it like someone cares. Man up.

 

[John B. Matthews]

Nonsense. If warnings always indicated a real problem, then there
would be no need for compiler options to enable and disable them.

I must demur. Warnings always indicate the potential for harm.
Additional analysis is required to determine if that potential applies
to a particular usage. In this case, control over warnings at the level
of the compilation unit is an artifact of the development language and
implementation. The author prudently enables most warnings, eliminating
them when possible. When an anomaly was recently observed, it was the
author's familiarity with the source that allowed him to dismiss the
remaining warnings as likely culprits and address the matter directly.
Another developer maintaining the code would surely prefer as few
warnings as possible, compiler options notwithstanding.

 

[Ben Pfaff]

I must demur. Warnings always indicate the potential for harm.

Potential for harm, perhaps. Actual harm, no. I read Lew's
claim as the latter.

 

[Series Expansion]

First of all apologies for the cross posting.  Follow ups to
comp.lang.lisp

I don't think so.

Never said magical.  Powerful yes.

Maybe you didn't, but some people certainly did impute effectively-
magical powers to Lisp macros.

I don't know anything about magic.

Then perhaps you shouldn't continue this debate?

I was under the impression that you did not understand how Lisp macros
work.

Your mistake.

Lisp macros, and Alessio, who is sitting right now in the same room,
agrees with me

He clearly does not, since he said Lisp macros operate on source code
and you said they operate on object code.

For what it's worth, his claim seems to me the more credible one.

and with many people who actually know Java

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Marco.

I know plenty of Java. My job involves Java. The implication made here
that I don't know Java is a particularly severe insult, and just as
irrelevant and unprovoked as all the others that are wearing on my
patience these days.

[Java lacks macros]

Irrelevant to the issue of which Lisp's operate on, source or object
code.

Yes.  And that is the reason why Lisp macros give you power you do not
have in Java.

Java gives you safety you do not have in Lisp. Did you have a point to
make here? Nobody claimed Lisp macros weren't powerful; I just
disputed an implication that they had powers of omniscience and
similar things that lie beyond the reach of Turing-equivalent systems.

Yes.

Thank you for realizing that.

 And Lisp macros are on par.
No.

 They can do (almost) arbitrary source-to-source transformations.

Almost arbitrary. There are some that they cannot do, including any
that would require omniscience, or knowledge of the whole code-base
including all the unwritten future code the output might eventually be
linked with, or prescience, or similar powers.

Of course I am.  I have few ideas but confused.

Perhaps you should stop posting until you've gotten un-confused.

They are a "very good thing"TM which give the programmer power.
Again, in Java there is nothing similar.

And Lisp lacks things that Java has.

When you actually have a point of some sort, please be sure to let me
know.

If you took the time to get your level of knowledge of Common Lisp
near the level of competence I or Alessio or many other people here
(in comp.lang.lisp) have with Java

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Marco.

you would have dug out prog, tagbody and go, not to speak of other
cockraches in CL (every cockroach is beautiful to his mother).

Cockroaches nest in any old enough legacy system, like they do in
older tenements. C has its share, which C++ inherited. Java is
refreshingly almost free of them ... though Vector and Hashtable might
qualify. At least they aren't prone to completely blowing things up.

 What you completely missed are handler-bind, handler-case,
restart-bind etc etc

Oh, I missed nothing; I just didn't find those relevant to proving
that Lisp contains serious dangers that will make it difficult to
maintain large bodies of Lisp code in large teams.

You also missed with-open-file

I don't care for the implication that I should have commented on
something I did not find relevant.

which (1) is a macro and (2) it clearly states the intent of
the programmer, and (3) it is far better than theBufferedReader
x ... try { x = new BufferedReader(...); } finally { ...
x.close(); ... } idiom.

C++ gives you something similar through RAII. Neither is relevant to
the danger posed by unfettered macro use. While with-open-file sounds
nifty, it comes at a steep price, one large team-oriented development
efforts might be ill able to afford.

Suit yourself.  We'll be waiting for you to get up to speed on CL.

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Marco.

Remember - and I am not apologizing for sounding patronizing; I am
patronizing

How nasty of you.

I know at least as much Java as you do

Assertion unsupported by evidence.

and I know that many lispers are in the same situation.

Assertion unsupported by evidence. You don't know me. I might be the
world's foremost expert on Java for all you know, or I might just be
an average Java code jockey. You don't know which, and shouldn't
assume either.

 The opposite, with you and CL does not seem to be true.

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Marco.

 

[Series Expansion]

Last One Wins!

Your answer:

Incoherent.

 

[Series Expansion]

Most compilers tokenize the source file prior to compilation.
You can think of macros as manipulating the tokens.

That seems acceptable, but it fails to grant macros miraculous powers
of prescience.

Right, but the internal representations are isomorphic to the source
file, so with lisp the line is 'blurry'.

I have proven mathematically that if the internal representations ARE
isomorphic to the source file then your asserted miraculous properties
of gensyms are physically impossible.

(Java is to JVM as lisp is to lisp.)

(Although lisp then goes through another pass to a lower level
'virtual machine' (i.e. assembler, JVM, gcc in some cases))

In other words, Java is really to JVM as Lisp is to assembler, JVM, or
even C code.

(Lisp on the JVM. That's gotta be a match made in hell! The JVM is
full of checks and validations, which I'm sure you Lispers would
consider as anal as Java's type safety and similar "bondage and
discipline". I can just imagine the methods needed to tie it up and
gag it into accepting Lisp-derived bytecodes without blowing up in
some manner.)

 

[anonymous.c.lisper]

That seems acceptable, but it fails to grant macros miraculous powers
of prescience.

I don't think any computer language ever grant miraculous powers.

You have to recognize that for lisp, 'tokenizing' the code turns the
code into lisp objects (more or less).

I have proven mathematically that if the internal representations ARE
isomorphic to the source file then your asserted miraculous properties
of gensyms are physically impossible.

Isomorphic isn't identical,
Symbols are first class objects.

I'd like to see your proof, it sounds quite impressive.

In other words, Java is really to JVM as Lisp is to assembler, JVM, or
even C code.

I think you could say that both statements are true.

(Lisp on the JVM. That's gotta be a match made in hell! The JVM is
full of checks and validations, which I'm sure you Lispers would
consider as anal as Java's type safety and similar "bondage and
discipline". I can just imagine the methods needed to tie it up and
gag it into accepting Lisp-derived bytecodes without blowing up in
some manner.)

I believe you have to do all sorts of strange things with classes and
casting.
I really wouldn't know beyond the fact that it is doable.

 

[java.oke]

Incoherent.

Kindergarten really has been a great time!!

Thanks for reminding me

 

[Lispy Loopy]

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Marco.

That's because there are no rational arguments in favor of either Lisp
or Java. They both suck. Use Clojure, which combines the best of both
worlds.

 

[Stuart]

John B. Matthews said:


Please explain the potential for harm in:

struct tm foo = {0};

that causes this message:

foo.c:6: warning: missing initializer
foo.c:6: warning: (near initialization for `foo.tm_min')

and which vanishes when the code is changed to:

struct tm foo = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

which has precisely the same meaning as the prior code *except
that*, if for some reason the definition of foo changes to add more
fields, the former code does not need to be changed, and is
therefore superior.


Please explain *any* circumstance in which struct structname = {0};
justifies the diagnostic message (above) that GCC generates for it.

Mostly I agree with your position, but some compilers, by generating
rather silly warnings in some circumstances, make it very difficult
to agree with you completely.

Not all would agree that it is superior. If additional fields are added to
foo some [particularly those in the high-integrity domain] consider it
prudent to review assignments to a structure (particularly initializations).
Having the compiler nag you if you have overlooked some case buried deep
within your code is considered a 'superior' code design.

In the first type of initialization it is not clear whether the author's
understanding of foo matches the current definition of foo (i.e. whether any
additional fields have been added). [The warning might be better expressed
though].

In the second case it would be obvious whether there is a mismatch and the
compiler need only issue a message if the code is clearly wrong.


Where code does lead to nuisance warnings [for instance where the design
constraints of foo will _always_ require it to be initialized to 0, and
there is a high expectation that foo will continually change during the life
of the code, so the first form of initialiation is desirable], a method for
coping with this is to annotate the code (at the point the warning would be
raised) to explain the warning and justify why it is appropriate to
disregard it. Some developers even have tools to automatically filter such
warnings (comparing the warnings of a new build with those expected for any
build).


I expect this sounds like an awful lot of fuss for a great many
programmers - but for some it is a way of life!

Regards
Stuart

 

[Stuart]

Stuart said:

Not all would agree that [ = {0} ] is superior [ to = { 0, 0, 0,
0, 0, ... } ]. If additional fields are
added to foo some [particularly those in the high-integrity
domain] consider it prudent to review assignments to a structure
(particularly initializations). Having the compiler nag you if you
have overlooked some case buried deep within your code is
considered a 'superior' code design.

Well, you got me there. I don't agree with you, but I do agree that
you have a defensible position!

In the first type of initialization it is not clear whether the
author's understanding of foo matches the current definition of
foo (i.e. whether any additional fields have been added). [The
warning might be better expressed though].

Good modularisation makes it reasonably easy to ensure that one has
dealt with all the ramifications of adding a member to a struct.

<snip>

I agree with using good modularization as a primary way of managing
complexity and maintenance of programs. Even so, some choices over the way
in which some things are done (such as structure initialization) can
maximise the 'help' you get from a compiler in spotting mistakes in your
code at the expense of a 'little' extra effort in writing the code. If a
program was proving difficult to maintain because small changes were leading
to a lot of 'knock-on' effects, that may be an indication that the original
design is not properly modularized and abstracted.

If zero-initialisation is required, = {0} does the trick elegantly
and well. The only reason this wouldn't Do The Right Thing is if
some fields were required to be initialised to non-zero values.
I favour blanket zero-initialisation followed by specific
assignments to members not because I like to make work for myself,
but because - as you say - new members might be added, and this can
introduce bugs.

The difficulty is whether you (or the compiler) can be certain that you have
performed all the necessary non-zero assignments. In the domain I work in
the general recommendation is to assign to complete structures (rather than
to individual fileds) where possible and avoid the use of default cases
(which might not be valid in an extension).

Consider:

struct foo { int height; int weight; int shoesize; int quux; int
quuux; int quuuux; };

struct foo bar = { 190, 81, 12, 0, 0, 0 };

(My imagination failed for the names of the last three fields, but
basically they represent any old fields that need starting values
of 0.)

Now we maintain the struct:

struct foo { int height; int weight; int iq; int shoesize; int quux;
int quuux; int quuuux; };

and we maintain the initialisation, with the intent of inserting 115
as the IQ (might be a teacher, or a police officer, or a council
official - how many readers have I just offended, I wonder?):

struct foo bar = { 190, 115, 81, 12, 0, 0, 0 };

We've put this in the wrong place, but the compiler won't tell us
that. Far better to do this:

struct foo bar = {0};
bar.height = 190;
bar.weight = 81;
bar.shoesize = 12;
bar.iq = 115; /* rjh, 29/5/2009, Change Request 2139707B */

That way, every value is associated directly with the name of the
member, making it easier to get things right.

C99 allows us to do something similar within the struct initialiser
itself:

struct foo bar = { .height = 190, .weight = 81, .iq = 115, .shoesize
= 12, 0, 0, 0 };

which is fine provided we remember that any undesignated
initialisers that follow a designated initialiser will not "jump
back" to fill in the gaps (any members in such gaps will be
zero-initialised in the absence of any other initialisation within
a part-initialisation), so it's still possible to screw this up:

struct foo bar = { .height = 190, 81, 12};
struct foo bar = { .height = 190, .iq = 115, 81, 12 };

which gives us a shoesize of 81 and a weight of 0. Here, it is
possible that full initialisation might save you by giving you a
diagnostic message:

struct foo bar = { .height = 190, .iq = 115, 81, 12, 0, 0, 0 };

Well that would be why I prefer Ada with its named association in aggregates
;-)

Bar : Foo := (height => 190, iq => 115, weight => 81, shoesize => 81,
....);

it does not matter about the order and it has strict rules about ambiguity
caused by mixing named and positional values (in array aggregates and
sub-program calls).

It would surprise me if this code were not to generate a diagnostic
message for "too many initializers", but I can't immediately prove
from the Standard that it must (I'm not particularly familiar with
C99, and don't even have a C99 compiler).

Perhaps someone else might chip in!

And of course this technique does depend on your having a C99
compiler (or a compiler that includes some C99 features).

Or avoiding C and using something much more robust like Ada ;-)

So, in the continuing absence of C99, my own preferred method is
blanket initialisation followed by explicit assignment to named
members. It would be silly to get religious about it, but as a
general guideline I find it helpful.

I agree that it is silly to get religious about it, I have had to fight
several battles where people have interpreted generally good advice
[applicable to general design] as an absolute rule. A classic in Ada is the
prohibition on Unchecked_Conversion - a language feature which has very
practical use in specific cases but is not something you want to see
peppered throughout the code (as it circumvents the strong typing of Ada).
Unfortunately it often gets a 'universal ban'.

My main purpose in raising the point was to present a different viewpoint.
People need to make informed decisions that best meet the needs of their
programme.

Regards