code.org and codesters

a friend of mine that did marketing and communications for a large organization showed me that heavy critique can be a launchpad for discussing who you are and what you have to offer.

so yesterday when i blogged about idit harels quartz article, i found it necessary to review code.org and see what it was like to use once and for all. note that i am not affiliated with them in any way, if anything i am (like harel) in “competition” with code.org, but not any kind of serious competition– more the theoretical variety.

in reality, i think the more tools that are available, the greater the odds that we will find newer more innovative solutions to the problem of computer illiteracy. so i like to at least be aware of as many of these solutions as possible.

in the past ive been wary of mark zuckerbergs endorsement of code.org, as i am no fan of his. i put that aside and looking into the site and its authors, i am pretty impressed. now that ive tried the site (yes, its drag-and-drop coding) i am more impressed. instead of just playing with logo, you have a hi-res cartoon character trace over a practice line. you have to solve for the shape using code– this is great.

for a look at what im working on, you can see that im doing iterations on instructional materials here: figch0and1.gif (281k, 502 x 7144) and im excited that harel is working on / with her / companys own solution at globaloria (and i still think its worth mentioning this in the article criticizing code.org.) but i havent tried it out yet.

like harel, i am personally a fan of helping people write code, vs. drag-and-drop. but i dont think this is right vs. “all wrong” like she describes, there are definitely pros and cons of both concepts.

in the days of basic, dijkstra claimed basic was all wrong, even damaging, while others simply made basic work better. but its difficult to impress me with elitism as ive heard it all before. (n.b.: someone compared my language to pascal the other day. i was very flattered– niklaus wirth is awesome.)

naturally im fascinated with concepts that bridge writing and drag-and-drop, such as greenfoots frames concept: http://www.greenfoot.org/frames/ but since im allergic to java, i can only hat-tip the innovation.

but the best part of reading harels article was this reply to her twitter account:

Provocative, interesting post from our friend @Idit. http://goo.gl/P6ew9E Codesters combines ease of blocks w/ access to actual code.

the video on their site: https://www.codesters.com/ is worth a look. buttons on the left, drag to the code window and it drops code in you can then customize. best idea ever? couldnt tell you. exciting though? absolutely, i like it!

(full disclosure: as a teaching tool / demo, i once made a buggy javascript-based calculator interface that did one keyword (with parameters) at a time, to show what was and wasnt a valid line. the one at codesters is a proper editor, and actually works!)

im not the sort of person that gets drawn in by every shiny new thing. for one, im typing this on an old netbook; almost no one i know uses those anymore. (it was already used when i got it.)

but just like we have more reliable software/design when it is informed by knowledge of the past, we can get good ideas by taking inspiration from the “future”– even when its a hypothetical future, even when a lot of it is hype, and even when most of it is a fad. clearly, part of it is really working and that counts.

i love, i will defend, time-tested concepts. but i dont think all good design ideas are behind us, either. stay open to the next good idea; maybe you can use it as a part of your good/reliable, more old-fashioned solutions.

happy coding!

 

 

variables in fig

this is part 1 of an introductory series on fig programming. for the introduction to the series, go here. for the next part in the series, go here.

 

part 1: variables in fig

 

to fully appreciate the power and feel of coding, you must write or at least “run” code. you can get a glimpse of this from watching someone else run code, but you will not experience the confidence or joy of being able to tell the computer something and have it do what you say unless you actually do it.

one of the goals of fig is to avoid “formulas” by default. in fact you can create all kinds of formulas using fig, and if it feels too limiting you can add python code inline to a fig program. python allows full formulaic expressions if you want them.

by allowing this kind of extension, fig is both friendly and powerful. in fact you could simply start with python if you had the interest in doing so, but fig will provide a number of friendly shortcuts that allow you to quickly progress without getting slowed down by too many implementation details.

variables are one of the most universal aspects of programming, and fig requires you to either use python or at least one variable to create a “Hello, world” program.

a few keywords in fig are designed to stand alone, but in general most lines of fig code begins with a name supplied by the user. you can use a letter, like z or the word Now (fig is not case-sensitive, so Now and now and NOW refer to the same variable) but this “main variable” is a feature of fig that often saves you the trouble of referring to it several times in the same line.

fig is designed to be read left-to-right, and does not use parentheses… at least they do not have importance in syntax; they’re decorative, and strictly for the user to decide where they’re needed. in fig, our line begins with a variable. for the moment, let’s just use “now”:

now "Hello, world!"

in basic, this would be now$ = "Hello, world!" and in python it would be the same, except without the $ after the word “now”.

in fig this creates (or resets) a variable named now — which also gets set to a numeric value of zero (0.)

the next part of the line changes the value from 0 to a “string” of characters in quotes, in this case the phrase "Hello, world!" so far, nothing visible is done with this information. the program sets the value of a single variable, and does nothing else. but it goes left-to-right very clearly:

  • the first bit of text names and creates a variable.
  • the second bit of text changes the information (the value) that is stored by the variable.
  • the next thing we add to the line will probably do something with that variable, too.
now "Hello, world!"  print

okay, so now we’ve added the print command. so our variable now is output (“printed”) to the screen.

you could do other things with the now variable; you could make its contents all upper-case, before or after it prints, using the ucasecommand:

now "Hello, world!"  print  ucase

this changes the value to upper case, but (going left to right) it prints before that happens, so no change is yet visible. this:

now "Hello, world!"  ucase  print

…changes the value before using print so you can see the change in the output. order matters; and the order starts at the left and goes straight onward.

fig is different than many languages in that the most obvious or typical example (Hello, world) is usually made purely of output statements likeprint. but in fig, you begin with variables right away.

this is primarily done for friendliness, but it also means that your first program will likely contain 2 of the 7 core concepts, (variables and output) instead of just output.

although this is functionally similar to a formula, i think it’s a better introduction to what programming is really about. fig doesnt actually avoid the functionality of a formula, but the parenthetical way of doing one that makes it “too much like math” to the math-phobic. it is still mathematical in nature, but closer to natural or spoken language in structure.

copying variables is much like setting them:

if you want to copy the value of the variable now into say, another:

now "Hello, world!" ucase
another now

now still contains the string "Hello, world!" but so does another, and you can use/change each variable independently. you could also use one variable as a backup, to compare the two later to see if the other has changed.

each of the two lines above start with a “main variable” and the program code on each line works with the variable on the far left:

  • putting a value after the main variable (this is optional) will set it.
  • putting another variable (also optional) after the main variable will copy its value into the main variable.
  • some commands will read or use, but not change the main variable; print is an example.
  • some commands will write or change the main variable, but not read it.
  • some commands will read and change the main variable– ucase is such an example.
  • some commands such as cls, will not read or change the main variable. cls simply clears the screen.

most commands in fig share a line / begin a line with a main variable, which is not optional. when a new version of fig gains a feature, it is generally a “shared-line” command, or not a program keyword at all. (for example, the help system in fig is not a keyword in the fig programming language, but it is a feature.)

a few keywords do not share a line; they get their own line and do not require (nor use) a main variable; commands/keywords of this type are very rarely added to fig.

these “own-line” commands are:

graphics / textmode

for / forin

while
break
pass

function
python
fig / next / nextin / wend

iftrue / ifequal / ifmore / ifless / else

try / except / resume

these commands are so important, they get their own line– if only to stand out as part of a command block (a multi-line series of commands) or as a command that significantly changes the behavior or mode of the program.

all other commands require a line that starts with a main variable:

now  cls  # cls is a command, now is main var

in the above example, # is a special case– it tells fig to ignore the rest of the line so that it can be used to “comment” the program. technically# is a command or keyword, but it can be on a shared-line with a main variable, or begin a line, or be on a line by itself.

however, it also isnt really part of the program; it just begins a note inside the program code.

if you put a # in front of a line of working code, it will turn that line into a comment and thus disable the line or stop it from running as part of the program. this can be useful for testing the functionality of a single line or group of lines, and using it this way is called “commenting out” a line.

what else can be said about variables? so far, we have only demonstrated keywords that work without any additional details in the way they are written: most keywords, like cls and print and ucase are simply tacked on to the rest of a line, at the right of the line. the program goes from left to right, and then to the next line.

as mentioned, there are keywords which go on their own line, such as textmode or while, and do not share a line with a “main variable” to start, or with other commands. but we haven’t talked about parameters yet.

apart from the start of a line, or the second “word” in a line (where it is used to copy one variable’s value into another) the place you are most likely to see a variable is as the parameter for a command that has them.

most fig commands have zero parameters, or one parameter. a few have more than one, but each command has the same (fixed) number of parameters in every context, except for function (used to define new fig commands.)

therefore cls always has zero parameters; while always has zero parameters; ucase always has zero parameters, and textmode always has zero parameters.

the keywords left and right always have a single parameter; it defines how many characters you want to keep from one side of a string.

to demonstrate:

now "hello"    print    left 2    print 

first now is created, set to "hello", then printed, then left 2 is run before the result is printed again. the output is:

hello
he 

we’ve used four spaces to separate each command, though one space is sufficient.

the left command includes 2 as a parameter, as the number of characters to take from the side of the string that’s stored in the main variable. it then changes the main variable to the leftmost 2 characters.

since print is called before and after left 2 runs, it displays the value of now before and after as well.

like most commands that have parameters, left does not have to use a “constant” value like 2, but can use a variable instead:

howmany 2
now "hello"    print    left howmany    print

using variables as parameters allows the program to have more control at run-time (it allows it to be more flexible and powerful) and is somewhat the essence of things being “programmable.” it allows the program to take input and have it affect the output, even before we get into conditionals.

as mentioned, the extra spaces are optional command separators (purely for the visual aspect of the code) and each of these lines are valid and do the same thing:

now "hello"    print    left howmany    print
now "hello" print left howmany print
now "hello" : print : left howmany : print
now "hello" ; print ; left howmany ; print

the colon : is the traditional command separator in basic, and in c and python and javascript, a semicolon ; is used.

it is worth talking about variable types (or rather data types, since any variable in fig could hold one or more type of value) but the subject is simple enough that the point of mentioning it might not be obvious:

  • string type: data “in quotes” is a string of characters, which may include numbers but they will not be treated as a numeric value."5" plus "5" returns "55"
  • integer type: an integer, also known as a “whole number,” is a numeric and has no decimal point. 5 plus 5 returns 10
  • float type: numeric and includes a decimal point; allows decimal values. like basic, fig handles floats and integers pretty seamlessly, but strings have to be converted using the val command to be treated as numerics. 5 plus 5.7 returns 10.7
  • array type: while variables hold one value at a time, a variable can be converted to an array holding the same value, plus others.

now 5 arr # create an array holding 5

now 5 arr times 100 # array holds 100 5s

normally the times command is used for basic multiplication, but when used on a string it sticks several copies of that string together into one:

p "hello" times 4 # "hellohellohellohello" 

when you start a line with a main variable that you’ve already used, it sets it to zero:

p  print          # displays 0
p  5  print       # displays 5
p  print          # displays 0 again
p  plus 7  print  # displays 7

arrays are the exception to this rule. since they might hold a lot of information, they do not get cleared on use as a main variable unless you explicitly clear them:

p 5  arr print    # displays [5]
p  print          # displays [5]
p 0  print        # displays 0

5 plus "5" plus 5.0 returns [5, '5', 5.0]

arrays in fig are the same as arrays in python, known in python as “lists.” lists in python (like in fig) are not restricted to a single type per array; they can hold a mix.

apart from converting a variable to array using arr, fig has several ways of creating an array:

  • the split command can split a string into array elements.
  • arropen and arrcurl load the lines of a file or webpage into an array, respectively.
  • arrstdin creates an array from information “piped” in from another program. this allows you to mix the functionality of various programs together, even if they aren’t designed as a group or suite.
  • command creates an array of parameters the fig program was called with. these are not parameters of individual commands, but of the program itself. (this allows you to put together your own “language” from fig programs and others, such as bash utilities.)
  • inline python can be used to create arrays.
  • arrshell runs command line programs, and returns the output of those programs as an array.

why learn computing?

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:

  • variables
  • input
  • output
  • basic math
  • loops
  • conditionals
  • functions (subroutines)

the goal of coding in fig can be simply to be able to write code in fig; however, if you can code in it then it can be a tool for learning more advanced languages like python, or most languages including javascript, bash, php, or even c.

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.

abstraction vs. obstruction: my take

im currently enjoying a conversation between andy mender and myself on the topic of abstractions. based on this, he wrote an excellent post you can read -> here. i will include the first paragraph and encourage you to read the rest:

“A WordPress user, codeinfig, brought my attention to what I was trying to express in my previous blog entry, but somehow failed to name. The patched together arguments I’ve been tossing around recently illustrate a major issue in software design – abstraction vs obstruction. We build abstraction layers to tie together smaller system components (or features) or to provide an easy to use interface for ourselves and others. However, abstraction layers tend to stack ad infinitum, because we all like having our own, right? Unfortunately, handling abstraction layers becomes more and more difficult with each level. Thus, obstruction is born.”

you can find the rest here: https://linuxmender.wordpress.com/2016/05/03/getting-the-job-done-dilemmas/ …as i posted in my comment:

“steve litt hints at motivation being a key factor in whether an abstraction becomes an obstruction. the desire to become a ‘gatekeeper’ is not something i rule out– although like you, i find that there is still quite a lot left when you focus on the more neutral matter of ‘design philosophy.’

in other words, too many abstractions gets in the way regardless of motivations. (and i believe you’re right about transparency and documentation, too.)

in short, i think gatekeeper aspirations will certainly produce unnecessary and opaque abstractions like litt says, but so will shoddy design with benign intentions.

and the user can only withstand so many of these ‘helpers’ stacked like turtles all the way down, before john/joan q. public starts to blame the computer, the developers, the companies that may or may not be to blame.

but cutting through excessive abstractions is the KEY to computer literacy and efficiency– and still so many focus (exclusively) on applications. in my opinion, that is a sure recipe for a helpless (at best, a frustrated) user.” i would add that abstraction is what programming “is all about,” until it is overdone– at which point it goes from being a solution to being a new problem.

 

(my own words following the phrase “as i posted in my comment” are in the public domain, and you are welcome to use or re-use them for any purpose.)