Programming in prose - is it out there?

  • Being that I can't even see the ivory tower from my foxhole, my question should probably be, who did it, and where is it now or why did it fail?

    I've been musing in another thread about writing programs using a prose syntax instead of all those curly braces and assorted little symbols.  Don't get me wrong.  I've clung to C# and its relatives for years on pretty baseless grounds.  It's just that I'm a pretty good typist when I'm not hitting the shift key all the time to get at those symbols, and I'd like to find out if there's anything out there that will really, really cut down my typing to the alphabet keys on my keyboard.

    I get the feeling that Basic, COBOL, and maybe Ruby are lighter on the symbols, but out of the three I've only coded in Basic.  That seems to be a step in the direction I'm thinking, but is there an extreme move in that direction somewhere in a journal at least?

    Maybe this will be a little more explicit:

    Let product and temporary be integers.  Let result be a string.  Given the integer named value and the string named preface, set temporary to the result of adding 42 to value.  Set product to the product of temporary and value.  Set result to the concatenation of preface and the string of the product.  Return the result.

    This is so artificial it's hard to read it and know what's going on, but could you implement a function more understandably if it was more of a real world problem?  Is this the problem with web two-point-ohyness and all that talk of ontologies, does it just get too complicated?

  • Here's a little something to save most of you a post:


  • There are a few esoteric languages that do something like that. For example, the Shakespeare Programming Language, where the code looks like a play, and Chef, which looks like recipes. Neither of those actually describe in English what the code does, though. Another one, similar to Chef but a little less obfuscated, is Sorted! - it does describe actions directly, but they're categorised by type, rather than in the order they get executed. There's also Beatnik, which can look something like English, kind of.

    I don't know of any "real" languages that do what you want, though.  Of the three you mention, I'd suggest giving Ruby a try some time.

  • Thanks for the suggestions.  I think Ruby looks like my best option here, too.  I doubt there'd be much demand right now for a serious language that looks the way I want, but maybe I'll do one for fun someday.

  • Comment Code!

    Should the value of Foo be equal to Baz, then we must proceed thusly: Read the property "name" of Foo and place this in the bag "Schmoo". A new class instance of Plip will then be created using the following arguments:

    1. Schmoo
    2. Baz
    3. A bit of text that states "three"
    The above instance of will be placed in Glonk, and then the block of code in case the value of Foo equals Baz shall be terminated.

  • I once managed to abuse Hugs (a Haskell interpreter) so I could talk to it prose-like. It was mainly lists, but it wasn't half bad:

    > say "Hello"
    > its length
    > is that: equal to 7

    > take 4 integers
    [1, 2, 3, 4]
    > map square to them
    [1, 4, 9, 16]
    > compare these with: take 4 squares

    "them" and "these" and "it" and those things were automatically generated. "to" and "with" were just 0 and are just semantics. (:) acts like ($) as separation. The last one is pushing the prose a bit but I think it still works. Since it's Haskell doing all the work here, not my own language, I think I'm allowed some limits.

  • Probably not what you're thinking of, but Inform 7 is a turing-complete language that looks like very much what you posit. It works very well


  • @tufty said:

    Probably not what you're thinking of, but Inform 7 is a turing-complete language that looks like very much what you posit. It works very well


    This is a very interesting prospect.  I imagine it would be possible to make this program output code instead of an interactive game.

    On a similarly related track, I also remember seeing an article about a MUD where the users interacted with objects through that interface.  Inform, however, looks much more sophisticated when it comes to interpreting what the programmer types.

  • I think the reason you'll find few languages without at least some
    punctuation characters is that they really are useful. Almost every
    program will use at least some degree of nesting, and parentheses are a
    clear and concise way to indicate that.

    Having said that, some languages rely on non-alphabetic characters far
    more than others. Besides the languages you mention, I find Ocaml and
    Haskell to be easy on the hieroglyphs, as well. Lisp uses very few
    punctuation characters besides parentheses, and there's SRFI-49 which
    lets you basically replace parentheses by indentation in Scheme. Forth
    isn't too bad, either.

    Of course, you can always use a macro language that uses only
    alphabetic characters and emits code in some other language. There are
    even a number of programs that translate some sort of English into C; I
    know these have been used to translate English descriptions of DeCSS
    (presumably protected as free speech) into executable code.

    Failing all that, there is always Intel assembly and Whitespace. ;-)

  • I don't think the examples above are imperative enough, therefore I present to you the Pompous Programming Language. In fact, this should probably be implementable without too much hassle:

    <font face="Courier New">let Truth be Good
    let Falseness be Evil

    the Lord
        he looketh
           judge petitioner

        he smothe
           destroy petitioner
        he said
           teach petitioner

    in the Beginning
       there was Light
       there was Dark
       the Light was Good
       and the Dark was Evil

       the Lord looketh at the Light
           and as it was Good
               the Lord said
                   "Let there be light!"

       then the Lord looketh at the Dark
           and as it was Evil
               the Lord smothe it
               and said
                  "Let light reign supreme!"


  • @Oscar L said:

    Let product and temporary be integers.  Let result be a string.  Given the integer named value and the string named preface, set temporary to the result of adding 42 to value.  Set product to the product of temporary and value.  Set result to the concatenation of preface and the string of the product.  Return the result.

    The problem is that the language we use to communicate with other people is often times very vague (words can be overloaded with dozens of different meanings) and language is also highly redundant (entropy is relatively low).

    By contrast, when we write code, we want the code to be fairly concise and the meaning of the code to be 100% clear to the compiler, hopefully also clear to other human readers of the code. If the compiler starts reading human language, it is going to need a human brain to decipher things like context, tone of the we read a lot into language based on our own experiences and pysches. The compiler will also have to be able to ask questions when it needs more information, and decide when it is safe to make small assumptions.

    To take an example from the "code" you posted: "Set product to the product of temporary and value." How does the compiler know that you used the same word here in two different ways?

    Think about this way: if you are a developer at a large-enough company, you don't direct the software development yourself. Instead, you are given business requirements. These requirements are written in somewhat of a similar language as the "code" you posted above. You, as the human, have to "compile" these instructions into some sort of intermedate form (source code), to pass off to a compiler which translates them yet again into another (possibly intermediate) form, etc. However, business requirements are not perfect, they have gaps, redundancies, vagaries -- you as a human are capable of finding these issues and asking intelligent questions to get the extra information you need. This is indeed an extremely tough thing to program into a compiler.

    Even if we do achieve a "natural language compiler" some day, I think we will still have use for many lower-level languages, because as I said above, our language is very redundant. Most technical people like to strip away most or all redundancies, and they would not be satisfied by human language programs.

  • I'm afraid to say it but Pascal is actually fairly legible.  Major complaints about it from C-family programers are the begin ... end blocks replacing the curly brackets and the assignment operator thing.  But sounds like you want to get away from that sort of thing anyway.  It was originally developed as a teaching language and except for a bit of punctuation for the compiler it reads pretty much like a normal person's psuedo-code. 

    You can try it with all the familiar .Net libraries using Delphi (most likely the newly released Turbo Delphi.NET) or Chrome

  • If you really want to get away from brackets try python on for size:


    def z(v):
        Do something stupid.
        v * 10
        return v
    if s > t:
        print "hello"
        print "Yello"


    Pretty minimalistic - and allows for some pretty 'prose-y' comments throughout.  Also, the triple quoted items show up when you run the help function within python CLI - so you can remind yourself about what the dang thing is supposed to do 6 months down the line when you have to make some changes etc...


  • Though a computer language could be made which was English in nature and represented natural prose, it is believed that it is impossible to make a compiler which could interpret prose of any natural language.  If not, it's commonly agreed that doing so is difficult and not useful.

    Some of the reasons behind this have already been presented, but I will list those that I can here:

    1. In a natural language, many different words or phrases can have the same meaning.  For example, I could say, "Sally parked the car in the garage."  I could also say, "After Sally was done driving, she left her vehicle in the carport."  Notice that the ordering of the words is different, different words are used, and some information is even uninteresting and superfluous, yet the ideas are the same.
    2. The same word can have different meanings.  Consider this dialog: "Please read chapter 5 for next week."  "No problem, I already read it."  Same word, different tense.  It can go even further.  "Please lead me to the door."  "The door made of lead?"  Here the word takes on an entirely unrelated meaning.  We can tell the difference based on context, but even that can be ambiguous.
    3. Nagel's Chinese Room argument argues that computers can only ever understand syntax and not semantics.  In a programming language, certain constructs are associated with certain outputs, but the computer does not understand what the meaning of these constructs is.  While this isn't necessary for a compiler, it causes an issue with the above points, as the compiler couldn't be guaranteed to disambiguate through context, since the context is not determined syntactically, but semantically.
    4. As hinted above, natural language contains many superfluous constructs.  Programming languages typically use terse, simple syntax and words to make writing it more efficient.  Comparing pseudocode with actual computer code at the same level, one can quickly see that natural language (English as an example) requires much more writing to convey the same information.
    I'm sure there are others, but this is a short list of why you will likely never see a compiler which could truly interpret and compile prose.

  • I think that choosing a development technology based on the syntax of the particular programming language is not the best idea, it should be chosen on it's technological merit, ie. it's ability to efficiently solve the task at hand while staying within the budget, timeline and technical constraints of the project.  As a programmer you should be willing to use whichever language will solve the problem best.

     But there are a few languages out there with syntax like the above example called Shakespeare, there are a few others as well, as a quick google of "esoteric programming languages" will show you.  However most of these are are university projects etc and certainly not something you would really use in a real world application, plus they all look incredibly verbose.

     If you really don't want to use braces and stuff and already know c# might be worth checking out.

    Also, why not just learn to touch type to all the special character on the keyboard characters on the keyboard, seems to work fine for most of the programmers i know.

Log in to reply

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.