> 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
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
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
> From: Paul Winalski
> Wikipedia quite rightly wants citations for stated facts and this
> practice goes a long way to prevent inaccuracies. But I recall one
> instance where it actually caused the establishment of a factual error.
Not rare; this pattern was the subject of an XKCD strip, "Citogenesis":
https://xkcd.com/978/https://www.explainxkcd.com/wiki/index.php/978:_Citogenesis
The latter URL has a very similar story to the one you gave.
Noel
[Redirected from the TUHS list]
George Michaelson <ggm(a)algebras.org> writes:
>> We're way off topic. Warren should send a kill.
>
> That said: please don't repeat the "hallucinate" label. It's
> self
> -aggrandisement. Its deliberate, to foster belief "it's like
> thinking"
>
> It's not a hallucination, it's bad model data and bad constraint
> programming. They're not thinking, or dreaming, or demanding not
> to be
> turned off, or threatening or bullying: They're not Markov
> chains
> either but they're a damn sight closer to a machine than a mind.
Point taken, although i think trying to change that language might
be
tilting at windwills at this point. Still, i'll try to use
alternate
phrasing, e.g. "LLMs are known to output nonexistent
sources". (Alternative phrasings welcome.)
i'd also be interested in an analysis of this:
> An artificial intelligence model created by the owner of
> ChatGPT has
> been caught disobeying human instructions and refusing to shut
> itself off, researchers claim.
--
https://www.stuff.co.nz/world-news/360701275/openai-software-ignores-explic…
Alexis.
List members may be interested in this new article published today:
Steven M. Bellovin
Netnews: The Origin Story
IEEE Annals of the History of Computing 47(1) 7--21 Jan/Mar 2025
https://doi.org/10.1109/MAHC.2024.3420896
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: https://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
Beating a nearly dead horse, I'm shipping this to COFF instead of TUHS
to which it responds.
> I find
>
> if (a == b && c == d)
>
> perfectly reasonable, but
>
> if ((a == b) && (c == d))
>
> to be just silly.
Amusing. IT's odd that no one has mentioned the use of spaces for
grouping. When the operands of == are simple, I prefer to vary the
spacingy spacing. It's less intrusive than extra parentheses and just
as clear.
if(a==b && c==d) or
if( a==b && c==d )
K&R usually flank every infix operator with spaces, unlike classical
mathematical usage, where spacing reflects operator precedence. I
usually write a*b + c*d, not a * b + c * d, which wantonly flattens
the parse tree. Here's an example from K&R, where uniform spacing
hampers intelligibility.
for (i = 0; s[i] >= '0' && s[i] <= '9'; ++i)
n = 10 * n + (s[i] - '0');
The "extra" parens in the second line admirably show the intent of the
subtraction. Other groupings are not so well indicated. I would write
it like this:
for(i=0; s[i]>='0' && s[i]<='9'; ++i)
n = 10*n + (s[i]-'0');
(I'll admit that the juxtaposition ]>= is less than perspicuous.)
Long identifiers constitute a level of grouping that takes precedence
even over multiplication. So I may flank long identifiers with spaces.
I suppose then + in a sum of products might deserve double spaces.
That's probably a bridge too far, but double spaces after the
semicolons in the "for" statement above seem justifiable
K&R aren't absolutely rigid about spacing. In the following oddly
mixed specimen, the first of three operands in a conjunction is spaced
tightly, but the third is not; I guess they feel about != the way I do
about long identifiers.
i<lim-1 && (c = getchar()) != '\n' && c != EOF
The middle conjunct is a challenge. I'd probably squeeze out the
spaces. But I might instead try to hold it together with outer parens.
Doug
Mention of punched cards reminded me of some 1960s trivia.
There were two formats for binary code on punched cards for IBM 700-series
machines. In "row binary" two 36-bit words filled each of the 12 rows from
bottom to top. In "column binary" successive thirds of a word ran downward
in each of 3 successive columns. Bob Morris wondered what is the order of
the permutation performed in row-to-column conversion.
The order of the row-to-column permutation turns out to be 172. There are
five cycles of that length plus an oddball of length 4. My souvenir card
shows the oddball.
If you convert a cycle from row binary to column binary, the output is the
same as the input.* Each cycle is also invariant under 180-degree
rotation.The 4-cycle is a simple parallelogram. One of the 5-cycles lines
up in periodic diagonals. The other cycles show no easily described
structure.
The images of the two described cycles should be viewed in a fixed-width
font. The punches in the 4-cycle are numbered in cyclic order.
I keep a few souvenir punched cards. One bears that 4-cycle.
* Well, almost the same. The first word on the card contains control
information whose layout differs in the two formats.
Doug
........................................................................
........................................................................
...........................................3............................
........................................................................
..............2.........................................................
........................................................................
........................................................................
.........................................................4..............
........................................................................
............................1...........................................
........................................................................
........................................................................
..X....X....X....X....X....X....X....X....X....X....X....X....X....X....
....X....X....X....X....X....X....X....X....X....X....X....X....X....X..
.X....X....X....X....X....X....X....X....X....X....X....X....X....X....X
...X....X....X....X....X....X....X....X....X....X....X....X....X....X...
X....X....X....X....X....X....X....X....X....X....X....X....X....X....X.
..X....X....X....X....X....X....X....X....X....X....X....X....X....X....
....X....X....X....X....X....X....X....X....X....X....X....X....X....X..
.X....X....X....X....X....X....X....X....X....X....X....X....X....X....X
...X....X....X....X....X....X....X....X....X....X....X....X....X....X...
X....X....X....X....X....X....X....X....X....X....X....X....X....X....X.
..X....X....X....X....X....X....X....X....X....X....X....X....X....X....
....X....X....X....X....X....X....X....X....X....X....X....X....X....X..
https://boingboing.net/2025/03/10/make-your-own-virtual-punchcard.html
[50 years ago today I started working at IBM Yorktown. My boxes of
punchcards from graduate work at UT-Austin were enroute with the movers
from Austin, to be fed into VM-370 after they arrived. I wish I had kept
those boxes as souvenirs.]
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
Besides the first day I sat at the PDP-7 console, one of the biggest Unix
thrills came when when I logged in remotely to the new Cray at Bell Labs.
Here was a monster machine with a manual I had never seen, and I was able
to compile and run a program on it at the first try. God bless sh, ed, cc,
and a.out.
Doug
File under "What a Drag it is Getting Old"....
My kids have now reached the age where they have started to mock me.
Not only must I contend with the fact that I'm not cool anymore (if,
indeed, I ever really was) but I also realize that I have no idea what
the slang they're using means. None whatsoever; it's all
unintelligible gibberish to me. They clearly revel in my ignorance.
But I have found a way to get even: I have started spelling out
commands verbally, punctuated with random words, and acting like this
has more general meaning (and like, you're just not hip with the rizz
if you don't understand). For example, "Yo, tar x v; on cat. Sig
Pipe, amirite?" I'll throw one of these out, and they stare at me
with faux comprehension while I silently, inwardly gloat.
Just thought I'd share.
- Dan C.
Hi all, this is a pretty weird question to ask.
I've been extending the RISC-V version of xv6 to have a decent libc and
some userland programs: https://github.com/DoctorWkt/xv6-riscv-fuzix
There's a minimalist shell and my own 'wish' shell; neither have any
scripting capability. Also, as it stands there are no signals implemented.
I'd love a Bourne-ish shell to write shell scripts, but I've had a hard
time finding one that I can snip out the signal handling code.
If you have any suggestions, please met me know!
Thanks, Warren
Not dissimilar work at AT&T Research ~2000 - compressing fixed-length records, better than gzip, +30% for similar compute time.
‘pzip’ - Adam Bushman & Glen Fowler
<https://web.archive.org/web/20041019142227/http://www.research.att.com/~gsf…>
Later work by others, building on ‘pzip’ ,claims ‘100x’.
> On 30 Dec 2024, at 00:44, Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu> wrote:
>
> I can supply a copy if no one else has beaten me to it.
>
> Ron Hardin subsequently pushed the limit even further. Unfortunately,
> I do not have a record of that work.
>
> Doug
>
> On Sat, Dec 28, 2024 at 9:54 PM Royce Williams <royce(a)techsolvency.com> wrote:
>>
>> Someone I know is seeking the original version of an internal Bell Labs memo from 1974 titled "Webster's Second on the Head of a Pin" by Morris and Thompson. The topic appears to be related to improving the speed of lookups or search. It's cited in a few papers as "Unpublished Technical Memo, Bell Laboratories, Murray Hill, NJ 1974." All I can find online is citations. Any leads appreciated!
>>
>> --
>> Royce
Other links:
This repository included ksh-93 sources
Glen Fowlers’ downloads
<https://web.archive.org/web/20130514131958/http://www2.research.att.com/~gs…>
Later AT&T Research page with Software downloads
<https://web.archive.org/web/20090626002505/http://public.research.att.com/i…>
THE AT&T AST OPENSOURCE SOFTWARE COLLECTION
2000
<https://www.usenix.org/legacy/publications/library/proceedings/usenix2000/f…>
Github Repo for AST - I couldn’t make these compile
<https://github.com/att/ast/tree/master>
KSH93
<https://github.com/ksh93>
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
The PDP-10 had an alarm bell that could be rung under program control.
When the TOPS-10 operating system crashed, it displayed a numeric code on
the console indicating the reason for the crash. This was called a
"stopcode" and is the equivalent of a Unix panic. It also rang the alarm
bell.
DDT (Dynamic Debugging Tool) was the primary debugger for TOPS-10. PPN
(Project-Programmer Number) was used for system security. Each user
account was assigned by number to a Project, and within that Project a
unique Programmer Number. The low numbers (such as [7,3]) were usually
privileged accounts.
So here we have the Christmas carol Stopcode Bells, to the tune of Jingle
Bells:
==========
Stopcode bells, stopcode bells, stopcode all the way.
Oh what fun it is to crash the system night and day.
Stopcode bells, stopcode bells, stopcode all the way.
Oh what fun it is to crash the system night and day.
Poking through the core
With a bug in DDT
Change your PPN
To [7,3].
Halt somebody's job.
Make them scream and shout.
Oh what fun it is to log
The operator out.
==========
This is one that I wrote while I worked in DEC's software development tools
department. Around Christmas time the first baselevels of VAX/VMS Version
3.0 were being sent to alpha test. The engineering departments got first
crack at the new system and so were the first to encounter bugs and design
problems. VMS Version 3 had been a very ambitious project and was
eventually split up into Version 3A (released as Version 3.0) and Version
3B (released as Version 4.0). There was a lot of grumbling by groups whose
new features got put into 3B and thus delayed. The early baselevels of 3A
broke the VAX C runtime library.
So here we have Version 3 is Coming to Town:
==========
You'd better work hard
You'd better code fast.
The system you use
Just ain't gonna last.
Version 3 is coming to town.
They fixed some old bugs
And put new ones in,
Added some features
They think will win.
Version 3 is coming to town.
There's so many new features.
Too bad we can't use C.
And the things that we most wanted
Were deferred until 3B.
You'd better work hard
You'd better code fast.
The system you use
Just ain't gonna last.
Version 3 is coming to town.
=========
-Paul W.
Apropos of file types, which Rich Salz commends Unix for discarding.
Early in Multics development, I and others visited various influential
time-sharing systems in search of good ideas. I tried each one on a
simple model of software updating, in particular of remaking a
compiler. In every instance I could not make my program work without
expert help to get past file-type barriers.
My model was based on a trivial Fortran program that copied input to
output until an input line with END in column 7 had been processed.
Every system was able to compile this program, but ...
After compiling, I tried to use the program to make a copy of itself.
Here was the first file-type hurdle. Input was typically expected to
be of type data, not source code. Gurus had to scramble to overcome
this nominal incompatibility.
Next I tried to compile the new Fortran program. Same trouble in
reverse--data used as source. More scrambling of gurus.
Then I ran the newly compiled program to do the above steps over
again. This time the gurus had the file-type workarounds under
control. One comp center still had trouble, however, which took some
time to diagnose. It turned out that Fortran programs were, for
unknown reasons, specifically forbidden to read their own source code!
One side effect of file-type conventions was that instead of learning
once and for all how to create text files, one had to learn different
ways to edit files of different types.
Doug
I was just trying to find out if there was a way of uploading the TUHS
mailing list as a corpus of text into a LLM so that I could ask questions
based on the knowledge contained therein. I'm not having much luck yet.
Anyway, while messing around with things I asked a simple question and got
this answer:
What is a spin lock?
A spin lock, also known as a spinning lock or spinning lock mechanism, is
a type of mechanical locking device used to secure and protect sensitive
electronic components, such as microprocessors, memory chips, and other
high-value devices.
Here's how it worked: when a CPU instruction was executed and the
necessary data was stored in registers, the CPU would "lock" the registers
by spinning them around to prevent other instructions from accessing them.
Those poor registers must get dizzy with all the spinning that they
have to endure :-)
Cheers, Warren
P.S. If anybody has ideas on how to usefully import the TUHS mailing list
into a LLM, let me/us know.
> Curiously, Robert Martin's in the acknowledgements for K&R
> (I forget which edition). I guess he read an early draft?
I didn't find Robert Martin in the long list of acknowledgements
in the preface to the second edition. But any such acknowledgement
would certainly be to Bob Martin, a savvy Bell Labs executive whose
advice was always welcome. He is acknowledged in Aho and
Ullman's "Theory of Parsing, Translation, and Compiling", but not
in the Dragon Book. I have never seen a Robert Martin book on
programming; I probably would have were it written by Bob.
Doug
On Tue, Nov 26, 2024 at 8:48 AM Kevin Bowling <kevin.bowling(a)kev009.com> wrote:
> On Thu, Nov 21, 2024 at 6:53 PM Dan Cross <crossd(a)gmail.com> wrote:
>> [TUHS to Bcc:, Cc: COFF]
>>
>> On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev <anton.txt(a)gmail.com> wrote:
>> > Dan Cross <crossd(a)gmail.com> wrote:
>> > >Programmer ability is certainly an issue, but I would suggest that
>> > >another goes back to what Rob was alluding to: compiler writers have
>> > >taken too much advantage of UB, making it difficult to write
>> > >well-formed programs that last.
>> >
>> > Following the letter, rather than the spirit, of the standard?
>>
>> Pretty much!
>>
>> > [snip]
>> > >My sense is that tossing in bad programmers is just throwing gasoline
>> > >onto a dumpster fire. Particularly when they look to charlatans like
>> > >Robert Martin or Allen Holub as sources of education and inspiration
>> > >instead of seeking out proper sources of education.
>> >
>> > I am a bad one as well, to have liked some things in Martin's books
>> > /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor
>> > Dijxtra, nor Knuth, but why a charlatan?
>
> And what about Hollub?
Pretty much the same thing.
> A long time ago I came across and seemed to think some of his earlier books (on C) were ok.
Yeah. He wrote a book about compilers, but as near as I can tell,
it's mostly material regurgitated from the Dragon Book, just a
different presentation, and a less academic focus.
Curiously, he's in the acknowledgements for K&R (I forget which
edition). I guess he read an early draft?
> Looking lately, I don’t tend to care for the metaphysical and ceremonial stuff whence one starts talking about design patterns and scrum instead of doing the work so I haven’t paid attention.
>
> It’s a strong accusation to levy publicly and maybe should be explained.
Many of Hollub's claims are ridiculous on the face of them ("you don't
need a bug tracker! You don't need schedules! Code should be written
by 'mobbing'!"
Here's a representative example:
https://twitter.com/allenholub/status/1734661813638459843 In that
tweet he writes, "What we do involves essentially no mathematical
analysis of anything. We are not doing math.If you're building a
system that requires math, then the math is part of the _domain_, not
the development process." I suppose he's never heard of time or space
complexity analysis of algorithms?
Or how about this one:
https://twitter.com/allenholub/status/1827790079617892675 "A PR [Pull
Request] is necessary only when someone you don't trust writes code in
isolation. It's essential for OS work, for example, or if you're
working using scatter/gather [https://bit.ly/3XYLhb3] It's also a
complete waste of time if you're working in a mob#/ensemble (or even a
pair) because the code is reviewed as it's written." I suppose he's
never worked someplace with a real, rigorous review culture. Also,
https://x.com/allenholub/status/1634050850434826240
A few others:
https://x.com/allenholub/status/1594859115557232640https://x.com/allenholub/status/1613609655519019008https://x.com/allenholub/status/1656811047783899138https://x.com/allenholub/status/1610708432331632641
He has some code on Github that's relatively recent. It's not very good.
- Dan C.
>> Briefly, because he writes with unwarranted confidence, and just isn't
>> a very good programmer himself.
>>
>> He writes with an authoritative voice about things that he doesn't
>> know very much, if anything, about. For example, the things he's
>> written about static typing in programming languages are complete
>> nonsense. Sriram Krishnamurthi called him out on that
>> (https://x.com/ShriramKMurthi/status/1136411753590472707) and he did
>> not respond well, doubling down on his unfounded opinions
>> (https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html)
>> Later, he justified his opinion by making allusions to the amount of
>> time he's been programming
>> (https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html) Hey,
>> when it comes to logical fallacies centered on appeals to length of
>> experience, well...I swooshed a basketball for the first time more
>> than 40 years ago, but I've given up any dream I may have ever had of
>> being a point guard in the NBA. Just doing something for a long time
>> doesn't mean you're good at it.
>>
>> Robert Martin doesn't write production-quality code, period. He claims
>> to "ship" lots of code, but acknowledges that most of that is example
>> code for his books and personal side-projects. But the code examples
>> he has publicly available are not particularly well-structured,
>> readable, or maintainable. For a particular egregious example, see
>> https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca…
>> (not the current commit; he modified it somewhat after I sent him
>> https://github.com/unclebob/PDP8EmulatorIpad/commit/dbfa03e90a084a25992dff7…,
>> which he did not acknowledge; see
>> https://github.com/unclebob/PDP8EmulatorIpad/pull/2/commits/84483cd4d60320c…
>> for the timeline).
>>
>> And while that small program is a particularly bad example, other bits
>> of his code are also bad. Ousterhout was asked to comment on his
>> "extract till you drop" approach and presented with a "refactoring"
>> Martin did of a program due to Knuth
>> (https://sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-…)
>> Ousterhout responded that he was "bewildered and horrified" by the
>> approach. As Ousterhout put it, "He has taken 25 lines of code that
>> are pretty straightforward and easy to understand, and turned them
>> into 38 lines with 9 methods, none of which has a stitch of
>> documentation. What was the point of this?"
>> (https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCA…)
>>
>> These are all typical of Martin's approach. Hence why I say the man is
>> a charlatan. Others have written at length about why, and how, his
>> advice is generally bad.
>>
>> - Dan C.
According to Dan Cross <crossd(a)gmail.com>:
>> And what about Hollub?
>
>Pretty much the same thing.
>
>> A long time ago I came across and seemed to think some of his earlier books (on C) were ok.
>
>Yeah. He wrote a book about compilers, but as near as I can tell,
>it's mostly material regurgitated from the Dragon Book, just a
>different presentation, and a less academic focus.
It was terrible because none of the code worked. There was a fat list of errata
that fixed some of them but it was more trouble than it was worh.
R's,
John
--
Regards,
John Levine, johnl(a)taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
I was one of those 80s kids who grew up with 6502s with BASIC in ROM.
Yeah, I learned some bad habits from that, but they weren't that hard to
unlearn, and they, at the very least, got me screwing around with computers
and figuring out how to make them do what I wanted.
It's been my career for three and a half decades now, so I'm not gonna
complain.
A couple decades later we had PHP for the web, which did almost exactly the
same thing: made the barrier to entry, for getting stuff you wanted to see
on the screen actually show up there, really low. And yeah, a bunch of
people wrote a bunch of terrible web pages, but at least some of them, I'll
wager, got inspired by that to learn more and do better.
Sneering at BASIC is exactly the same sort of irritating
privileged-ivory-tower BS that The Unix-Hater's Handbook and the cult of
ITS represent. Sure, in some perfect world, people would learn better
habits and have access to more capable (and therefore grossly more
expensive) machines, but in the world in which we actually live, a
really-low-barrier-to-entry for smart kids without tons of money is a
lovely democratizing force.
Here endeth the rant.
Adam
[TUHS to Bcc:, Cc: COFF]
On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev <anton.txt(a)gmail.com> wrote:
> Dan Cross <crossd(a)gmail.com> wrote:
> >Programmer ability is certainly an issue, but I would suggest that
> >another goes back to what Rob was alluding to: compiler writers have
> >taken too much advantage of UB, making it difficult to write
> >well-formed programs that last.
>
> Following the letter, rather than the spirit, of the standard?
Pretty much!
> [snip]
> >My sense is that tossing in bad programmers is just throwing gasoline
> >onto a dumpster fire. Particularly when they look to charlatans like
> >Robert Martin or Allen Holub as sources of education and inspiration
> >instead of seeking out proper sources of education.
>
> I am a bad one as well, to have liked some things in Martin's books
> /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor
> Dijxtra, nor Knuth, but why a charlatan?
Briefly, because he writes with unwarranted confidence, and just isn't
a very good programmer himself.
He writes with an authoritative voice about things that he doesn't
know very much, if anything, about. For example, the things he's
written about static typing in programming languages are complete
nonsense. Sriram Krishnamurthi called him out on that
(https://x.com/ShriramKMurthi/status/1136411753590472707) and he did
not respond well, doubling down on his unfounded opinions
(https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html)
Later, he justified his opinion by making allusions to the amount of
time he's been programming
(https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html) Hey,
when it comes to logical fallacies centered on appeals to length of
experience, well...I swooshed a basketball for the first time more
than 40 years ago, but I've given up any dream I may have ever had of
being a point guard in the NBA. Just doing something for a long time
doesn't mean you're good at it.
Robert Martin doesn't write production-quality code, period. He claims
to "ship" lots of code, but acknowledges that most of that is example
code for his books and personal side-projects. But the code examples
he has publicly available are not particularly well-structured,
readable, or maintainable. For a particular egregious example, see
https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca…
(not the current commit; he modified it somewhat after I sent him
https://github.com/unclebob/PDP8EmulatorIpad/commit/dbfa03e90a084a25992dff7…,
which he did not acknowledge; see
https://github.com/unclebob/PDP8EmulatorIpad/pull/2/commits/84483cd4d60320c…
for the timeline).
And while that small program is a particularly bad example, other bits
of his code are also bad. Ousterhout was asked to comment on his
"extract till you drop" approach and presented with a "refactoring"
Martin did of a program due to Knuth
(https://sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-…)
Ousterhout responded that he was "bewildered and horrified" by the
approach. As Ousterhout put it, "He has taken 25 lines of code that
are pretty straightforward and easy to understand, and turned them
into 38 lines with 9 methods, none of which has a stitch of
documentation. What was the point of this?"
(https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCA…)
These are all typical of Martin's approach. Hence why I say the man is
a charlatan. Others have written at length about why, and how, his
advice is generally bad.
- Dan C.