<div dir="ltr"><div><div><div>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. </div>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. </div>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 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. </div><div>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 <a href="http://VS.NET">VS.NET</a> 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). </div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Jul 10, 2013 at 8:26 PM, Hendrik Boom <<a href="mailto:hendrik@topoi.pooq.com" target="_blank">hendrik@topoi.pooq.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <a href="http://mtn-host.prjek.net/" target="_blank">http://mtn-host.prjek.net/</a>. 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: <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> </blockquote></div> </div>