This note gets a bit COFF-y; please redirect any replies
to that list.
USENIX Summer 1981, in Austin TX. First USENIX conference I
ever attended, and the first to which I travelled by train--
mostly.
I was somewhat shy about travelling in those days, but my
Caltech colleague Mark Bartelt talked me into going, and
suggested going by train. Except by the time I booked the
trip there was space available only from Los Angeles to
San Antonio and back, not onward from San Antonio to Austin.
But in those days I did a bit of cycle touring, often in
the company of my friend Brian Foster. Brian was also a
co-worker at the time, and was interested in attending too.
So we decided to travel together by train (in coach) to
San Antonio, arriving around 05h30, and spent the rest of
that day cycling, mostly up the frontage roads beside I-35,
to Austin.
After the conference we cycled back, mostly at night, which
was somewhat spooky (I remember seeing a thunderstorm off
on the horizon but we didn't get rained on) but saved us
a second dose of sunburn. They checked into a motel for
a day and a night until the return train came through at
02h55.
I have gone by train to nearly every other conference I've
attended since, but never again have I cycled. It was a
fun ride but a harder one than expected. In those days
of paper mapes, we visited the Caltech geography department
and plotted out what looked like a fairly smooth route,
with a slow but steady climb. The topo map we used had
a resolution of 50' altitude. Evidently the constant,
sometimes steep hills between San Antonio and Austin are
all no more than 49' tall.
It was a good conference too. One memory that sticks in
my head was Jim Joyce using Tinker Toys as a metaphor for
connecting Unix tools together.
Norman Wilson
Toronto ON
> From: Dave Horsfall <dave(a)horsfall.org>
> This will probably get me tarred and feathered, but I have a couple of
> gripes about C
Your points are not about C's semantics, and only sort of about C's syntax;
they are more formatting. In fact, it would be really easy to write something
to switch a module betweeen your preferred formatting, and 'standard' (for
the local value of 'standard') formatting.
A minor comment about your first point. I was just reading some old code of
mine, and ran across a procedure declaration of the form:
foo(string, special)
char *string, special;
Your preferred form (_without_ changing C's _formal_ syntax) that puts the
indirection level with the type has the problems that i) it would make the
declaration above potentially confusing (unless one mentally edits the line
back to 'classic' C formatting as one reads it; is 'special' a 'char', or a
'pointer to char'; the 'classic' form is quite clear about that); ii) one can
only list a single variable per line without changing C's syntax. E.g. (in
standard C) if you want to have two pointers declared on one line one would
have to say (in standard C):
char* ptra, *ptrb;
In short, there are good reasons to associate the indirection level with the
variable (standard C), and not with the type (yours). Although I gather that
you'd probably like to change C's formal syntax, to associate the indirection
level with the type, not with the variable. So one could say:
char* ptra, ptrb;
One could no longer, though, say:
char *string, special;
One change I would have made to C, in the past, was to add valof/resultis
(from BCPL; lacking in C). That's because C macros that return values _have_
to use _only_ expressions (e.g. ((expr0) ? expr1 : expr2)), not more complex
code like 'case' (which valof/resultis would let you do). Of course, modern
compilers do optimizations that make that a lot less necessary.
The thing I would still add to C is condition handling (although I have
written assembler packages that added a very efficient one to C without
changing the C language; and JTW and someone did a less capable one entirely
in C - mine had unwind protects).
Explaining why condition handlers are a good thing I don't have the
time/energy to do right now, but I can explain it if people want to hear it.
Noel
> Overloading bit shifting operators to implement stream I/O was a repellent choice
Without commenting on this judgement, I can tell how the convention
came about in a casual conversation.
I was perhaps the earliest serious experimenter with C++ overloading,
for a constructive solid geometry package in which arithmetic
operators were overloaded for matrices and vectors, and boolean
operators were overloaded for union and intersection of geometric
objects. I've forgotten how object subtraction (e.g. to drill a hole)
was represented. Sadly, the symbol vocabulary for overloading was
fixed, which meant that two vector products (dot and cross) vied for
one operator. Joe Condon put me onto an interesting analog of quotient
and remainder in 3D. The quotient. of two vectors, q=a/b is the ratio
of the projection of a onto b to b and the remainder r=a%b is the
component of a perpendicular to b, The usual quotient-remainder
formula holds::a = q*b + r.
Once, while discussing some detail of overloading, Bjarne remarked
that he'd like to find an attractive notation for stream IO, which
printf certainly is not. << and >> immediately popped into my mind.
They've been in the language ever since.
Equally casually, there was no discussion about the set of operator
symbols, so C++ did not come up with a convention for symbol syntax,
such as that of Haskell.
Doug
I love C; I think it's a great language. But there are things I wish
were different in C, and I wish it had less undefined behaviour.
I've been having fun designing a language called 'alic' to do the above.
I feel proud enough to mention it here. Have a look at the doc which
compares it to C, if you are interested:
https://github.com/DoctorWkt/alic/blob/main/docs/overview.md
Rather than talk about alic, reply with what you like/hate about
your favourite language!
Cheers, Warren
TUHS->COFF
> > It's like Wikipedia.
>
> No, Wikipedia has (at least historically) human editors who
> supposedly have some knowledge of reality and history.
>
> An LLM response is going to be a series of tokens predicted based on
> probabilities from its training data. ...
>
> Assuming the sources it cites are real works, it seems fine as a
> search engine, but the text that it outputs should absolutely not be
> thought of as something arrived at by similar means as text produced
> by supposedly knowledgeable and well-intentioned humans.
>
> An LLM can weigh sources, but it has to be taught to do that. A human
> can weigh sources, but it has to be taught to do that.
Before LLMs, Wikipedia, World Wide Web, ... adages such as "Trust, but
verify," and "Inspect what you expect," were appropriate, and still are.
Dabbling in editing and creating Wikipedia articles has enforced those
notions. A few anecdotes here -- I could cite others.
1. I think my first experience was trying in 2008 to fix what is now at
https://en.wikipedia.org/wiki/Vulcan_Gas_Company_(1967%E2%80%931970),
because the article had so much erroneous content, and because I had
worked/performed at that venue 1969-70. Much of what I did in 2008 was
accepted without anyone else verifying. But others broke things/changed
things, even renamed the original article and replaced it with an
article about a newer club that adopted the name. A few years ago, I
tried to make corrections, citing poster images at
https://concerts.fandom.com/wiki/Vulcan_Gas_Company. Those changes were
vetoed because fandom.com was considered unreliable. I copied the images
from fandom to https://technologists.com/VGC/, and then citing those
images was then accepted by the editors involved. (The article has been
changed dramatically, still is seriously deficient, IMO, but I'm not
interested in fixing.)
2. Last year, I created https://en.wikipedia.org/wiki/Hub_City_Movers,
citing sources I considered reliable. Citations to images at discogs.com
were vetoed as unreliable, based on analogous bias against that site.
Partly to see what was possible, I engaged with editors, found citations
they found acceptable, and ultimately produced a better article.
3. Later last year, I edited https://en.wikipedia.org/wiki/IBM_AIX to
fix obviously erroneous discussion of AIX 1/2/3. Even though I used my
own writings as references, the changes were accepted.
I still use the Web, Wikipedia, and even LLMs, but cautiously.
Charlie
--
voice: +1.512.784.7526 e-mail: sauer(a)technologists.com
fax: +1.512.346.5240 Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/mas.to: CharlesHSauer
From https://spectrum.ieee.org/bellmac-32-ieee-milestone
"The group wrote its own version of Unix, with real-time capabilities to
ensure that the new chip design was compatible with industrial
automation and similar applications."
Would that be in the archives?
S
