Welcome
Welcome to refracta

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. In addition, registered members also see less advertisements. Registration is fast, simple, and absolutely free, so please, join our community today!

fig vs python (very quick chapter 8 of fig book)

If it's not on-topic, it's in here.

fig vs python (very quick chapter 8 of fig book)

Postby figlfdev » Sat Oct 22, 2016 1:42 am

As far as coding goes, you can write pretty much anything in fig you want to. It may not be the fastest language, or have a feature for everything, but you can extend it using Python.

Python is a great second language to learn, and is still probably easier than Javascript (although Javascript will run in your browser.)

If you have no interest in Python yet, you don't actually need this chapter. Think of it as "extra credit,” but definitely don't worry if Python seems too complicated.

A few months of coding in any language should make learning Python easier, and there are better intros to the language than this one; this one is just made for people comfortable with fig.

If this chapter only started with what makes Python different than fig, you might think Python is either pure genius (it basically is) or that it makes things more difficult than necessary (it sometimes does.)

Python is a little closer to what you should expect from most languages than fig is. Fig was designed specifically to round off (some might even say cut) as many corners as possible. Today, most languages are case-sensitive, Python has to be indented just so, and while fig
has a "main variable” at the beginning of most lines, Python requires that you at least set every variable to something before you can reference it.

Fig COULD automatically return 0 for any variable referenced, even if not used already. Since most modern languages don't do this (and even have a good argument against it) Fig uses its main variable concept instead, which has the following features:

* It makes it obvious what variables are used in a
program

* It zeroes unused variables in a way that is less
work than Python, but relatively compatible with
most modern languages-- it is minimalist yet still
explicit.

* It works like a "named pipe,” (a concept in Unix-
like operating systems) where a number of built-in
functions can reference and change the contents of
a stream of data implicitly:

Code: Select all
x arropen "file.txt" | join x " " | ucase | print


works kind of like this command in GNU/Linux:

Code: Select all
x=$(cat file.txt | sed 's/\n/\ /g' | tr a-z A-Z) ; echo $x


The pipes: | in fig don't change the way that fig works, they are simply a substitute command separator for Python's ";" or Basic's ":".

Fig is therefore also a simple (sort of) introduction to coding in Bash. Although it barely
is the case, the main variable functionality does transition a little to using pipes in Bash.
Last edited by figlfdev on Sat Oct 22, 2016 10:05 am, edited 1 time in total.
figlfdev
 
Posts: 116
Joined: Tue May 31, 2016 6:23 pm

Re: fig vs python (very quick chapter 8 of fig book)

Postby figlfdev » Sat Oct 22, 2016 1:49 am

But getting back to Python, you must name (and set) a variable before you can reference (or use) it:

Code: Select all
x = 0 ; print(x) # Python uses hashes for comments


because fig allows a certain amount of decorative punctuation, this will work in fig:

Code: Select all
x = 0 ; print   # fig uses hashes for comments too


but the x after print is implied. In Python, the semicolon ; between commands and the equals = between variable name and value are required. And of course, every function, like print(), requires the variable to be named.

Code: Select all
x = 0 ; print (x) ; print (x) # Python

x   0   print       print       # fig


another thing worth mentioning about Python is that it comes in two major versions: 2 and 3, which are both still in use. A lot of professionals still prefer Python 2, as do I; fig was conceived as a Python 2 project, and I would love to make fig a project for Python 2 in the long run.

Fig from version 3.0 onward runs in Python 3. More about this momentarily.

In some ways, Python 2 is more friendly and flexible. The biggest difference is string handling, and the print command. In Python 2, print works like this:

Code: Select all
print x
print x,
print x, y, z


In Python 3, print works like this:

Code: Select all
print(x)
print(x, end=' ')
print(x, y, z)


Ok, so what's the big deal then? Well it doesn't stop there, if you want to save or load a file, or print certain characters, or read from stdin-- all stuff Python 2 makes trivial that's more of a hassle in Python 3.


Fig would still be a Python 2 project, except the Python Foundation was supposed to drop support for it in 2015, and has only extended it to 2020. I still hope that the many people who prefer 2 will fork the language, perhaps calling it "boa" or something.

At that point, I would most likely change fig back to Python 2 (because transitioning is a feature, and I think 2 is better for education.) But in the meantime, fig 3.0 onward is a Python 3 project. If someone is interested enough in Python 2.9 (or earlier) to fork or maintain it, they should feel (they are) free to do so; I would encourage it.

Fig was made with the hopes that more people would understand and even write programming languages, and a programming language made from (any version of) fig would be a very cool thing to find.

I'm focused on Python 3-- reluctantly-- because it may really be the version of Python we are all stuck with sooner or later. It's too bad. [Keep me posted on pypy, especially if you get pygame working.]

Anyway, a fig program that works in 2.9 will probably work the same in fig 3.x, but eventually fig may have features (command is one) that aren't available in 2.9.


As for inline Python, the version of fig (2 vs. 3) is also the version of Python you must use. So fig 3.1 requires inline Python 3 syntax.


One of the largest differences between fig and Python is indentation. A lot of my fig examples I indent "Python-style" but in Python, you must indent each block of code: and you must unindent at the end of it. So this for loop in fig:

Code: Select all
for x (1 10 2)
    now x print
    next


corresponds to the following loop in Python:

Code: Select all
for x in range(1, 10 + 1, 2):
    now = x ; print(now)


There's no "next" in Python; the change in indentation is how it knows!

Nested loops in fig and Python:

Code: Select all
for y (1 5 1)

    for x (1 10 2)
        now x prints " " prints
        now y print
        next

    next


Code: Select all
for y in range(1, 5 + 1, 1):

    for x in range(1, 10 + 1, 2):
        now = x ; print(now, end=' ')
        now = y ; print(now)
Last edited by figlfdev on Sat Oct 22, 2016 10:07 am, edited 1 time in total.
figlfdev
 
Posts: 116
Joined: Tue May 31, 2016 6:23 pm

Re: fig vs python (very quick chapter 8 of fig book)

Postby figlfdev » Sat Oct 22, 2016 2:10 am

In Python, some functions are built in (like int()
and print() and join() for example) while others
have to be imported:

Code: Select all
x 3.14  cos  print  # fig

from math import cos ; print cos(3.14) # Python


Just like defining a function, you only have to
import cos once per program to use it as many times
as you like. Another way to do the same thing:

Code: Select all
import math ; print math.cos(3.14)


The advantage of doing it that way is that it
imports the entire math library at once, so you
don't have to keep importing each of its commands
individually.

Code: Select all
from sys import stdin
for p in stdin: ps += [p[:-1]]
return ps[:]


This is where fig's arrstdin comes from.

Fig's function is named for the Basic command, but:

def replace(phrase, chfrom, chto):
____phrase = phrase.split(chfrom)
____return chto.join(phrase)

in Python, function is called def.


Note also that join x y becomes y.join(x) and split
x y
becomes x.split(y) ...but in python you can do
this to replace text strings, which is easier:

Code: Select all
phrase = phrase.replace(x, y)


Block commands aside, most functions in fig start with def figcommandname in fig's Python source. So
in the fig translator itself:

Code: Select all
def figint(p): return int(p)


is the code in Python that performs int in fig.
Sometimes the translation is that simple, and
sometimes it isn't. From inline Python in fig:

Code: Select all
x 12.5
python
    figcolortext(0, 1) ; fighighlight(0, 7)
    # fig's int function:
    print(figint(x) * 10)
fig


So not only can you use inline Python, you can use
fig functions (some of them) inside inline Python.

When all of it is inline Python, you can copy the
fig functions and use them in a pure Python script.
figlfdev
 
Posts: 116
Joined: Tue May 31, 2016 6:23 pm

Re: fig vs python (very quick chapter 8 of fig book)

Postby golinux » Sat Oct 22, 2016 2:58 am

Didn't you notice that you copied formatted text with line breaks? Very hard to read with all those choppy little pieces. So I'll just move on (it gives me the perfect excuse) . . . ;)
May the FORK be with you!
User avatar
golinux
 
Posts: 661
Joined: Thu Nov 08, 2012 1:23 am

Re: fig vs python (very quick chapter 8 of fig book)

Postby figlfdev » Sat Oct 22, 2016 10:12 am

golinux wrote:Didn't you notice that you copied formatted text with line breaks? Very hard to read with all those choppy little pieces.


yes, it is. i was aware of the line breaks, but i had a larger screen connected (to a netbook) and it looked like the linebreaks were actually a courtesy. back on the smaller, default screen i can tell what youre complaining about.

it should be fixed now.

So I'll just move on (it gives me the perfect excuse) . . . ;)


i dont follow what made you open the topic in the first place-- weve talked about it in the past, i already know youre uninterested-- no excuse is required. its mostly here for fsr, and if someone comes over from distrowatch.
figlfdev
 
Posts: 116
Joined: Tue May 31, 2016 6:23 pm

Re: fig vs python (very quick chapter 8 of fig book)

Postby golinux » Sat Oct 22, 2016 1:52 pm

figlfdev wrote:
golinux wrote:Didn't you notice that you copied formatted text with line breaks? Very hard to read with all those choppy little pieces.

yes, it is. i was aware of the line breaks, but i had a larger screen connected (to a netbook) and it looked like the linebreaks were actually a courtesy. back on the smaller, default screen i can tell what youre complaining about.

it should be fixed now.

And so it is. Much better. :)
figlfdev wrote:
So I'll just move on (it gives me the perfect excuse) . . . ;)

figlfdev wrote:i dont follow what made you open the topic in the first place-- weve talked about it in the past, i already know youre uninterested-- no excuse is required. its mostly here for fsr, and if someone comes over from distrowatch.

You never know when a certain madness might overtake me. ;)
May the FORK be with you!
User avatar
golinux
 
Posts: 661
Joined: Thu Nov 08, 2012 1:23 am

Re: fig vs python (very quick chapter 8 of fig book)

Postby figlfdev » Sat Oct 22, 2016 8:09 pm

my advice to people is to really just take it one thing at a time.

everyone wants to go through a door-- its easy when you know how. you have to reach-- then grasp-- then turn-- then push. (if that doesnt work, pull instead.)

but reaching and grasping is all you need for the first two steps-- and thats easy even if youve never done it. its just like picking something up.

for hello world you have to create the variable, then set the variable, then print it:

1. x # variable is created
2. x "hello world" # variable is set
3. x "hello world" print # variable is "printed" (no teletype, so it goes to the screen.)


it goes left to right, so if you want (before you print,) you can change the color to yellow with "colortext 14" or change to uppercase with "ucase"

x ; "hello world" ; colortext 14 ; print
x ; "hello world" ; ucase ; print


or both:

x ; "hello world" ; colortext 14 ; ucase ; print


what if you want it to say something else?

x ; "what is your name? " ; prints ; lineinput
y ; "hello, " ; plus x ; colortext 14 ; ucase ; print


or if you prefer portuguese (long story):

x ; "qual é o seu nome? " ; impressha ; linhaentra
y ; "olá, " ; mais x ; cortexto 14 ; maicula ; impress # sem, é "impressão"


semicolons are optional / for organizing text:

x ; "hello world" ; colortext 14 ; ucase ; print # fine

x "hello world" colortext 14 ucase print # still fine


no matter how you get directions, you do each step based on the previous one. then its easy.

with computers, people are only happy if they do everything in one step. thats not how you do graphics though-- i started learning computers with the 1980s version of mspaint.

when i started learning, it did help to take stuff that already worked and change it-- take it apart, as it were, to see how it works.

change the strings, change the 14 to 10 to make it green, or to 5 to make it purple.

if youre using refracta (or devuan, both have xfce) then you can change the 16-color palette on your side, in the term window (menu > edit > preferences.)
figlfdev
 
Posts: 116
Joined: Tue May 31, 2016 6:23 pm


Return to General Nonsense

Who is online

Users browsing this forum: No registered users and 0 guests

suspicion-preferred