FORTH is an abomination

I was forced to look at some FORTH code this morning. My brain is permanently damaged. FORTH is an abomination, whatever advantages it may apparently hold.

 \ Note 1: Text after a backslash is a comment until end-of-line.
 \ Note 2: Text within parentheses like "( n -- )" is also a comment.
 \ Note 3: To be strictly ANSI compliant, the code below is in UPPERCASE.
 \	 Most PC Forth implementations are (optionally) case insensitive.

 : STAR	 ( -- ) \ Print a single star
   42 EMIT ;	  \ 42 is the ASCII code for *

 : STARS	( n -- ) \ Print n stars
   0 DO STAR LOOP ;	\ Loop n times (0 up to n-1) and execute STAR

 : SQUARE	( n -- ) \ Print an n-line square of stars
   DUP 0 DO		\ Loop n times, keeping (DUP-licating) n on the stack
   DUP STARS CR	\ Each time, print n stars then print CR
   LOOP DROP ;	\ After loop is done, drop the n from the stack

It appears to have all the drawbacks of ASM with few of the benefits. Why not just use BEFUNGE?

Where code must survive for 30 years

Interesting conversation with a guy on the coach to London on Saturday, writing distributed middleware for Rutherford. Because he works in an environment where code must survive for 30 years, it must be robust, non-brittle, simple enough for new team members to mod without the author being present (or even alive…). Some interesting points were:

  • always wrap interfaces – assume that someone else’s interface will be changed at some point in the future (against good practise) by wrapping the interface in a layer of your own. This way, your code is independent of the details of the interface and instead forces you to think about making it implement the functionality of the interface. Obviously, in large projects with changing workforce etc., this is particularly important, but – thinking about it – I have already implemented this ‘interface hiding’ in my own code. The LinearFit routine was originally lifted straight from Numerical Recipies and so pretty nasty. I left the putrid NR interface available as a wrapper (so old code wouldn’t break), but reimplemented the guts with OO using stuff from TChart, and generalised the OO interface to be more useful. It’s acually a pretty good discipline to work to an interface, and when you can actually add functionality on the side, then it rather proves the utility of interfaces.
  • Delphi is great – shame it’s dying – having used C and C++ for major dev work, the guy seemed to wholly appreciate the benefits of Delphi. I don’t give a shit about allocating strings, for fuck sake; I just want to use them. C encourages lazy programming… was a view I’d entirely agree with (all those ‘unchecked buffers’ in webservers? 98% C code, you can bet). It’s difficult to verify the ‘dying’ bit. He said that something like 70% of all UK database infrastructure runs on Delphi, the skills are limited to x86 platforms. If only Borland would release DCC32.exe for PPC or Sparc. I guess they should have done that a while ago, because x86 seems to be the way forward now, but they are seen as Wintel-only. Kylix is dog-slow for UI stuff, too, apparently
  • investigate Python – an interesting one, because Phil and others have said the same. Python can run code as interpreted or native compiled, is modular, and can easily be used as a scripting langauge. It has dynamic typing (a la RTTI), classes, exceptions, etc. so is much more friendly than VBScript and friends. Check this out:

    Strings can be concatenated (glued together) with the + operator, and repeated with *:

     >>> word = 'Help' + 'A'
     >>> word
     'HelpA'
     >>> '<' + word*5 + '>'
     '<HelpAHelpAHelpAHelpAHelpA>'

Also mentioned how dire Motif is: apparently, with two TreeView-type widgets on a form, Motif cannot tell which one was clicked. It can tell you which node was hit, but not the owner. Solution? Two separate applications…