[racket] Aging code

On Wed, Jul 10, 2013 at 10:14:31PM -0400, Sean McBeth wrote:
> Hey! Thanks for the story! Yeah, here I'm complaining about unstylish code
> over 15 years, you've got a completely different problem! Very interesting.
> 
> In a way, it fits one of my categories. I'm sure there was a motivation for
> writing an Algol 68 compiler, a motivation that just did not stand up to
> time. Much like my ersatz Canvas drawing system (I think I even called it
> Canvas), it's fun and challenging and engaging to actually write the code,
> but it's not going to be a component of a modern system.
> 
> Your comment on a simpler sublanguage is interesting. Over dinner, thinking
> more on this subject, it struck me that the code that I have written over
> the years that has stood up better over time has been "the simplest
> possible, but no simpler". Fancy tricks have a tendency to get invalidated
> in compiler updates.

I've heard that's a quote from Einstein:

Things should be as simple as possible, but no simpler.

---

There's another program I wrote a few years aago that was debugged into 
existence,  THe spec was simplistic and vague -- take unedited ASCII 
text with minimal for something like a story or a novel, and convert it into 
sonething that looks somewhat reasonable.

The tough part was to ensure that no matter how horrible or 
misleading the program should not ger derailed, but produce 
output that's useful for further proofreading and rewriting if 
necessary.

Something like <i> an extreme silliness </i> can easily e interpreted 
as indicating italice, for example, but if the trailing </i> were to be 
left off the program should *not* put the rest of the book in italics.

This was essentially a user-interace problem -- he kind of thing taht 
can only be got right by trial and error.  I keep tinkering with 
it; it became a compromise between the efforts I have to exert 
when writing text and writing code.

Of course the code became a mess of special cases, and was hard to 
debug.  Some very intricate endless loops shosed up. etc.

Recently I had a new insight into this, and chose a parsing formalism 
that guarantees to find structure in just about anything, and never 
gets stymied by errors.  It's one I had thought of for programming 
language design way back in the 60's (but never implemented).  But now 
I realised it would be perfect, using html tags as operators...

THis new parser first made things more compliccated, then I started 
seeing simplifications -- ways of rewriting code by using more general 
concepts to induce conceptual (if not operational) simplification.

And the code got smaller.  That was the intention.

And the code got faster.  This was a surprise -- I was going for 
comprehensibility above all other criteria.

-- hendrik
  
> 
> I also thought about the types of languages I'm likely to write in. I did
> almost exclusively Java and C# during the time I was employed by a boss.
> There are some cultural pressures that seem to make these particular
> languages volatile over time. Like, if you don't have a new version of C#
> every year, it's an indication that the language is dead or something.
> Whereas C over the years is not hugely different from when it started.
> Thinking beyond my short experience, it's obvious that a developer culture
> that values upheaval in the language every few years is going to encourage
> the sort of staleness that I mentioned in my Priority Queue story.

Onec you get something really right you don't have to tinker much with 
it.  Then everyone forgets about it, and takes it for granted, and 
forget that you were involved with it, and figures that because of 
inactivity it's obsolete.  My friend Dick Grune summarised this as 
"Correct Programming Harmful To One's Career."

> 
> I still have to do a lot of .NET stuff today for some of my clients, so I
> have to keep the latest versions of Visual Studio installed on a Windows
> partition. Going through my code, I was struck by how poorly VS2012 "played
> with" projects built in VS.NET 2003. It technically works, yes, but it
> first insists that I upgrade the project files and occasionally misses some
> of the dependencies. Yet I've never had a problem with running GCC against
> a pile of code, no matter how old it is (though again, not *that* old).

The *available* languages I currently prefer are Modula 3, OCaml, and 
Scheme.  I'm tempted by Typed Scheme, but the Scheme I use most is 
GambitC, because of the potential of its excellent C interfacing.

-- hendrik


> 
> 
> On Wed, Jul 10, 2013 at 8:26 PM, Hendrik Boom <hendrik at topoi.pooq.com>wrote:
> 
> > How can I resist this request to talk about ancient code?  Even if it
> > seems off-topic?
> >
> > My own long-lived examples are a type-theoretical program verifier,
> > and an Algol 68 compiler.
> >
> > In 1972 I started an Algol 68 conpiler, worked on it for a few years at
> > the University of Alberta, decided to abandon the project when it went
> > over two and a half years (I had planned ono two) and my PDF expired,
> > went on to work at the Mathematical Centre in Amsterdam , where
> > against my better judgement I was persuaded to resue work on it.  The
> > facilities there were much worse than the ones I had had in Alberta.
> >
> > When that time came to a close I had a compier that handles about half
> > of a very demanding test suite.
> >
> > But that meant it was probably about 90% complete, but you really
> > needed closer to 99% to make the thing useful.
> >
> > I backed it up on magnetic tape, left one copy in a friend's sock
> > drawer and took teh other with me.
> >
> > Over the years the one I had got copied a few times, because
> > reel-to-reel 9-track tape drives were getting scarce.
> >
> > Unfortunately, one time that copy was not done correctly, although it
> > appeared to have been done correctly.
> >
> > Then a few years ago I found that someone on the other side of the
> > world had written an Algol W compiler (the language in which I had
> > written my compiler), and I tried to use it to resurrect my Algol 68
> > compiler.  When I discovered the bit rot I felt sick.
> >
> > But my friend in Amsterdm had contacts within IBM, and someone there
> > took it on as a personal project.  It turned out he was working on
> > long-term data archiving, and he thought it was just *great* that he
> > gos a 30-year-old magnetic tape to try to recover data from.  For all I
> > know that tape might have been mentioned in some archiving conference
> > proceedings.
> >
> > Anyway, I got the enntire compiler and a bunch of other data sent to me
> > in 8-bit EBCDIC code and proceeded to decode it.
> >
> > I ended up with the source code to the compiler.  It was really fun to
> > be looking through it again.
> >
> > Most of hte deficiencies I find looking at it are caused by
> >   (1) It wasn't finished
> >   (2) the limitations of Algol W.  Algol W was a pretty good tool for the
> > time, with garbage collection and data structures, but its limitations
> > were severe.  No decent modern modules and separate compilation
> > mechanisms (although procedures could be separately compiled if they
> > didnt need any global variables) and limita on the size of procedures,
> > on the number of blocks in a compilation, and on the number of
> > different record types that could be used in a complete program (16 of
> > them).  There limitations rather warped the program from its  original
> > design.
> >   I'd love to do the whole thing over, except that it might take a few
> > more years, and I don't think anyone would be interested in the
> > resultt.
> >
> >   Nevertheless, I go back to work on it every now and then in
> > one-or-two-month spurts of energy.  Doingg this is kind of like playing
> > a video game of extreme complexity.  Each new test case passed is line
> > beating a boss.
> >
> > A lot of code in the code generator got tossed or commented out,
> > because that class of machine just isn't around any more.  But I do
> > keep the old commented-out code around until I'm ready to ocmmit to the
> > new.
> >
> > If anyone is interested in looking at the code, it's available from
> > the monotone repository at http://mtn-host.prjek.net/.  The algol W
> > compiler in that repository has bugs; it's *not* the version I'm
> > using, and I'm currently wondering how it's related to the one I *am*
> > using.
> >
> > Every now and then I wake up in the middle of the night having
> > figured out once again how I should have approached the whole
> > project.
> >
> > They vary a lot in detail, but the common threads are:
> >
> > (1) I should have started with a simplified, significantly unoptimizing
> > code generator, then wrote test cases for it.
> >
> > (2) I should have also started implementing a sublanguage -- a
> > sublanguage that contained only the features I really needed for
> > writing the compiler.
> >
> > Actually, it wouldn't really have been a sublanguage -- it would have
> > had a subset of the semantics, but drastically simplified syntax, and
> > almost no implicit type conversions.  Kind of a compromise betwen a
> > programming language and a test generator for the code generator.
> >
> > (3) write the real compiler in the sublanguage, extending the
> > sublanguage whenever implementing a feature was faster than coding
> > around its absence.
> >
> > The history of the verifier is a tale for another day.
> >
> > -- hendrik
> >
> > ____________________
> >   Racket Users list:
> >   http://lists.racket-lang.org/users
> >