[OT] Walter's anecdotes

[Dennis]

Brian Tiffin asked in the thread [Do you use D's 
GC?](https://forum.dlang.org/post/gthgnueerizzgirfpmrt@forum.dlang.org) "Does anyone have a Walter's Wisdoms file?"

Since I like reading Walter Bright's anecdotes and experiences 
from the past, I made a compilation of the ones I found on this 
forum. Enjoy!

> Hey, anyone can ignore me and go ahead and do it that way. I 
> wish you the best of luck - sometimes us old coots are dead 
> wrong - but forgive me if I'm not going to be terribly 
> sympathetic if you ignore my advice and things go badly!

[Quote](https://forum.dlang.org/post/kgmk55$2evj$1@digitalmars.com)

## Objective-C vs C++ (February 2005)
https://forum.dlang.org/post/cv0otb$1lmn$1@digitaldaemon.com

Back in the ancient times, when dinosaurs and C ruled, I was 
looking for a way to set my C compiler (Datalight C) apart from 
the crowd. I ran across Objective-C by Stepstone and C++ by AT&T. 
Both were used about equally, and there was fierce debate about 
which one was going to be the future.

But Stepstone wanted royalties for anyone wanting to do 
Objective-C. I contacted AT&T, and they graciously said I could 
implement a C++ compiler, call it C++, and not pay royalties to 
AT&T. (They also thanked me for being the only one who ever 
bothered to even ask!)

That settled it for me, C++ was the future.

## DOS linkers (September 2013)
https://forum.dlang.org/post/l006cj$1h2c$1@digitalmars.com

Back in the bad old Datalight C days, I relied on the Microsoft 
linker which came on the DOS system disks. Unfortunately, 
Microsoft constantly changed it, even with the same version of 
DOS. Worse, numerous other Microsoft products came with yet other 
versions of LINK.EXE.

All those linkers behaved differently.

It was a frackin' nightmare to support customers with them. I 
used to have floppy disks packed full of just different versions 
of LINK.EXE.

This drove me to get our own linker (BLINK.EXE). While it wasn't 
perfect, either, at least I could actually fix problems with it 
rather than throwing up my hands in rage being unable to control 
the situation.

## Numeric imprecision (June 2014)
https://forum.dlang.org/post/nh5urp$1qf3$1@digitalmars.com
https://forum.dlang.org/post/lolj3d$nsq$1@digitalmars.com

An anecdote: a colleague of mine was once doing a chained 
calculation. At every step, he rounded to 2 digits of precision 
after the decimal point, because 2 digits of precision was enough 
for anybody. I carried out the same calculation to the max 
precision of the calculator (10 digits). He simply could not 
understand why his result was off by a factor of 2, which was a 
couple hundred times his individual roundoff error.

## Java compiler (September 2015)
https://forum.dlang.org/post/ms7gs7$272a$1@digitalmars.com
https://forum.dlang.org/post/pmktna$1hgo$1@digitalmars.com

> In my experience you can deliver
> everything people say they want, and then find it isn't that at 
> all.

My favorite anecdote on that was back in the 1990's. A friend of 
mine said that what he and the world really needs was a Java 
native compiler. It'd be worth a fortune!

I told him that I had that idea a while back, and had implemented 
one for Symantec. I could get him a copy that day.

He changed the subject.

## Stealing code (February 2016)
https://forum.dlang.org/post/naoqo8$d52$1@digitalmars.com

I've been (falsely) accused of stealing code in the past, even 
once accused of having stolen the old Datalight C compiler from 
some BYU students. Once a game company stole Empire, and then had 
the astonishing nerve to sic their lawyers on me accusing me of 
stealing it from them! (Showing them my registered copyright of 
the source code that predated their claim by 10 years was 
entertaining.)

## The real reason (June 2016)
https://forum.dlang.org/post/nj3f1q$2mcu$1@digitalmars.com
https://forum.dlang.org/post/pmktna$1hgo$1@digitalmars.com

Related to me by a friend: X told me that what he really wanted 
in a C++ compiler was compile speed. It was the most important 
feature. He went on and on about it. I laughed and said that 
compile speed was at the bottom of his list. He looked perplexed, 
and asked how could I say that? I told him that he was using 
Cfront, a translator, with Microsoft C as the backend, a 
combination that compiled 4 times slower than Zortech C++, and 
didn't have critical (for DOS) features like near/far pointers. 
What he really regarded as the most important feature was being a 
name brand.

## Data flow analysis (July 2017)
https://forum.dlang.org/post/ol0eoh$2bbh$1@digitalmars.com

Back in the 80's (!) computer magazines regularly ran C compiler 
benchmark results. (At one time I counted 30 C compilers 
available for the PC.)

I took a class at Standford on compilers, which included a lot of 
info on data flow analysis. I decided to implement it. Data flow 
analysis optimizations basically deleted the benchmark code, 
because it didn't do anything (lots of dead assignments). This 
compiler was released as Datalight Optimum C.

The article writer concluded that the compiler had a giant bug in 
it, because it ran the benchmarks impossibly fast, because it 
deleted the dead code. Instead of being lauded as the only C 
compiler on the PC that did global data flow analysis, it was 
labeled as a buggy piece of crap.

By the time we dug ourselves out of that PR disaster, other 
compilers had implemented it, too.

Ironically, these days DMD gets repeatedly charged with not doing 
data flow analysis, and clang is assumed to have invented data 
flow analysis.

Just goes to show the power of marketing :-)

## Depending on bugs (August 2018)
https://forum.dlang.org/post/pk2gv6$28g4$1@digitalmars.com

You'd be amazed at what people do and then set their entire store 
based on it. If the language spec allows it, people will do it. 
People will even design their code to require certain bugs in the 
compiler. (This really blows when you're trying to write a 
standard compliant C/C++ compiler and you get angry letters from 
customers about why I'm not supporting some stupid bug in BrandX 
C++ that they rely on.)

One of my favorite stories about this was a company that had a 
coding style where their comments looked like this:

     //******** text ********\\

     int x;

They thought it was marvelous! But what really happens when 
you've got two line concatenation characters at the end? Is one 
line concatenated, or two? You have to carefully read the spec to 
determine which, and it matters because if two are concatenated 
then the declaration of x vanishes. And BrandX did it wrong, the 
customer wrote all their code this way, and it all broke with my 
compiler, and of course it was all my fault.

I thought "who in their right mind would write code that way?" At 
least I could justify myself with BrandX is a buggy compiler, but 
when the behavior is in the spec, I have no leg to stand on.

If we want to support interfacing with C++, we have to support 
badly written C++, because that is the NORMAL case. Telling them 
their code is **** and that they should rewrite it in order to 
work with D is never, ever going to work.

Another anecdote - Microsoft MASM in the 80's was full of bugs. I 
mean full of bugs. When Borland came out with an assembler, it 
wouldn't work with most of the ASM files out there. They finally 
had to engineer in what they called "quirks mode" to emulate 
MASM's bugs. Telling customers to rework their ASM files didn't 
work for a large company, either.

## Optimizing the standard library (October 2020)
https://forum.dlang.org/post/rljdoi$dcj$1@digitalmars.com

Professional C Standard library implementations tend to be 
hideous code to perform objectively simple operations. The reason 
is speed is so desirable in foundational code that it drives out 
all other considerations. (memcpy() is a standout example.)

I remember back in the 80's when Borland came out with Turbo C. 
The compiler didn't generate very good code, but applications 
built with it were reasonably fast. How was this done?

Borland carefully implemented the C library in hand-optimized 
assembler by some very good programmers. Even printf was coded 
this way. The speedups gained there sped up every Turbo C 
program. At the time, nobody else had done that.

Much as I hate to admit it, Borland made the smart move there.