which-language-should-i-use?
=> index.html code your own language
=> dictionary-of-programming-concepts.html dictionary-of-programming-concepts
=> build-your-own-freedom-lab.html build-your-own-freedom-lab
=> quasi.html quasi
-> which-language-should-i-use
intro
which language should i use? 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 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.
most people are going to present their own bias when recommending a language, and im no different. im going to focus on python, python 2, bash, javascript, fig and logo. this may not help you choose a language, but it may illustrate how such choices can be made. if you are no longer interested, heres a good place to quit reading this. no worries.
articles like this are extremely common. the motivation was a friends comment on my latest project, called [[quasi]]:
"I'm surprised you are working with javascript. It's not a highly regarded language..."
funny, i dont like it either. but i noticed that so many people who criticise the use of javascript are doing so on a platform (such as diaspora or facebook) that has loads of it. granted if it were up to me, we would be using javascript-free forums more often. i prefer forums that at least function without it.
the worst forum software ive ever encountered is discourse, a disturbingly popular mess that can only be described as "javascript hell." to be fair, it isnt just the language used that makes it terrible. but there is a loathsome amount of javascript and bloat.
back to top
logo
we 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 top
shell scripts
some shell scripts have 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 in particular to a language designed for complex tasks can be an incredible relief. bash is very popular, but i wish i had learned the shell with ksh instead.
with that said, shell scripts are nearly ubiquitous, the tools that include the "commands" (actually separate programs mostly) were part of the first operating system designed to be completely free-as-in-freedom, and the shell integrates extremely well (and quite easily) with tools designed by different people during different decades.
ksh makes it trivial to do simple tasks elegantly, with a small group of tools. the shell 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 shell scripts for creating long, complex scripts. that doesnt mean the shell isnt important-- the longest program i ever created in my own language (fig) is actually about 50% shell script, why? because that 50% was easier to do that way, 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 shell code is:
variablename "echo $(jot 5 1)" shell
this part: echo $(jot 5 1) is pure shell code. if you want to dump the output to an array:
variablename "echo $(jot 5 1)" arrshell
this lets the fig program work with the output or save it for later.
the shell 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 shell scripts do.
the shell is very good at what it does best-- and in my opinion, a pain to use for whatever it doesnt do best. but it is undeniably useful. incidentally, "very good at what it does best-- and a pain to use for whatever it doesnt do best" is also how i would describe javascript.
back to top
python, python 2
i 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 top
fig
fig is based on a language i 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 shell 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.
at the time, i was involved with the qbasic[lit]/[lit]qb64 community, and the logo for my language (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.
figs predecessor 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 my language into one 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 top
javascript
what do i need javascript for?
there are two applications in particular which i find javascript quite useful for. the first is easy to illustrate:
*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.*
this task is far easier to do in javascript *code* than any other language, really.
i say "javascript *code*" because there are plenty of awkward, tedious (and bloated) gui design tools that dont require you to write the code for their gui controls. but "javascript code" actually uses html to accomplish this, and though im not a huge fan of it, it really makes coding gui stuff less tedious than any other language.
now, the rest of the language is nothing that i love. so many things are a pain in javascript, but that only stops me from wanting to use it for most tasks. on the rare occasion that i care about a gui, javascript calls to me.
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.
i decided to find out how far quasi could get with just javascript. and apart from the gui being fairly easy to create, its quite a challenge. im not nearly as proficient with javascript as python, and im using native features instead of adding a library-- this may cost a lot when it comes to input. im hoping that at least i can use a dialogue for input, but i would much, much rather use the import[lit]/[lit]export "window" of the [[quasi]] interface.
whatever i decide (if anything) to do with quasi, im creating features for now that are implemented only with native javascript features. im content for now if it works with icecat and qupzilla; qupzilla is relatively old and webkit-based.
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.
quasi is thus a simple language experiment, not unlike the one i did with fig basic. since (native) javascript doesnt have identical features to fig or python, its interesting to try to coax this design into something that does what i want.
because im not as proficient with javascript as python, and because javascript makes some tasks so tedious that im not even interested, this is both a learning experience and a series of compromises.
but so was fig, only there were fewer compromises because python is simply an incredible language to implement a compiler in.
thats not to say that ive never created a practical language in javascript before, only it was a simpler language. the wiki that displays this very text is based on a handful of similar projects ive created over the years, to turn wiki-like or markdown-like text into html.
ive done that several times before in python, or python and javascript. but this time i had my reasons for a pure javascript-based wiki. and of all the mini wiki projects i created, this is by far the one that does the most for my workflow.
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.
an alternative is to just have python take input files and turn them into html. you know, ive done that already. the precursor to the website design i use now did exactly that. and despite vastly preferring python to javascript, using freewiki.js simply runs circles around using pzmarkup, in practice. this is about making my own work comfortable.
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.
the best part is this-- freewiki.js reduces the amount of text i use for nearly every page i create, as well as the amount of noise created by html tags. if you load a freewiki page without javascript, the browser will remove most newlines-- but the text is still visible.
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 freewiki is a modest program, it would be trivial to create a freewiki-to-text converter in python, similar to an implementation of freewiki in python instead of javascript. but the point is-- the raw text in each page is cleaner and easier to edit. thats the point of a wiki.
i dont like javascript, but i use it for a few things. since ive already created fig and figplus, and ive already implemented two mini languages in bash, and ive already implemented one useful (albeit simple) language in javascript, it seems reasonable to work on a project like [[quasi]] based on javascript.
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.
i dont love javascript, but i use it sometimes. its not rewarding enough to use it a lot, except for programs like freewiki that i can use in many applications with a minimum of editing javascript code. as with python, whats my favourite thing to make with javascript? other languages.
back to top
[lit]happy coding![lit]