If it's not on-topic, it's in here.
Sun Oct 23, 2016 6:36 am
tl;dr:
1. bash for everyday pipelines / one-liners / small looping tasks
2. fig for most things id put in a script
3. inline python for extending fig
4. python itself for heavy duty lifting (usually fig+python is enough)
5. js+browser for complex guis and yad for simple ones (i find js tedious for most other tasks.)
i learned basic over 30 years ago, and used it for over 20 years. i tried over 30 dialects, looking for the "basic of the 21st century" based on ease, fun, flexibility, and actual adoption. (spoiler: its python... specifically python 2.)
i also tried pascal, js, php and lua. over the years ive learned bash. fsr is better with it-- he has to be, i can just use something easier.
i use bash (or the command line) every day. ive written huge scripts, which i find extremely tedious to do in bash-- especially since i know python. for big projects, i use python:
* scope... * better array handling... * sometimes better string handling (i like pipelines.)... * fewer "tricks" needed to do simple things... k=$(($k+1)) is: k += 1 *
sometimes python is faster, too-- or im still doing bash wrong after > 10 years: very possible.
in fig, i talk to the shell a lot: x "find / | grep '\.png'" arrshell # put the output of the command line into an array named x
but whatever processing cant be done easily in a one-liner, i let fig do the rest. id have never gotten as far with mkfigos (its at least 50% bash) without help from fig. the part thats bash, would be at least twice as tedious in fig. the part thats in fig, would be at least twice as tedious in bash-- particularly making certain it works.
bash rarely gives me confidence that it will do exactly what i want unless i try it at virtually every possible step on the way. thats why pipelines are lovely-- you can look at the output after each step, and base the next step on it.
i rarely use python anymore. i rarely need it, and when i do i can just drop it inline into fig. why not just use python? because fig has a lot of shortcuts for the parts of python i find tedious.
python is certainly better for a number of things. after all, it can do literally thousands of things! if you want to create your own language, youll have way more fun using python than something less sophisticated. its incredibly flexible and expressive.
there is one thing i dont like python for at all-- guis. i hate making guis in most languages. the only languages that ive had fun making guis in:
1. tcl/tk (but id rather use js)
2. autoit (for basic stuff)
3. rapidq (its ok)
4. js
in my opinion, javascript is simply ideal for making guis. its too bad you need a browser-- or the like-- to run the gui, but thats a weakness as well as a strength.
havent tried making guis in haxe yet. i have tried it in python, with tk and gtk.
oh, and yad! most of the things id want to bother making a gui for, id just use yad instead. and i can probably do that in python, fig or bash, but ive only used it from bash so far.
Sun Oct 23, 2016 1:43 pm
I know there is a giant gif for fig documentation in Refracta but is there another source to learn it? I did some searching online but couldn't find anything. I'm hoping that a huge image is not the only information available.
Mon Oct 24, 2016 1:17 am
Where do you see a huge image for fig? It's 48x48, but it looks small to me in the menu. Do I need to make a smaller one?
Mon Oct 24, 2016 1:55 am
Oh, I meant when you click on the fig menu item it opens a giant gif in the browser.
Mon Oct 24, 2016 7:43 am
all the docs (and examples) are in /usr/share/doc/fig ...i never thought to make menu entries (i wasnt sure docs would even be included) -- fsmithred took care of those.
under ./workinprogress theres a pdf called ten-chapter something.pdf which is actually a pretty complete book. id definitely skip the intro (i wrote it with one person in mind, it badly needs to be shortened) but chapter 1 will walk you through the language.
the gif was also made with one person (a different one) in mind-- someone who complained they dont like long form. i dont blame them, though i think its pretty good from chapter 1 onward. at 8.5x11 (american letter size) its only about 43 pages. theyre numbered by half-page, the plan was to reorder the pages and print at 5.5x8.5.
if you apt-get install python-pygame you get better graphics, but if you dont it will still emulate graphics in the term window. for fig3.1, ive used it with pygame, but dont get me started on what its like to get pygame working on python3 in recent versions of debian. it used to be in experimental, then deb-src only, theyve done a good job of screwing it up.
there are only graphics commands for pset and line-- if you want a circle, this can be used under any license you want:
- Code:
#### license: creative commons cc0 1.0 (public domain)
#### http://creativecommons.org/publicdomain/zero/1.0/
function circle x y r c
cr r int plus 1
p -3.14159
try
rcpr 1 divby r
except
rcpr .005
resume
while
now p plus rcpr swap now p
ifmore p 3.14159
break
fig
cosx p cos times cr plus x int
siny p sin times cr plus y int
now pset cosx siny c
wend
fig
now display
while
x randint 1 800
y randint 1 600
r randint 1 500
c randint 1 15
now circle x y r c display sleep .02
wend