which language should i use?
code your own language | [[design-your-own-distro]] | [[dictionary-of-programming-concepts]] | [[build-your-own-freedom-lab]] | [[free-media-alliance-best-practices]] | [[quasi]] | which-language-should-i-use
list of entries
- python, python 2
introyes, the headings arent right. i intend to fix them.
its a question so many people ask. its the wrong question; the best language to use is the right tool for the job. but thats oversimplifying it a bit.
if the language implementation youre using is non-free, or otherwise problematic, due to being part of a campaign to destroy software freedom, then those are valid reasons to narrow down the list.
if youre trying to learn, then a language youre less proficient at makes sense. if youre being paid to use it, thats certainly an argument that doesnt need to be made-- though it could affect who you choose to work for.
the industry of course, will tell you to use the languages the industry likes. other people will point out that all languages are fundamentally the same. thats mostly true, but the point of having different languages is that they have different strengths.
articles like this are extremely common. the motivation was a friends comment on my latest project, called [[quasi]]:
back to list
logowe have a few languages to cover here, so lets talk about logo first. what on earth would you use logo for? its a toy language. logo is ooooooooold.
you probably wouldnt create any applications with logo, its true. logo is part of a philosophy of teaching, and its designed to make technology, computing and learning more accessible. today, when people are saying that "everybody should learn to code" (not necessarily for work, but for modern literacy) logo was half a century ahead of its time. it did the job that many teachers argue cant be done.
logo was arguably the most popular of a handful of educational languages developed in the 1960s. because it is in some ways a more practical language than logo, basic has a stronger reputation as a 20th-century educational language. but it was the philosophy behind logo, as applied to the olpc project and the sugar computing platform, which led me to learn a more "modern" language like python.
people who think logo isnt the most popular educational language simply dont know where to look. apart from relatively conventional implementations such as librelogo, which can be used in libreoffice, logos simplicity in teaching has morphed into popular teaching, development and gaming environments such as scratch, lego mindstorms, sugar, turtleart, appdeveloper and minetest.
logo has always demonstrated a connection between programming and automation, and from the early days was implemented either using a cursor on the screen or an actual robot holding a pen. so the reason you would use logo is simply "to teach, to learn, to create computer literacy." yes, you can do that with python as well. but logo has a strong legacy, it is more accessible to younger students than any other language, and it is arguably as popular now as it ever was.
the lack of standard dialect in logo is a strength-- usually a standard is considered a good idea. the various languages i consider descendants (at least cousins) of logo, might not exist if logo were a standard. you can create a derivative language with words in plain english and python-like syntax:
move.up(5); move.right(10); pen.colour("blue")
or you can create a logo dialect that is simple to parse, such as the one i implemented in bash:
u5 c 5 r d 10
"move up 5 spaces, change colour to magenta, move down and right 10 spaces."
not only can anybody learn logo, but you dont even need a computer to teach it. you can (and people have) created simon-says-like playing cards that let people try logo with a person (maybe the teacher) volunteering to be the robot. you can have the volunteer walk around the room, or draw on graph paper with a real pen. this is kindergarten-level programming. we could have a more computer literate society if every classroom had an activity like this.
back to list
bashbash is one of the most popular shell languages of all time. it has a tedious, brittle and unforgiving syntax; a space in the wrong place can make difference in far more ways than in most languages. there are countless ways in which string formatting can go unexpectedly wrong, and switching from bash to a language designed for complex tasks can be an incredible relief.
with that said, bash is a nearly ubiquitous shell language, the tools that include its "commands" (actually separate programs) are part of the first operating system designed to be completely free-as-in-freedom, and it integrates extremely well (and quite easily) with tools designed by different people during different decades.
bash makes it trivial to do simple tasks elegantly, and its a small group of tools. it is basically the ultimate swiss army knife of computing, and many people consider it the closest thing to a programming language that they know how to use.
i really hate using bash for creating long, complex scripts. that doesnt mean that bash isnt important-- the longest program i ever created in my own language (fig) is actually about 50% bash, why? because that 50% was easier to do with bash, but my own language made it more trivial to "glue it together" into a complex program. in fig, all you have to do to run bash code is:
variablename "echo $(seq 1 5)" shell
this part: *echo $(seq 1 5)* is pure bash code. if you want to dump the shell output to an array:
variablename "echo $(seq 1 5)" arrshell
this lets the fig program work with the output or save it for later.
but bash is a great environment for running programs and connecting them together. you can do that natively in other languages, but they dont make it nearly as easy as bash does.
back to list
python, python 2i spent decades coding before i learned python, and it does a lot of things that i had always hoped would become features of the language i used for coding on a regular basis.
in so many ways, python is the perfect language i imagined. okay, its not actually perfect. in fact i wasnt planning to paint it in such a favourable light as that.
but it is a good teaching language, it has found its place serving many purposes that once were served by other languages, from perl to basic to (in some instances) even scheme. which doesnt mean its a suitable replacement for scheme in most ways, only that mit was using scheme for an introduction to programming, and python now takes its place.
i dont like the direction python is going in, ive spent many years listening to know-it-alls tell me i should just use c++ (fine language, not the tool i need) or even c (very important, very powerful, but not the tool i need) or java (no, thank you! for so many reasons) and the arguments for the latest python are familiar sentiments.
im not obligated to use a tool that doesnt suit my purposes. ive spent many years learning and i still enjoy new things-- when theyre a good fit. python is no longer a good fit.
python 2 on the other hand, is a great language. ive watched people attack it, ive watched people pretend that i will have no other options come january (screw you, pythonclock, its january now) and i consider that nothing but corporate propaganda.
people have explained why python strings are broken-- there was no need to break them, not only is python 2 friendlier (much friendlier to learn and use overall) but i actually created a new python version of fig and used it for half a year before going back to creating python 2 versions of it. python 2 is better and more reliable. i also knew a former nokia developer that still preferred it over the new python.
the python foundation was originally going to axe python 2 in 2015, i believe. then they moved it to january 2020. then they moved it to april. this is very nice for google and microsoft, who respectively have hired pythons creator and have taken over pycon, but it does nothing for me.
for me, pypy is a suitable replacement for python 2 and cpython. i will continue to use cpython for as long as it makes sense, then i will replace the string that points to *[lit]/[lit]usr[lit]/[lit]bin[lit]/[lit]env python2* with *[lit]/[lit]usr[lit]/[lit]bin[lit]/[lit]env pypy* and the python foundation can slither along whatever stupid path it wants.
theyve sold out and the result is an inferior product for many of us-- but corporations and corporate fanboys are happy with it. heck, there are people that think windows is suitable for "enterprise" and that says it all.
whatever. its still a joy to use python 2 and ive used pypy enough to know it works really well. the one thing i would "change" about python doesnt really need to be changed-- it can all be done with libraries and other languages based on python, such as fig.
back to list
figfig is based on a language i created called "nudity." nudity was designed strictly as a fun experiment, inspired by the star trek computers.
it seems to me that when people talk to the star trek computers, they are giving commands similar to bash commands "lights" (meaning set lights to preferred level per whatever parameters are implied by the persons voice print, the time of day, etc.) or even sql queries or search engine queries.
to the best of my knowledge we are never shown how holodeck programs are created, though we are shown that certain elements can be dropped into place simply by describing them. this suggests the holodeck is a voice-activated rapid application development tool.
i wanted to create a language familiar to early 21st century coders that could be entirely spoken, so it was as light as possible on any punctuation in syntax. it was called nudity because of the "stripped down" or even logo-like syntax the commands used.
at the time, i was involved with the qbasic[lit]/[lit]qb64 community, and the logo for nudity (a fig leaf) was designed by bob seguin-- the same person who created the logo for qb64. he agreed to make the fig leaf logo public domain, and i modified it to suit my needs.
nudity was a fun experiment, though one i grew bored with. id created simple, silly toy languages before. i didnt want bobs logo to go to waste, and i thought id try converting nudity into a program slightly more inspired by basic and logo programming, still very stripped down, and i would call it "fig basic."
it was suggested i drop "basic" from the name, since it was far enough conceptually from basic itself, and from then on it was called "fig."
fig is the first language ive created that ive used for years-- ive even created other languages based on it, and figplus extends it further (ive deliberately kept fig down to under 100 commands. this is a feature.
in the 80s, sometimes, you could master an entire dialect in less than a year. i wanted that to be possible and practical with fig.) its the first multi-purpose language ive created that really helps my workflow.
things that are possible with python are often easier with fig. of course fig focuses on the python tasks i need the most-- one of the first features i created was support for inline python. this means you can create a function that contains only python code, in a fig program, and then call it like (practically) any other fig function.
the only thing native fig functions can do that user-defined functions cant is use the implied parameter:
[fig]p = "this is a string" ; print # the print command uses the
# first variable on the line
p = "this is a string" ; userprint p # for user functions, all
# parameters are explicit
note that = and ; are optional syntax, added only for clarity to the reader-- the parser ignores them. if youre a fan of wirth, you could use := instead of the = sign for assignment.
fig is easier to teach than python, which is one of its primary features. it is a fun educational language. but unlike logo, i use it for real everyday computing tasks.
fig (through 2.x and again from 4.x onward-- the latest is 4.6 from 2017, its very stable) works with python 2 and pypy. i dont maintain the 3.x versions of fig that work with the latest versions of cpython, because im not interested in those. after half a year of use, i realised those versions were less reliable for my purposes and i stopped using them.
back to list
*create a button.*
*now create a textbox.*
*now make it so that when you click the button, it adds to or modifies text in the textbox.*
there is an alternative, of course. i could use forms and a cgi interface (sorry randall, /pin number/) to python. dont think i havent tried it before; ive done that several times for fun. the first day i worked on quasi (that was this week) i really considered having quasi connect to a python cgi server. of course the obvious issue there is that anybody who wants to use it then has to install a server-- or accept that someone else controls it.
if i decide to take quasi in a different direction so it can accomplish whatever im trying to do, it will probably be easier to do that based on what im developing now-- the features im building into quasi would most likely serve that purpose.
just as modular features in other designs can be repurposed to do entirely new things, im pretty confident that if quasi doesnt go how i want, and im still interested in trying a different design, i can still use a lot of the code for it so far.
but so was fig, only there were fewer compromises because python is simply an incredible language to implement a compiler in.
named freewiki.js, this is a single script that reads the contents of span tags, then changes the syntax accordingly. this means that when i create a document like this one, it is trivial to add "markup" that i designed (its also pretty trivial to modify the script so that it can use the markup you prefer) and i find it far preferable to editing html.
this is designed for LARGE amounts of edits on MANY different pages, so a tool to make that more practical is wonderful to have. and it cuts down on a lot of dread that i would have when faced with making regular edits-- thats exactly what a wiki is supposed to do.
before i created freewiki.js, it was in-page-wiki. the code for in-page-wiki was designed to be minimal and included on every page. that way if you download a page, it still has the wiki translator. this is wasteful of bandwidth, but ultimately i decided to add features to it that were impractical at best to put on every page.
for bandwidth saving, as well as a more reasonable design, i decided to upgrade in-page-wiki to a separate file.
if you use the command line to get a page, you will find that the syntax of a freewiki page is more pleasant to read than html, even though i do add small amounts of html to my pages (as freewiki reduces the need, but does not forbid it.)
as for what language you should use-- i recommend you use free (as in freedom) languages, and i recommend you lean away from environments designed to push you around or take over free software (such as mono-- that was apparently created for strategic anti-free-software purposes) and i recommend you start small, choosing the language (among these criteria) that help you do what youre trying to do.
back to list
if you have questions, and you already have a neocities account, ask here: [url]https://neocities.org/site/codeyourownlanguage[url]
if you dont have an account, join neocities here: [url]https://neocities.org/[url] or a forum here: [url]http://softwarefreedom.jcink.net/index.php[url]