08.10.19
Guest Post: Why I Wrote Fig (the Computer Language That Helps Techrights Operations)
By figosdev
Summary: Fig project introduced; its developer wrote some code for Techrights and has just decided to explain why he uses his own programming language
SOME helper code we recently published for the site [1, 2] had been written in Fig, whose developer explained the language as follows.
Since Techrights is now publishing Fig code, I thought it best to write a couple of articles about it — one explaining how to use it, and the other explaining why.
Stallman didn’t start the GNU project just to have another operating system, and I didn’t write Fig just to have another language. Rather I grew up with fun languages like Basic and Logo, and wanted to use them to teach coding to friends and others.
Logo lives on in modern adaptations, and so does Basic. A lot of people think Basic is bad for you, but that’s due to stuff written about the versions of Basic in the 1960s and 70s, before it gained better commands for structural programming. Both Linus Torvalds and I first learned Basic as our introduction to programming. It’s a fun, simple language when it’s done right.
“Both Linus Torvalds and I first learned Basic as our introduction to programming. It’s a fun, simple language when it’s done right.”Python is a good language for beginners, and it has modern advantages that even the most modern versions of Basic do not — it’s also a good shell language, a decent language for making games, as well as applications. But Python is definitely not as simple as Basic, and I wanted to create an even simpler language if possible.
A simple language benefits from having few rules, but it does not need to be completely consistent. If your language only has 2 rules, it will be very consistent but it could be tedious to work within that level of consistency. Fig tries to find a balance between having as few rules as possible, and having enough to be friendly.
The original Basic had very few commands, which made it trivial to learn “the whole thing.” Fig was not my first attempt to create a fun, simple language — in fact it is named after the logo for a previous language project of mine — originally fig was called “Fig Basic”. Like its predecessor, Fig was a experiment in lightweight syntax.
I had a couple of rules for developing Fig — one, punctuation would only be added as needed, within reason. This produced a language that uses “quotes for strings” and # hashes for comments. Decimal points work the same way in fig that they do in Python and Basic.
“Since Fig compiles to Python code, and has an inline Python feature, it was (and remains) possible to cheat and just use Python pretty much wherever it is needed.”As with punctuation for syntax, the other rule was to only add new statements or functions as needed, when it became too tedious to do without them. This resulted in a language with fewer than 100 commands.
Since Fig compiles to Python code, and has an inline Python feature, it was (and remains) possible to cheat and just use Python pretty much wherever it is needed. You can create a Fig function that is just a wrapper around a Python import, and that’s pretty nice. Then you can call that function using Fig’s lightweight syntax.
Fig can also do shell code, so it can interact with other programs on the computer. But I wrote an extensive (20 short chapters) tutorial for Basic more than 12 years ago, started adapting it to Python, and eventually decided to teach coding in terms of the following near-standard features:
1. variables
2. input
3. output
4. basic math
5. loops
6. conditionals
7. functions
I realise that in Python, “functions” are really method calls, but that’s not very important to most people learning programming for the first time. I see a lot of people working their way up to “rock paper scissors” programs when first learning Python, and that’s typical of how they taught Basic as well.
“While Python is case-sensitive and indented, Fig uses Basic-like (Pascal-like, Bash-like) command pairs and is case-insensitive.”I started creating simple Python tutorials aimed at Basic coders, and those gradually turned into a simple library of Basic-like Python routines, which eventually turned into Fig Basic. And Fig Basic is different than most dialects of Basic, because it took into account a lot of things I learned while trying to teach Basic and Python — namely, the things people had the most problems with in terms of syntax.
While Python is case-sensitive and indented, Fig uses Basic-like (Pascal-like, Bash-like) command pairs and is case-insensitive. Today even most versions of Basic are case-sensitive, but during its peak as a language it was not.
Fig is not parenthetical and has no operator order, other than left to right. It inherits Python’s (and QBasic’s) conventions about newlines — after an if statement, you start a newline (QBasic had a cheat about that, but Fig is consistent.)
So for example, a for loop from 10 to 2 with a step of -1 might look like this:
for p = (10, 2, -2)
now = p ; print
next
Many things about this are optional — both equals signs, the parentheses, the commas and the indentation. Here is the code with those removed:
for p 10 2 -2
now p print
next
This is based on the inspiration Fig takes from logo (specifically turtle graphics) which tends to require less punctuation in its syntax than almost any popular language — certainly among the educational languages.
The inline Python feature naturally requires indentation.
“The inline Python feature naturally requires indentation.”But I’ve created languages before and since, and Fig is only the best of those. What I really want is for people to learn programming and for people to learn how to create simple programming languages. The latter is something I’ve taught as a sort of “next step” after coding basics.
I strongly feel that we need a more computer-literate society, and code is really the shortest route to computer literacy. A programming language is basically a text-based interface to the computer itself (built on a number of abstractions… so is a command line, but a command line works like a programming language all on its own.) We need to make it easy for teachers to learn, so they can make it easy for students to learn.
A more computer-literate society would be better able to make political decisions regarding computers, and it would be better able to contribute to Free software, so creating more tools to teach coding to everyone would help immensely in my opinion.
“I strongly feel that we need a more computer-literate society, and code is really the shortest route to computer literacy.”And I feel if more people worked to create their own language, we would learn a lot more about what sorts of features (and omissions) would best suit the task of creating an educational language for everyone. Sure, Basic did very well and Logo has done very well; Python is doing well. As to whether we can make it so fewer people struggle, or explaining what makes coding truly easy or truly difficult in the initial steps, there is only so much data we have on this. We could have a lot more.
Years ago, I wanted to create a piece of software as a “kit” for making it much, much easier to design your own language. Instead of creating a formal specification and writing/generating a parser, you would choose a parser based on the style of your language and tweak it to your needs. There would be a giant collection of features, and a way of turning that into a catalog, from which you would “select” the routines you wanted your language to have.
Meanwhile, Fig is possible to take apart and change. version 4.6 is a single 58k Python script, with 1,154 unique lines of code. This includes a simple help system, which allows you to search for any command by name (even part of the name) and that gives you the syntax and a quick description of the command and what it does.
I would be just as happy for people to adapt Fig or be inspired to create their own version or own language, as I would be for them to adopt Fig for their own use. I would still like to make it easier to teach coding, so that more people are capable, earlier on, with less intimation — just like in the days when Logo was really, really simple.
“I would be just as happy for people to adapt Fig or be inspired to create their own version or own language, as I would be for them to adopt Fig for their own use.”I now use Fig for most tasks, and let me apologise for the code that Roy has published so far. I wrote that as code for internal use and took every shortcut, and he was totally free to publish it, but I don’t use the same care (recommended with good reason) when naming variables that I do when naming commands for a programming language. I actually put a lot of thought into that sort of thing — but when I name variables, I’m very sloppy. It’s a beginner’s mistake, and I still do that more than a quarter of a century later.
I will write a simple Fig tutorial or two next, but I will try to use better variable names. One convention I use a lot though — is if I need a “throwaway” variable, I will just use “p” or “now.” If the variable is going to be referenced a lot, these are definitely not good variables names at all. Writing Fig has made me a better coder and designing a language will make you a better coder too, but the variable names thing — sorry about that.
Fig puts almost 100% of variables on the left of each line (almost like creating a named pipe) so they’re easy to find. For loops and Forin loops put the variable a little more to the right, but every “standard” command in Fig begins with a variable:
howmuch = 2
p = "hello" ; left howmuch ; ucase ; len ; print ; print ; print
You can download the latest version of fig (4.6 is very stable!) here from PyGame. You can also find the language featured in the first issue of DistroWatch Weekly of the new 2017 year:
[download fig 4.6] SHA256: 4762871cf854cc8c1b35304a26d7e22c5f73b19a223b699d7946accea98d2783
Whatever language you love most, happy coding!
Licence: Creative Commons cc0 1.0 (public domain) █
Content is available under CC-BY-SA