this is the introduction to a public domain series on fig programming. for the next part in the series, go here.
introduction: why learn computing?
in a specialized world, we could be forgiven for asking “arent there people to do this stuff for us?” the answer is there are, and if not for them we might better understand the tools we use practically every day.
yet we celebrate each time a medicine we need becomes available over the counter, so we can be our own doctor; we ask friends and family for advice on things too personal or trivial to ask anyone else; we even look for cheaper ways to refill our own printer ink. specialists matter; yet often we are terribly happy to find ways around hiring one.
when it comes to computers, most people are happy to leave all their work to tools written entirely by large companies. then they stumble through the haystack of features they dont need, to get to the relatively few that are vital to the task at hand. over time, options are replaced with requirements, and tools with ecosystems and lock-in, and you are pushed along a path you really don’t want to go.
this is the road of relative helplessness, where even learning about the tools you need every day includes nothing about how they work; only how to make them do something until theyre redesigned once again.
you can pay to have custom software made, but it costs a fortune. and you could use software that is designed more for people who are ready to take charge, but it isnt heavily advertised and you have more questions than answers when it comes to such things.
where do you get the answers? if you take the usual computer course, these things may be buried somewhere in the footnotes of a string of classes a year or more long. you may learn (and spend time learning) so much more than you have time for.
there are no shortcuts to necessity, but you can cut through some of the things you dont actually need. this cuts both ways, because you still have to learn the things you actually need; and too often those things are simply not being taught.
today you will hear that kids need to learn to code. if theyre not going to do it for a living, exactly what is the benefit?
learning to code is the shortest route to computer literacy, for two reasons: first, it supplies a solid foundation. also, it gives valuable insights into processes that make up essentially 100% of what happens when you are using a computer.
you have to experience coding to really understand the process. a pilot moves a handle in front of them and twiddles controls, while a painter smears liquid onto cloth all day; but to learn to do these things so they produce the desired results requires either an unusual level of instinct and trial and error, or an excellent education; sometimes both. those who teach themselves are going to be the “trial and error” type, but teaching can help make coding more accessible.
you can also make the language easier. basic went online in 1964 at dartmouth college, and was designed specifically to make computer programming accessible to everyone. from its beginning as a way for non-computer specialists to make use of computers, basic spread to secondary schools and even elementary school use.
logo is another language that was developed in the 1960s, best known for its triangular graphics cursor and spirograph-like designs that allow children and adults to learn programming by exploring simple commands and tasks. unlike basic, logo lends itself foremost to graphics, while more “practical” applications are relatively difficult.
however, in some ways logo has survived basic in educational use; being spun off into “drag-and-drop” programming environments such as scratch, turtleart and minecraft.
while these examples may not all be direct descendants, there is a clear evolution from the commands and exploratory nature of logo to easily discoverable and graphical programming for complete beginners. turtleart in particular follows logo in design, purpose and output, while scratch can be seen as an obvious continuation and extension of tasks made trivial by logo.
my interest is in making code itself accessible, not only teaching core concepts through a friendly interface.
from the example of basic, we know that children can learn to write code from an early age in a school setting. the concept of programming in terms of a language and not just automated tools is still valuable. todays basic is (in my opinion) generally complicated versus what it was in the 60s and 80s, but i set out to create a language with some of the strengths of basic, logo and python alike.
originally called “fig basic,” now shortened to “fig,” one of the primary goals is to teach basic programming concepts. fig is also designed to acclimate the user or student to text-based coding. instead of avoiding the environment that is arguably ideal for hard copies of program source, for logging into a remote machine including the single-board computers like the raspberry pi or beaglebone and arduino, fig caters to that environment and encourages its use.
fig is based on the following 7 (and fairly universal) concepts:
- basic math
- functions (subroutines)
i believe that even proficiency with code will lead to a more instinctive understanding of computing in general. fig is one attempt to make something more “basic” than basic; which i encourage all coders to try.
different languages have different strengths and weaknesses; most have enough functionality to simulate other languages and even computer architecture itself; this is known as being “turing complete.” though “complete” does not mean trivial; you can use scratch or minecraft to run text-coded programs written in other languages; but getting these environments to behave that way would be anything but easy.
often the “easy” way to achieve a more complicated task is with more complicated software, or a more sophisticated language. you still have to start somewhere, and “where” is not only the subject of a great deal of debate, but will remain fertile ground for innovation for many years to come.
- license: creative commons cc0 1.0 (public domain)