Vilani Programming

[robject]

For color in a game I'm running, I want to make up a Vilani Programming Language (VPL). The players would interact with it more or less like we do today: a display and an input device. The code is read by looking at it. It's not beamed into our heads. It could be holographic, but it's still a visual interface.

So, I can hand them a piece of paper with "code" on it, and they could read it, and puzzle it out.

Because I'm a "regular modern" programmer, I think OO and structured programming as-is are somewhat pedestrian for "Far Future" code. I want to hide that in something less familiar. Even assembly language is too familiar.

And yet, I don't want to do a variant of COBOL. But I find its column-orientation interesting.

So, I was thinking, what would Column-Oriented Programming look like?

Consider a shell-like programming language: the commands are the same, or a thin API layer on top of, typed commands. Like sed, or awk, or indeed shell.

Now take that and impose column-significance: the column position is critically important. Maybe each column is assigned a fixed, permanent meaning. Maybe there are sets of meanings. Maybe it's completely flexible (probably not). For example, display position represents data flow: input commands are on the left, internal processing is in the center, and output commands are to the right.

The result looks vaguely like a tapestry, perhaps. Or a super-wide paper tape. Or maybe it looks like a chaotic jumble (that's fine, too). Maybe all of the above.

Anyone thought along those lines before? Just total blue-sky thinking.

 

[aramis]

space delimited entry with significant blank spaces due to non use was a nightmare with punch cards...
it is worse with manual live entry.

Vilani are noted for a strong efficiency drive...

so I suspect the os will be very like unix command line. But with name truncation.

shells probably have 3 paths set... source, dest, and command (vs *nix or dos' 2, or cp/m, apple dos' & apple prodos' 1).

would expect a com device path pair, too...

I would expect directories to be two letter combinations, with files delimited by punctuation, but paths being strings. commands should be 2 to 4 letters.

lots of subdirectories unused...

the programming environment can be much more rigid but flexible... think hp-rpn on steroids.
hell, vilani math should be all rpn.

 

[tjoneslo]

It sound like what you are describing is very much like MUMPS (or M or Cache). M is a terse programming language tightly tied to a hierarchical database. All commands can be abbreviated to one (or two) characters. And if you're used to other programming languages a number of the constructs are a little sketchy. Combine that with an rpn notation and a FORTH or Lisp like Functional programming setup, and you end up with something almost unreadable.

Mumps in full text mode looks a lot like COBOL, but in minimal mode start to look like perl.

 

[whartung]

Use Forth with Vilani words. It'll look nice and foreign to them.

 

[BillDowns]

If you are wanting column oriented languages, look into Snobol, Jovial, RPG, some of those old ones.

 

[BillDowns]

Ok, robject, here's a columnar language for you. It's a bit esoteric - IBM used it in their Patient Care System before it went to IBAX as IBM's portion of that joint venture. It was originally developed in the early 70's (latest copyright I saw was 1976) by the IT department for Duke University Medical Center. Later, it was sold off to HBOC.

All data is stored in the Symbol Table. Think of it as a 4 column table in memory - name, type, length, value. There are special system Symols - the names all start with a "T-", like "T-DATE", "T-USER", etc. Names are limited to 8 characters.

There is a command stack like Forth but each command launches an system object: Screens, Forms (like a Word document), Reports, Database access, Calculations, and a special little thingie called a "Data Collection List" (DCL for short). That list of objects is not exhaustive - just indicative, BTW. All command objects read from or write to the Symbol Table. Each has a builder where the programmer codes each instance and saves it - 8 character names! Most of these are obvious how you would code them except for Calculations and DCLs. Note Screens may stack commands. The Stack is actually stored in the Symbol Table with names like "%STK0001".

A Calculation instance is a set of math expressions simply executed one by one in the order written. No big deal, just that the entire set is loaded & executed at once.

A DCL is a pretty cool tool when you get to know it. There is a special symbol names "T-STATUS", which is saved when a DCL executes - you'll see it's role in a moment. You change this status in screens, or calculations, or within a DCL, but for the latter it does not take effect until that DCL ends. In the DCL Coding form, there are 3 columns of Status codes, an Operand column, and Parameters column.

If the Operand is a Command (the stack commands pretty much work inside a DCL plus a few extra ones), then it is executed if "T-STATUS" matches your conditions. If there is only a value in the 1st status column, then T-STATUS must be higher. If there is only a value in the 2nd column, then T-STATUS must be equal. If there is a value only in the 3rd column, then T-STATUS must be lower. If there are values in columns 1 & 3, then T-STATUS must be between the two inclusively. There is an IF command and a LOOP command only available in DCLs.

If the Operand is a Symbol Name, the 3 status columns control whether the data is allowed, optional, required, or deleted. If T-STATUS is below the 1st column or over the 3rd column, it is not allowed, and thus deleted. If the 1st column or 3rd columns are not valued, then it is allowed to be present. From the 1st column to the 2nd, the data is optional - if present that's ok but it will not be fetched if it isn't present. From the 2nd column to the 3rd, it is required and the parameters will specify wherre to obtain the data, i.e. a screen or database or calculation, and any edits that over-ride the dictionary default edits. Another special command - Review Screen - works with this data mode; it should be after all the basic data elements are specified, and it forces a rescan from the top if anything on the screen is changed.

That all sounds very Vilani to me

 

[CosmicGamer]

While computers and programs would be very different in the far future, I'd think that any person with computer expertise could convert the program to something recognizable (there's an app for that). Be no more difficult than reading a text file in a language that you don't know - just put it through the translator (if it was stupid enough not to automatically translate it for you as soon as you opened it).

 

[Nathan Brazil]

Vilani, in general, did not not write code until after contact with Terrans. Each computer device was purpose built. Please read the following GURPS advantage from GURPS: Interstellar Wars

Computer Programming (see p. B184)
Imperial characters may not take this skill unless they have become familiar with Terran computer technology. Likewise, Terran characters may not use this skill when working with computers of Imperial manufacture. Imperial computers are not reprogrammable – they are designed and built for a specific purpose.
- GURPS: Interstellar Wars p.136

Also under computer options on p.162
Dedicated (Imperial Required): A dedicated computer can only run a single software program, designated when the computer is built. The primary characteristic of Imperial computers is that they are all built with the Dedicated option.

 

[mmarquee]

RPG!

This sounds a lot like RPG - which is rather appropriate http://en.wikipedia.org/wiki/IBM_RPG#Example_code

So, I was thinking, what would Column-Oriented Programming look like?

Consider a shell-like programming language: the commands are the same, or a thin API layer on top of, typed commands. Like sed, or awk, or indeed shell.

Now take that and impose column-significance: the column position is critically important. Maybe each column is assigned a fixed, permanent meaning. Maybe there are sets of meanings. Maybe it's completely flexible (probably not). For example, display position represents data flow: input commands are on the left, internal processing is in the center, and output commands are to the right.

 

[charvolant]

I'm a bit late coming to this party, but how about something like logic programming (Prolog)? In it, you express programs as statements in first-order predicate calculus. The result is that the program can be run in multiple directions, depending on what variables you leave unbound.

For example, if you have

length([], 0).
length([X | Y], N) :- plus(N1, 1, N), length(Y, N1).

and a suitably advanced processor, you can ask something like ?- length(L, 3) and get back L = [_, _, _] (a list with three elements).

It's a sufficiently unfamiliar programming paradigm for most people that it should look fairly weird. Particularly if you choose some rules on parameter ordering that don't just do expected input -> expected output

 

[Shonner]

Use APL if you want something hard to read, but runs on ship mainframes.

 

[robject]

While both Prolog and APL are obscure, their rules are quite self-evident: Prolog is an inference chain, and APL is a function chain, if I may abuse the word "chain" in order to be sloppy with my terms.

RPG is a better candidate. And punch cards were indeed on my mind when I was writing the original post.

 

[robject]

Z*PL

Descended from the ladder-logic analog hardware programming of Ziru Sirka computers, Z*PL (also called ZSPL, where 'S' stands for either sirka, star, or splat) is a columnar programming language used typically for process control.

      *************************************************************
      
      *************************************************************
      *
      * Z*PL is columnar in nature.  The purpose of a given line
      * is determined by a letter code in column 6.
      * An asterisk (*) in column 7 denotes a comment line.
        * Data on lines are whitespace separated.
      *
      *************************************************************

      * "M" (module) specs define API boundaries.
     M    ENG_J_API    Z    PL    ARM    DRC
     
      * "D" (device) specs define i/o device injection.
     D    ARMstF1    ID    E    K    S01DIMAGE        Rename(ARMST:RARMST)
     D    ARDspF1    OD    CMK    R    CCPNL0004        
     
      * "R" (register) specs are used to define data context injection.
     R    pSHNUM        S        6p
     R    pCOORD        S        30a
     
      * "K" (constant) specs define constants
     K    SOK            '        OKAY
     K    SWA            '        DELAYED
     K    SWB            '        STARTING
     K    SWNP        '        ERROR
     K    SWX            '        UNKNOWN
     
      * "C" (calculation) specs are used for executable statements.
      * Parameters are defined on one line, space separated
      
     C    *entry    JMP
     
      * the "chain" command is used to search a device for a given key.
     C            pSHNUM    chain    ARMstF1
     
      * if the record is found, move fields from the device into parameters.
     C            if        %found.ARJ
     C            set        .JDrv.COORD = pCOORD
     C            action    .JUMP
     C            endif
     C    *end    JMP

     C    *entry    STAT
     C            pSHNUM    chain    ARDspF1
     C            if        %found.ODSP
     C            set        .SH = SOK    if    %found.STW    =    0x0000000
     C            set        .SH = SWA    if     %found.STW    =    0x0000002
     C            set        .SH = SWB    if    %found.STW    =    0x0010002
     C            set        .SH = SWNP    if    %found.STW    =    0xFFFFFF2
     C            set        .SH = SWX    if    %found.STW    =    0xFFFFFFF
     C            action    .FFD2
     C    *end    STAT

 

[Hemdian]

My players aren’t typically that technical but ...

IMTU starship computers have their main programs hard-wired into ROM cartridges. The only coding that’s done onboard is writing Command Sequences. A Command Sequence can be a series of queued calls and/or a scripting language.

Outside of that context, large software projects typically use Dynamic Fractal Aspects (developed by Naasirka): A series of programming modules or ‘aspects’ are joined together. At runtime each aspect grabs other aspects from the surrounding software environment (either by cloning or co-opting) in order to meet their objectives. These additional aspects do likewise (and so on and so on) until the whole program has unfolded into memory like a fractal design. Thus how efficient and even how feature rich you program will be varies from computer to computer depending not on hardware resources but on software resources. Seed your computer with plenty of high quality aspects and all your programs will run better.

DFAs can be written in a number of different programming languages … and generally look more like contemporary program specs than code. You decide what you want the computer to do, the computer decides how best to do it. I don’t have my notes with me but I think there was ‘Tabulate’ for mathematically heavy situations, ‘Lexicon’ for translation software, ‘Squire’ for simple productivity and office applications, plus a few with Vilani names … in addition to the code compiler each comes with a framework of DFAs. ‘Vision’ was developed for media-production (including holo-TV) by Makhidkarun but uses Naasirka’s DFA architecture.

There are also Adaptive Interface Links: A data communications 'device' (could be software) for joining otherwise incompatible computers. An adaptive interface link will 'ping' a target computer and analyses the speed and format of the response, trying to determine by trial and error a working protocol. Even after successful two-way communications have been established an adaptive interface link will continue to refine the protocol ... improving it, making it faster and more efficient.

 

[phorner]

You might want to check out this link. It has samples of over 20 languages:

http://groups.engin.umd.umich.edu/CIS/course.des/cis400/index.html