“ChattyG takes a college freshman C/C++ programming exam”
https://www.theregister.com/2023/10/03/chatgpt_code_college/

“ChatGPT was put to the test via a series of humdrum freshman C/C++
programming tasks and it passed – though not with honors.”

“According to a Croatian research team, while first-year students can
struggle with some of the assignments, the results [PDF] showed ChatGPT
hitting proficiency targets that ranged between average and that of
experienced programmers. And naturally, as with all college exams,
outcomes can be determined by how questions are worded.”

Lynn

On 10/5/2023 3:40 PM, Lynn McGuire wrote:
> “ChattyG takes a college freshman C/C++ programming exam”
>    https://www.theregister.com/2023/10/03/chatgpt_code_college/
>
> “ChatGPT was put to the test via a series of humdrum freshman C/C++
> programming tasks and it passed – though not with honors.”
>
> “According to a Croatian research team, while first-year students can
> struggle with some of the assignments, the results [PDF] showed ChatGPT
> hitting proficiency targets that ranged between average and that of
> experienced programmers. And naturally, as with all college exams,
> outcomes can be determined by how questions are worded.”

If we keep teaching it, it should get better and better... :^o

Am 06.10.23 um 00:40 schrieb Lynn McGuire:
> “ChattyG takes a college freshman C/C++ programming exam”
>    https://www.theregister.com/2023/10/03/chatgpt_code_college/
>
> “ChatGPT was put to the test via a series of humdrum freshman C/C++
> programming tasks and it passed – though not with honors.”

This is already outdated. I've read the paper and they used the free
version, aka GPT-3.5. They should repeat the same tests with at least
GPT-4. There is a vast improvement especially in programming skill from
3.5 to 4.

In addition, there are open source models available which you can run on
your own computer [1], some of them are specifically finetuned towards
coding - e.g. WizardCoder [2]. The version finetuned to Python
specifically is claimed to surpass GPT-4 in some benchmarks. It can be
downloaded in quantized form, ready to run even CPU-only on a machine
with sufficient RAM [1,3]

[1] https://github.com/ggerganov/llama.cpp
[2] https://github.com/nlpxucan/WizardLM/
[3] https://huggingface.co/TheBloke/WizardCoder-Python-34B-V1.0-GGUF

Christian

On 10/5/2023 10:36 PM, Christian Gollwitzer wrote:
> Am 06.10.23 um 00:40 schrieb Lynn McGuire:
>> “ChattyG takes a college freshman C/C++ programming exam”
>>     https://www.theregister.com/2023/10/03/chatgpt_code_college/
>>
>> “ChatGPT was put to the test via a series of humdrum freshman C/C++
>> programming tasks and it passed – though not with honors.”
>
> This is already outdated. I've read the paper and they used the free
> version, aka GPT-3.5. They should repeat the same tests with at least
> GPT-4. There is a vast improvement especially in programming skill from
> 3.5 to 4.
>
> In addition, there are open source models available which you can run on
> your own computer [1], some of them are specifically finetuned towards
> coding - e.g. WizardCoder [2]. The version finetuned to Python
> specifically is claimed to surpass GPT-4 in some benchmarks. It can be
> downloaded in quantized form, ready to run even CPU-only on a machine
> with sufficient RAM [1,3]
>
> [1] https://github.com/ggerganov/llama.cpp
> [2] https://github.com/nlpxucan/WizardLM/
> [3] https://huggingface.co/TheBloke/WizardCoder-Python-34B-V1.0-GGUF

Thanks for the links. :^)

Lynn McGuire:

> ChattyG takes a college freshman C/C++ programming exam
> https://www.theregister.com/2023/10/03/chatgpt_code_college/

For me, it failed the very trivia:

AS: Can a C function return a pointer to itself?

CG: Yes, a C function can return a pointer to itself. This
is known as a recursive function, where a function calls
itself repeatedly until a certain condition is met. In
this case, the function would return a pointer to the
function itself to enable the recursive call.

I asked that question here:

<https://app.chatty-g.com/>
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev ha scritto:
> Lynn McGuire:
>
>> ChattyG takes a college freshman C/C++ programming exam
>> https://www.theregister.com/2023/10/03/chatgpt_code_college/
>
> For me, it failed the very trivia:
>
> AS: Can a C function return a pointer to itself?
>
> CG: Yes, a C function can return a pointer to itself. This
> is known as a recursive function, where a function calls
> itself repeatedly until a certain condition is met. In
> this case, the function would return a pointer to the
> function itself to enable the recursive call.
>
> I asked that question here:
>
> <https://app.chatty-g.com/>
>

The explanation is certainly wrong but it is true that it is possible:

#include <stdio.h>

typedef void (* fptr)(int) ;

fptr foo(int n)
{ printf("Call n. %d\n", n);

return (fptr)foo;
}

int main()
{ fptr p = foo(1);

p(2);

return 0;
}

Out:

Call n. 1
Call n. 2

jak to Anton Shepelev:

> > AS: Can a C function return a pointer to itself?
> > CG: Yes, a C function can return a pointer to itself.
>
> The explanation is certainly wrong but it is true that it
> is possible:

I disagree. A function returns the value of its declared
return type. And although C allows the definition of self-
referential structs, it does allow the declaration of self-
referencial functions.

> #include <stdio.h>
>
> typedef void (* fptr)(int) ;
>
> fptr foo(int n)
> {
> printf("Call n. %d\n", n);
> return (fptr)foo;
> }
>
> int main()
> {
> fptr p = foo(1);
> p(2);
> return 0;
> }
>
> Out:
>
> Call n. 1
> Call n. 2

You are converting void to function pointer fptr. This is
not supported in C. You might have taken advantage of
void*, which is silently convertible to any pointer, but
then again it does not work with function pointer, and C has
not analog of void* for functions pointers, so an explicit
conversion is seem inevitable.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev:

> And although C allows the definition of self-referential
> structs, it does allow the declaration of self-referencial
> functions.

does /not/ allow.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 10/8/23 04:55, Anton Shepelev wrote:
> I disagree. A function returns the value of its declared
> return type. And although C allows the definition of self-
> referential structs, it does allow the declaration of self-
> referencial functions.

What if you typedef'd the function pointer?

Also, you could probably get away with it by just setting it to a void
pointer and casting the return value to the function pointer.
--
user <candycane> is generated from /dev/urandom

candycanearter07 to Anton Shepelev:

> > And although C allows the definition of self-referential
> > structs, it does [not] allow the declaration of self-
> > referencial functions.
>
> What if you typedef'd the function pointer?

That's what I did:

typedef void (*fp )( void );
typedef stm_fp (*func )( struct my_struct * s, int i );

As you see, the `func' still must return something other
than func...

> Also, you could probably get away with it by just setting
> it to a void pointer and casting the return value to the
> function pointer.

Yes, to a void /function/ pointer, because void* is
incompatible with void(*)(void). And then it is not a
truely recursive declaration, and requires additional work
to invoke. And the following does not compile, of course:

typedef func (*func )( struct my_struct * s, int i );

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@gmail.moc> writes:

> jak to Anton Shepelev:
>
>>> AS: Can a C function return a pointer to itself?
>>> CG: Yes, a C function can return a pointer to itself.
>>
>> The explanation is certainly wrong but it is true that it
>> is possible:
>
> I disagree. A function returns the value of its declared return
> type. And although C allows the definition of self-referential
> structs, it does [not] allow the declaration of self-referencial
> functions.

The question asked is whether a C function can return a pointer to
itself. The answer is Yes: the example given shows a function
that returns a pointer to itself. The type of the returned value
doesn't match the type of a pointer to the function in question,
but the value returned does point to that function. It is true
that in C we cannot declare a self-referential function pointer
type, but that question isn't what was asked; the question asked
is Can a C function return a pointer to itself, which indeed is
possible.

Consider an analogous situation in the data domain:

void *pv = &pv;

There is no question that the variable 'pv' points to itself.
The type of 'pv' does not match the type of '&pv', but still it
is the case that 'pv' points to itself. There is no way in C to
define a pointer type T such that the type T is the same as the
type T* (i.e., a pointer to T), but that result doesn't mean a
pointer variable cannot point to itself. Similarly a function
can be defined that returns a pointer to itself.

Anton Shepelev <anton.txt@gmail.moc> writes:

> jak to Anton Shepelev:
>
>> > AS: Can a C function return a pointer to itself?
>> > CG: Yes, a C function can return a pointer to itself.
>>
>> The explanation is certainly wrong but it is true that it
>> is possible:
>
> I disagree. A function returns the value of its declared
> return type. And although C allows the definition of self-
> referential structs, it does [not] allow the declaration of self-
> referencial functions.

C does not have any way to express the /type/ of a function that returns
a pointer to itself. But self-referential functions (as most people
would use the term) are commonplace, many of them having very dull and
ordinary types!

>> #include <stdio.h>
>>
>> typedef void (* fptr)(int) ;
>>
>> fptr foo(int n)
>> {
>> printf("Call n. %d\n", n);
>> return (fptr)foo;
>> }
>>
>> int main()
>> {
>> fptr p = foo(1);
>> p(2);
>> return 0;
>> }

> You are converting void to function pointer fptr. This is not
> supported in C.

Not in the fragment shown. The conversion is from one
pointer-to-function type (void (*(*)(int))(int)) to another (void
(*)(int)) and that's allowed.

The trouble is that foo and foo(1) have different pointer-to-function
types. If C could express the right type, one could write

foo(1)(2)(3)(4);

but is it stands we can only write

foo(1)(2);

before the types go wrong. A third chained call would try to "call" a
void result.

> You might have taken advantage of
> void*, which is silently convertible to any pointer, but
> then again it does not work with function pointer, and C has
> not analog of void* for functions pointers, so an explicit
> conversion is seem inevitable.

I think it would be reasonable to say that a function /can/ return a
pointer to itself. It's just that the type will be wrong. After all,
we are happy to say that (void *)&some_int_var is a pointer to that int
object even though the type is wrong. To use that pointer to get at the
int object, a conversion is required. Similarly, to use the pointer
returned by a function like foo, a conversion is required. I would do
it like this:

#include <stdio.h>

typedef void (*generic_function_ptr)(void);
typedef generic_function_ptr (*fintp)(int);

generic_function_ptr foo(int n)
{
printf("Call n. %d\n", n);
return foo;
}

int main(void)
{
((fintp)((fintp)foo(1))(2))(3);
}

--
Ben.

Ben Bacarisse:

> C does not have any way to express the /type/ of a
> function that returns a pointer to itself. But self-
> referential functions (as most people would use the term)
> are commonplace, many of them having very dull and
> ordinary types

Yes, but by returning a pointer to itself I meant returning
the correct value of the correct type, and ChattyG
understood it as a question about recursive functions. In
one of the three attempts, it even typed a sample C program
demonstrating recursion!

> >> #include <stdio.h>
> >>
> >> typedef void (* fptr)(int) ;
> >>
> >> fptr foo(int n)
> >> {
> >> printf("Call n. %d\n", n);
> >> return (fptr)foo;
> >> }
> >>
> >> int main()
> >> {
> >> fptr p = foo(1);
> >> p(2);
> >> return 0;
> >> }
>
> > You are converting void to function pointer fptr. This is not
> > supported in C.
>
> Not in the fragment shown.

Indeed. I missed the fact that the return value of `p()' is
never used.

> The conversion is from one pointer-to-function type (void
> (*(*)(int))(int)) to another (void (*)(int)) and that's
> allowed.

Indeed.

> The trouble is that foo and foo(1) have different pointer-
> to-function types.

Which is why I have to cast it. Observe that if
void(*)(void) had similar special treatment in C as void*,
assignment would be possible without casting.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@gmail.moc> writes:

> Ben Bacarisse:
>
>> C does not have any way to express the /type/ of a
>> function that returns a pointer to itself. But self-
>> referential functions (as most people would use the term)
>> are commonplace, many of them having very dull and
>> ordinary types
>
> Yes, but by returning a pointer to itself I meant returning
> the correct value of the correct type,

Yes. I should have made it clear that I knew your complaint was about
the type. I was clarifying for all readers what the problem was -- the
type not the address.

As I went on to explain, that's stretching the point. With objects, we
accept pointers of the wrong type as being (informally) pointers to that
object, and so (I would say) it is for functions, especially as all
pointer-to-function types can be inter-converted without loss; something
that is not possible with all object pointers.

> and ChattyG
> understood it as a question about recursive functions.

yes, it's answer (apart form the initial "yes") was dead wrong.

--
Ben.

Anton Shepelev wrote:

> You are converting void to function pointer fptr. This is not supported
> in C. You might have taken advantage of void*, which is silently
> convertible to any pointer, but then again it does not work with
> function pointer, and C has not analog of void* for functions pointers,
> so an explicit conversion is seem inevitable.

It mayn't be supported in standard C, but it's a common extension—in fact,
POSIX _requires_ it in order for the dlsym subroutine to work.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
bluemanedhawk.github.io
Y'know, the one with the thing!

Blue-Maned_Hawk:
[Unicode em-dash replaced with --]
> [functions returning pointers to themselves]
> It mayn't be supported in standard C, but it's a common
> extension--in fact, POSIX _requires_ it in order for the
> dlsym subroutine to work.

How so, when casing the return value (from a different
function pointer) does not solve the problem?

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 10/8/2023 4:22 AM, candycanearter07 wrote:
> On 10/8/23 04:55, Anton Shepelev wrote:
>> I disagree.  A function returns the value of its declared
>> return type.  And although C allows the definition of self-
>> referential structs, it does allow the declaration of self-
>> referencial functions.
>
> What if you typedef'd the function pointer?
>
> Also, you could probably get away with it by just setting it to a void
> pointer and casting the return value to the function pointer.

Not sure if that's allowed. A function pointer cast to a void pointer,
which in turn is cast back to a function pointer is undefined? What am I
forgetting here?

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
> Anton Shepelev wrote:
>> You are converting void to function pointer fptr. This is not supported
>> in C. You might have taken advantage of void*, which is silently
>> convertible to any pointer, but then again it does not work with
>> function pointer, and C has not analog of void* for functions pointers,
>> so an explicit conversion is seem inevitable.
>
> It mayn't be supported in standard C, but it's a common extension—in fact,
> POSIX _requires_ it in order for the dlsym subroutine to work.

The POSIX requirement is limited to values returned by dlsym().

https://pubs.opengroup.org/onlinepubs/9699919799/functions/dlsym.html

> The return value from dlsym(), cast to a pointer to the type of the
> named symbol, can be used to call (in the case of a function) or access
> the contents of (in the case of a data object) the named symbol.

An implementation could satisfy that requirement without supporting
void* to function pointer conversions in general.

--
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 10/8/23 3:31 PM, Chris M. Thomasson wrote:
> On 10/8/2023 4:22 AM, candycanearter07 wrote:
>> On 10/8/23 04:55, Anton Shepelev wrote:
>>> I disagree.  A function returns the value of its declared
>>> return type.  And although C allows the definition of self-
>>> referential structs, it does allow the declaration of self-
>>> referencial functions.
>>
>> What if you typedef'd the function pointer?
>>
>> Also, you could probably get away with it by just setting it to a void
>> pointer and casting the return value to the function pointer.
>
> Not sure if that's allowed. A function pointer cast to a void pointer,
> which in turn is cast back to a function pointer is undefined? What am I
> forgetting here?

While not specifically called out as undefined behavior, it also isn't
ever said to be allowed.

It will work on the most common processors currently, but I have an
active product using a processor where it will definitely NOT work, as
function pointers are bigger than object pointers.

The Posix standard sort of requires that it works, but only for a
certain set of function pointers, so you can do a work around for
machines that don't actually support it.

One way to acheive the results is define the return type as a pointer to
some defined type of function, and you cast the return value to a
pointer to a function that returns that type of function, and in the
function cast the pointer to itself to that type of function.

i.e.

typedef void (*fret)(); // fret is a simplifed type we can return
typedef fret (*pf)(); // pf is the actual type of the function.

fret func() {
return (fret) func;
}

int main() {

pf p = (pf)func(); // Call the function and cast the return value
pf p2 = (pf)p(); // call the same function from the pointer
}

Note, the standard specifically says we can cast any function pointer
type to another function pointer type and back and get a usable pointer.

(untested code, but should be at least close)

Anton Shepelev wrote:

> Blue-Maned_Hawk:
> [Unicode em-dash replaced with --]

Why?

>> [functions returning pointers to themselves]
>> It mayn't be supported in standard C, but it's a common extension--in
>> fact, POSIX _requires_ it in order for the dlsym subroutine to work.
>
> How so, when casing the return value (from a different function pointer)
> does not solve the problem?

I was not referring to functions returning pointers to themselves in the
quoted part of my message. I was referring to void * being castable to a
function pointer.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
bluemanedhawk.github.io
Variably constant!

Blue-Maned_Hawk to Anton Shepelev:

> > Blue-Maned_Hawk:
> > [Unicode em-dash replaced with --]
>
> Why?

Oh, it just doesn't go with Usenet, stylistically and
aesthetically. English plain-text is must like
code -- 7-bit-clean. And like code (e.g. for Troff or
LaTeX), there are convensions for dashes, /italic/ text,
<URLs>, &c. Your signature is a mess of Unicode
characters -- terrible :-!

> > > It mayn't be supported in standard C, but it's a
> > > common extension--in fact, POSIX _requires_ it in
> > > order for the dlsym subroutine to work.
> >
> > How so, when casing the return value (from a different
> > function pointer) does not solve the problem?
>
> I was not referring to functions returning pointers to
> themselves in the quoted part of my message. I was
> referring to void * being castable to a function pointer.

Yes, and I asked why the authors of that API decided not to
use the casing that is guarranteed to work, preferring the
dubious casing of void* to function pointers. If /I/ were
the designer (should you be afraid?), I should make it two
functions:

void * dlsym_o(void *restrict handle, const char *restrict name);
void(*)(void) dlsym_f(void *restrict handle, const char *restrict name);

because the caller usually knows what he seeks. If he
doesn't, let it be a single function with a compund return
type. I am not sure what a good way to do it would be,
however, because, having to declare a struct, (with possibly
an union inside) and an enum just for this function may be
bloat, yet:--

enum dlsym_type {dsOBJ, dsFUN, dsNA}; /* the 3rd member optional */

struct dlsym_info
{ char is_found; /* flag, optional */
enum dlsym_type type ; /* optional */
void * obj_ptr ; /* NULL if not found */
void(*)(void) fun_ptr ; /* NULL if not found */
}

`optional' above means the element may be omitted from the
interface. For example, dsNA and .is_found are mutually
exclusive, and both the flag and the enum may be done away
with by requiring that the caller use whichever pointer is
not NULL, and consider the symbol not found if both are
NULL.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Keith Thompson to Blue-Maned_Hawk:

> > The return value from dlsym(), cast to a pointer to the
> > type of the named symbol, can be used to call (in the
> > case of a function) or access the contents of (in the
> > case of a data object) the named symbol.
>
> An implementation could satisfy that requirement without
> supporting void* to function pointer conversions in
> general.

Sounds a like an unnecessary special case and a loophole,
when a standard solution exists:

Message-ID: <20231009230305.adfd0d80c146dc966ab22443@gmail.moc>
Archived : http://al.howardknight.net/?ID=169688196000

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@gmail.moc> writes:
>Blue-Maned_Hawk to Anton Shepelev:
>
>> > Blue-Maned_Hawk:
>> > [Unicode em-dash replaced with --]
>>
>> Why?
>
>Oh, it just doesn't go with Usenet, stylistically and
>aesthetically. English plain-text is must like
>code -- 7-bit-clean. And like code (e.g. for Troff or
>LaTeX), there are convensions for dashes, /italic/ text,
><URLs>, &c. Your signature is a mess of Unicode
>characters -- terrible :-!
>
>> > > It mayn't be supported in standard C, but it's a
>> > > common extension--in fact, POSIX _requires_ it in
>> > > order for the dlsym subroutine to work.
>> >
>> > How so, when casing the return value (from a different
>> > function pointer) does not solve the problem?
>>
>> I was not referring to functions returning pointers to
>> themselves in the quoted part of my message. I was
>> referring to void * being castable to a function pointer.
>
>Yes, and I asked why the authors of that API decided not to
>use the casing that is guarranteed to work, preferring the
>dubious casing of void* to function pointers.

Because all POSIX systems of the day had identically
sized function and object pointers, and the committee possibly
did not believe that there would ever be a future architecture
for which POSIX would be useful that had a distinction
between object and function pointers and they had little
interest in obsoleting existing code.

dlsym showed up about 1990 in SVR4, coming from SunOS IIRC.

Scott Lurndal to Anton Shepelev:

> > Yes, and I asked why the authors of that API decided not
> > to use the casing that is guarranteed to work,
> > preferring the dubious casing of void* to function
> > pointers.
>
> Because all POSIX systems of the day had identically sized
> function and object pointers, and the committee possibly
> did not believe that there would ever be a future
> architecture for which POSIX would be useful that had a
> distinction between object and function pointers

Sounds like a instance myopic thinking. Compliance with the
Standard is always the safest road into the future. ("Write
it down in your notebooks, gentlemen!"[1])

> and they had little interest in obsoleting existing code.
>
> dlsym showed up about 1990 in SVR4, coming from SunOS
> IIRC.

What was there to obsolete in 1990, or did you mean ever
since?
____________________
1. /One-storied America/

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@gmail.moc> writes:

> Blue-Maned_Hawk to Anton Shepelev:
>
>> > Blue-Maned_Hawk:
>> > [Unicode em-dash replaced with --]
>>
>> Why?
>
> Oh, it just doesn't go with Usenet, stylistically and
> aesthetically.

What is aesthetically wrong about using a bullet-point marker? What
is stylistically wrong about writing accented characters?

> English plain-text is much like
> code -- 7-bit-clean.

That's circular. By "plain-text" you mean 7-bit clean. Texts written
in English have, traditionally, used all sort of typographical marks,
and it has always been considered goof style to write correctly.
Phonetic script should be rendered correctly. Foreign words should be
rendered correctly.

What many people think of a "plain" English text is just what we've been
forced to write by clunky technology; first typewriters and then
computers. We should more on. There was a time when people would moan
if I sent a file with lower case letters in it because it could not be
rendered on a CDC mainframe. Come on, it's the 21st century.

> And like code (e.g. for Troff or
> LaTeX), there are convensions for dashes, /italic/ text,
> <URLs>, &c. Your signature is a mess of Unicode
> characters -- terrible :-!

BMH has posted a bad signature. It's not UTF-8 encoded Unicode at all,
despite what the header says. It is what's called mojibake.

In fact, properly rendered, his sig just contains a few phonetic letters
and, oddly, some "BOX DRAWINGS LIGHT VERTICAL" lines for which I would
have used | (despite what I wrote above).

Of course the fact that he did not post it correctly could be seen as
undermining my case, but I take as a further call to action: come on
BMH, buck up and get it right!

>> I was not referring to functions returning pointers to
>> themselves in the quoted part of my message. I was
>> referring to void * being castable to a function pointer.
>
> Yes, and I asked why the authors of that API decided not to
> use the casing that is guarranteed to work, preferring the
> dubious casing of void* to function pointers.

Almost certainly a case that the designers knew the system involved and
were solving an immediate problem for one particular OS on a limited
class of machines (SunOS, I think). They never thought that people
would still be using it, much less critiquing it, 40 years later!

--
Ben.