Coding for fun on a smartphone
Graham Trott
Posted on August 5, 2019
A smartphone, as well as being able to make telephone calls, is also a device for absorbing small units of spare time. Anywhere, any time people have nothing to do, out come the smartphones, which we then peck away at en masse, heads down and generally oblivious to whatever else is going on around us.
A smartphone has all the features of its bigger brother the personal computer, and then some. After all, few computers can make phone calls, act as a torch or show you where you are on the planet down to a few meters. The power of a smartphone is equivalent to that of a laptop computer of maybe 5 years earlier, so it's no slouch in the processing department, but its most notable feature is also its main weakness compared to a computer. Although the screen resolution is frequently better than that of a laptop, using it for text at that resolution is impossible without a magnifying glass.
So one of the hardest things to do on your smartphone is to write and test code. Which is a shame, because programmers also have time to fill; on buses, waiting for the dentist or in the usual social environments where everyone else is peering at Facebook, WhatsApp or Instagram.
I'm not talking about carrying our work wherever we go or cramming essential skills for that interview coming up. Worthy as this may be, we all need a break from time to time, and for some of us that can still be coding, just a coding activity that's a bit less demanding; more fun, even.
What we need at times like this is a coding playground. JSFiddle and CodePen are probably the best-known of these, though the former is rather cumbersome on a phone. However, the problem is not really with the tools; it's with the language. To get anything significant to run in your browser you need to juggle 3 scripts; HTML, CSS and JavaScript, the last of which can get pretty lengthy, especially if you have to keep source lines short to prevent them wrapping on your small screen. (I rule out using landscape as the keyboard ends up taking most of the space.) Your results appear in a fourth window so you're switching back and forth all the time, and you have to be pretty determined (or marooned on a desert island) to continue with the experiment for very long.
At this point, spare a thought for young coders in some less well-endowed parts of the world, where smartphones outnumber PCs many times over. (As a matter of fact, there are plenty of disadvantaged communities in the so-called 'developed West' where this is just as true; it's not a problem that's confined to African and other post-colonial countries.) There's a wealth of potential talent we pay too little attention to encouraging.
It was an attempt to 'scratch my own itch' that originally led me to write a completely browser-based high-level language. I wanted something higher-level than JavaScript, that would let me code an entire web page in a single script, one whose vocabulary and syntax would be rich enough to deal with not just the code but all the markup and styling too, and to me "higher level" means "closer to English". My own native language is the Gold Standard in this respect; I regard it as the pinnacle of human communication and have a mission to train computers to understand at least some dialect where man and machine can meet.
Of course when you write your own programming language no IDE will understand it, so you have to forego the niceties of color-coded editors, autocompletion and so on unless you can do it yourself. This started to look like a deal-breaker, so I went hunting and quickly discovered CodeMirror. After some head-scratching I figured out how to customize it to color-code my scripts and I was back on track again.
So I was now set up to write code for the browser in an expressive language that required no external compiler or build tools and could do everything from basic arithmetic to graphic animation. It goes without saying that I wanted to be able to play with this in my spare time too, writing simple games and simulations or just trying out ideas that would be useful elsewhere.
Somewhere around this point came the idea of building a scripting playground combined with a tutorial and reference manual, and naturally it would have to run on a mobile browser too. Equally naturally, it had to be all written in the same scripting language; if it couldn't handle that then what kind of a pathetic excuse for a language would it be?
Well it didn't take that long really. Maybe it's just the way my brain is wired, but I find I'm most productive when I can take the thoughts that are in my head (I think in English, not JavaScript) and type them with the minimum of translation needed along the way. For me it's the quickest way to get things done. The scripting language allows the job to be shared out among multiple scripts, each of which does its own bit. Typically each one handles a different screen panel so all the main script has to do is call them when they're needed. In fact, it took longer to write the customized ShowDown reference pages that describe every feature of the language than to write the code that drives the IDE.
The project is still ongoing but it's now at the point I feel confident enough to offer it to others, the hope being that feedback will point the way for future enhancements. Maybe some would like to use a mobile-friendly scripting playground, as I do, to soak up some of those tedious minutes after Facebook begins to pall. If you do, let me know what you thought; what you liked (if anything) and what you didn't, and where it should go next.
Thank you for reading. The scripting playground can be found on the Codex button at EasyCoder.
Photo by LinkedIn Sales Navigator on Unsplash
Posted on August 5, 2019
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.