From: stan.salter@ablelink.org (Stan Salter)
Newsgroups: alt.folklore.computers
Date: Mon, 22 Nov 93 21:37:00 -0500

From the pages of MathNEWS.

{SMURF -- A Next Generation Programming Language}

 As associate advisor to the undergrad computer science course-based
 computer language assignment committee--the people who decided "hey,
 why should anyone in first or second year CS learn a useful programming
 language?"--I am privy to lots and lots of neato information.
 Unfortunately, I have been forbidden to share this information with the
 math undergraduate student body. Fortunately, I don't care.  Nyah nyah
 nyah nyah nyah! Thbbppptt!

 When I first took CS246, I was disappointed to find that I'd be
 programming in Modula-3.  I'd hoped that, being enrolled in CS, I'd
 have a chance to learn a language which would have more value on my
 resume than my 7-11 cashier experience.  Moving up to CS241 I
 discovered I'd be working in Modula-3 again. It was for this reason
 that I joined UCSCBCLAC (see above), with the hopes of encouraging them
 to introduce C or C++ at the second year CS level.

 After lengthy meetings, during which several donut-fights broke out, an
 agreement was reached.  As of the 1994 fall school term, Modula-3 would
 be replaced in CS246 and CS241 with the SMURF programming languages.
 SMURF is a recently developed object-oriented modular programming
 language, described as

 "having the power of Modula-3 with the programming-ease of C".  While
 SMURF has not yet reached the popularity of C, it is expected that
 within two years it will have taken over 40% of the computer
 programming industry.

 {What the heck is SMURF?}

 SMURF stands for Short Modular Un-Recursive Function.  It was designed
 by MicroSMURF, a division of Microsoft.  One benefit of this
 association is that WinSMURF should be on the store shelves in July of
 '94.  The UW Computer Store has apparently only ordered in 80 copies of
 WinSMURF for Sep '94.  All I can say, is better get in there
 quick--it'll sell FAST!

 Borland has also announced the release of Borland SMURF++.  Since SMURF
 is already object-oriented, I asked SMURF dept. head Paul "Ziggy"
 Wienberg what the "++" stand for.  "Leave me alone" was Paul's reply.

 The simple beauty behind SMURF is that it is a simple and beautiful
 programming language.  What, you want me to elaborate?

 {SMURF is Short}

 SMURF programs are, by necessity, very short.  An individual SMURF
 program can't contain more than four function-calls.  For example, a
 SMURF module might contain one variable assignment, one function which
 acts on this variable, one call to another SMURF, and a return function
 which passes the modified variable to the previous SMURF.  Each smurf
 module can access only one variable, called SMURF.

 {SMURF is Modular}

 SMURF programs may only contain four function calls, but you can have
 thousands of the little fuckers working together.  Picture your CPU,
 swarming with SMURFs, each perform its own little job without giving a
 shit about what the other SMURFs are doing, how much CPU time its
 taking up, or who actually owns that file you told it to erase.

 {SMURF is un-recursive}

 As Bill Gates so eloquently said in his '91 interview in BYTE magazine
 "recursive programming sucks!"  To combat this archaic programming
 style, a SMURF function can not call itself.  Complex
 function-tree-structure analysis built into the SMURF compiler makes
 sure that sneaky programmers can't trick the SMURFs.

 {SMURF has (duh) functions}

 Function: If you don't know what these are, you must be very confused
 by now.


 {SMURF Modules}

 A programmer writing in SMURF must quickly learn the 100 or so
 different kinds of SMURF modules.  Rather than have libraries which
 link different kinds of functions into a module, each library has its
 own kind of SMURF module which it automatically links to.  The downside
 of this is that you can't use functions from two different libraries in
 the same module.  When you're dealing with a maximum of four function
 calls per module, this usually isn't much of a problem.  Several kinds
 of SMURF modules are described below.

 PapaSMURF: This is the main module, the progenitor of all other SMURFs.
 It does nothing but execute other SMURF modules.  In other words, it
 bosses the other SMURFs around.  There can only be one PapaSMURF.

 SMURFette: This module has no function libraries linked to it.  It
 accepts no parameters.  It returns no values.  It is incapable of input
 or output.  In other words, it performs no useful function in a SMURF
 program.  It can, however, link to any other SMURF module.  SMURF
 project-chief Yohan claims "it keeps the other SMURFs happy, and hard
 working".  There is only one SMURFette, and in large SMURF programs
 especially, she gets linked constantly.  The SMURFette module must be
 linked to the PapaSMURF module, and in multitasking SMURF programs,
 PapaSMURF's call to SMURFette have priority over all other calls.

 BrainySMURF: This module performs all the input and output functions
 available in SMURF.  In other words, whenever you want user input, or
 wish to output information to the screen, you have to call BrainySMURF.
 The BrainySMURF library is one of the most criticized parts of SMURF.
 The input routines work fine, but the output routines are slow and tend
 to include extraneous information.  You can have as many BrainySMURF
 modules as you want, but you'll wish you had less.

 ClumsySMURF: Whenever you define your SMURF variable in a module,
 you'll use some memory.  SMURF doesn't reclaim this memory when the
 module is exited, you have to destroy the variable using ClumsySMURF if
 you want that.  If you ever have more than one ClumsySMURF module
 running simultaneously, chances are they'll get confused, and start
 randomly destroying memory.

 HeftySMURF: This module moves information from one memory location to
 another. Whenever you want to assign a variable or copy a list, you've
 gotta call HeftySMURF.

 There are hundreds more, but I can't describe them all here.  See the
 upcoming CSC (computer smurf club) discussion "SMURF -- a Next
 Generation Programming Language" for more information.

 {Hello SMURF!}

 For those of you who are confused, I'll show you an example SMURF
 program. Note, each of these is a separate module-file, the name of
 which is given.

 Papa.SMURF
    SMURF!
      {
         Link Smurfette.SMURF;
         Call Brainy.SMURF.Smurf-them-hello-Brainy;
      }
    ENDSMURF.

 Smurfette.SMURF
    SMURF!
      {}
    ENDSMURF.

 Brainy.SMURF.Smurf-them-hello-Brainy
    SMURF!
      {
         SMURF = Call Hefty.SMURF.What-is-their-name-Hefty;
         OutSmurf("Hello "SMURF);
         Call Clumsy.Destroy-this-name-for-us-Clumsy(SMURF);
         ReSMURF();
    % Poor Brainy didn't get to SMURF with SMURFette
      }
    ENDSMURF.

 Hefty.SMURF.What-is-their-name-Hefty
    SMURF!
      {
         CreateSmurfString(SMURF);
         Call Brainy.SMURF.Ask-them-their-name-Brainy(SMURF);
         Link Smurfette.SMURF;
         ReSMURF(SMURF);
      }
    ENDSMURF.

 Brainy.SMURF.Ask-them-their-name-Brainy(SMURF);
    SMURF!
      {
         SMURF = GetStringSMURF("What the smurf is your name?");
    % Ha, this time I will SMURF her good!
         Link Smurfette.SMURF;
         ReSMURF(SMURF);
      }

 Clumsy.SMURF.Destroy-this-name-for-us-Clumsy(SMURF);
    SMURF!
      {
         SmurfWithAHammer(SMURF);
         Link Smurfette.SMURF;
         ReSMURF();
      }
    ENDSMURF.

 Of course, this is a very simple program, which is why so little code
 was needed.  The 420 megabyte example source code for CalcuSMURF"(a non
 smurfentific...er...scientific calculator), which comes on CD-Rom with
 WinSMURF, gives a much better demonstration of the power of SMURF.