sitemap: index | fig19 | fig27 | fig29 | fig30 | pzmarkup | figdesign | figcheatsheet | forlanguagegeek | figbert | understandingcomputers

jump to section: #1literacy  #2whyfig  #3models  #4history  #5mechanics  #6moredetails  #7faq  #8changelog 

fig design philosophy

literacy for everyone

you know the mantra: "im [almost] computer illiterate." nonsense... if you can turn on a lamp, you can operate a computer.

what people mean is that theyre software illiterate. and if you can read, there are only three reasons you dont understand your software:

why fig

fig is actually part of a mission to solve that final reason, but we wont get anywhere without fixing the first two.

even if software is explained well, the more it is designed without you as the operator in mind, the more trouble it is to explain (and understand.)

there are some abstractions that benefit both teachers and learners; but many more obscure so much that an understanding is going to be something "magic." having a company do all of the magic for you sounds great, doesnt it? and you dont have to worry about any of it...

until of course, when it turns on you. maybe it makes your mic live and bugs your home, or maybe it deletes your library of e-books. less menacingly, perhaps it just doesnt let you do something you want (and should be able) to do. for those reasons and more, an understading of how computers work is essential.

models and anatomy

whether youre studying psychology, anatomy or machinery, model building is a gateway to understanding the subject better.

today, people are understanding hardware a little better because theyre buying single-board computers and connecting them to televisions, robots and others inventions they build themselves. if youre inclined to learn some serious coding skills, this is a great way to build computer literacy, fast.

but not everyone wants to build their literacy to that extent. they just want (or think they want) to understand the bare minimum they need to get by.

i believe this is why computer literacy is still treated as something remarkable. everyone wants a superficial understanding of the subject-- as superficial as possible! because theyre convinced that will keep things easy.

this superficial understanding keeps people scratching their heads when the software designed to hold their hand through everything drops them for a new "improved" design. now they will have to start all over again... (please, this time make it more superficial, please!)

underneath all that, everyday computing stays very much the same. we can still break it down into a simpler model.

fig isnt just about explaining a model of working software. it lets you build working models, and do so with arguably the easiest design possible.

before we get on with the design philosophy (because from here its more for people that already write code, but please stick around if youre curious) its worth talking about the history of similar efforts.

some history on educational programming

the 1960s and 70s saw a revolution in technological education. john kemeny wanted everyone to understand programming and computers, and with thomas kurtz designed a language called "basic" at dartmouth university, which would make learning computers easier for decades to come.

throughout the 80s and 90s, people were still learning how to code in basic. formally, basic has given way to vb and other languages that lend themselves to more "modern" tasks and interactions.

the learning curve for many of these more modern languages has increased, and the ubiquity of truly easy languages like basic has waned in the presence of newer ubiquitous platforms like the browser and javascript.

you can learn javascript, and it will teach you a lot about computers and especially websites. i still dont think its as suitable for explaining computers as a more friendly server-side language like python, or a minimal language like logo.

like basic, logo came out of the 1960s and is still widely used to introduce concepts in coding. some versions of logo work by dragging blocks around the screen and connecting them together, some have more features than just drawing lines and shapes and colors, and one version of logo is actually built into the writer application in the libreoffice suite.

its true that i could use any of these languages to teach computers, but what drifts away the least from what i want to demonstrate as a model includes logo, basic and python.

fig has some of the power i enjoy in python, with a syntax design inspired by logo and by pipes in bash scripting. in basic, colons separate commands while in bash, pipes "|" carry the output of one command to the input of the next. on all but the lines for a few special commands you begin by setting a variable:

simple examples


now x is set to 0. you can do this explicitly if you prefer:

x 0

or put a (strictly optional) command separator between them:

x : 0

perhaps youd like to set it to a string instead:

x : "hello there"

now lets add the "len" command found in both basic and python:

x : "hello there" : len

now instead of being set to "hello there", x is set to len("hello there").

back to a string, add a comment: (single hashes work but i often double them)

x : "hello there" : len : str ## in python: x = str(len("hello there"))

can we concatenate? yes we can:

x : "hello there" : len : str : plus "2358 "

multi-concatenation like python then print to screen:

z : x : times 4 : print ## in python: z = x ; z = z * 4 ; print z

"plus" and "times" also work on numeric variables. here is the program without separators:

x "hello there" len str plus "2358 "
z x times 4 print

which prints the following to the screen:

112358 112358 112358 112358

more details

in most lines, fig starts with a variable which becomes the "working variable" or "main variable" for that line, like the working directory in... well, you know the current working directory or you dont.

its important to point out that fig is not designed primarily for people who understand whats being talked about in this section. fig is used as a working model for teaching such concepts, it doesnt require the user to have a pre-existing concept of them.

but to get back to the structure: fig has multi-line commands just like if/end if in basic or indentation in python. in fact, the fig command unindents, for those of you familiar with the concept. the unindent command is called fig because it returns to "fig mode" after a section of inline python:

    ## that was a fig command. now we are writing python in-line.
    for n in range(7):
        print n,
    if 1:

fig is not generally sensitive to indentation, but it is for inline python. it also tries not to be case-sensitive (unlike python.)

here is the same multi-line snippet without inline python code:

## this is also valid comment syntax in fig.
## i chose it over basics ' because of visibility.
for n 0 6 1 ## in basic: for n = 0 to 6 step 1
z n prints " " prints
iftrue 1

note the fig command in the final line: remember it unindents, and so is ending the iftrue block. next is an alias for the fig command, so it ends the for/next block (like in basic.)

its helpful to readability to use aliases for fig, but not necessary. you could use "fig" in every such case. you could also use any alias you like in every such case.

fig has a dictionary (call it a hash table if you refer) with most of the fig commands and how many parameters are expected. by design, the goal is to keep it as close to 1 or none as possible, but some commands read the "main variable" and others ignore it. some change the main variable (like a function returns a value,) and others leave it unchanged (like a sub which performs a task and accepts parameters, but doesnt return a value.)


frequently asked questions

    p "hello" len
        p = 1 / 3.0 + (p * (3 + 7 * 9) ** 5.7)
    z p print