Skastic: An image-based esoteric programming language

I came across a post on slashdot recently about an esoteric programming language based on ASCII art. (https://developers.slashdot.org/story/17/08/13/2033239/new-asciidots-programming-language-uses-ascii-art-and-python). It's pretty novel and interesting, and in the comments section, people mentioned some related languages with similar characteristics which can be found on esolangs.org. I was intrigued by some other languages which use lines to show control or data flow, some of which are found in a list of two-dimensional languages https://esolangs.org/wiki/Category:Two-dimensional_languages. The overall visual appearance of https://esolangs.org/wiki/Rail is unusual among languages on esolangs.org in that is arguably readable.

This inspired me to dig in again to visual programming languages, a topic I haven't spent much time on in years. Many of the visual languages I am aware of use an IDE wherein programs are made by hooking together some sort of nodes using tools. That is, the visual code is a structured diagram of some sort. Examples of these languages I have some familiarity with include Scratch, Prograph (Marten), Max/MSP, and vvvv. But are there any visual languages that deduce code and data structure using raw images rather than structured diagrams?

A bit of reading through the esoteric language pages (particularly https://esolangs.org/wiki/Category:Non-textual) revealed a handful of examples. Most of them are truly esoteric: e.g. using streams of pixels where the color of a pixel represents some specific operation. In other words, the code is unreadable (see e.g. https://esolangs.org/wiki/ObjectArt). A clever alternative, somewhat closer to what I was looking for, is https://esolangs.org/wiki/Efghij, wherein programs are represented by images of household objects stacked in various ways. It's worth noting that efghij is at present a language design with no implementation.

I've decided to design and implement a new, general purpose, turing-complete, esoteric language wherein programming involves drawing an image. That is, the input to the interpreter/compiler is a bitmap file which can be drawn on paper and scanned in. But what should the language look like, and what kind of programming model should it use?

I decided to make something that might be considered a LISP variant. A LISP program is essentially a textual representation of an abstract syntax tree (AST). Skastic (SKetch AST-IC) is a language where you draw the AST for a program.

You can find it here: https://github.com/mypalmike/skastic

Comments

Post a Comment

Popular posts from this blog

Fixing sound effects issues in LibGDX on Android

Just a forewarning: this is not a definitive explanation for everything that can go wrong with your sound effects in LibGDX - just some information I learned while debugging some issues I ran into. I still have more questions than answers. Sound effects are often one of the last things you will implement in an independent game project. You've got this nearly complete game that just needs some polish in the form of bleeps and bloops. So it can be frustrating when the audio API doesn't work as you expect. In LibGDX, the audio API is quite simple. You load your sounds. You play your sounds. What could go wrong? It turns out that things can go wrong. These are computers, after all, which means they have every intention of causing frustration for developers. In my case, I had 5 sound effects files and a music file. The sound effects files had been made with Logic Pro X and exported ("bounced" in Logic terminology) as mp3 files. I had code like: public cla...
Read more

LibGDX, Preferences, and Android

Another day of coding with LibGDX, another annoying Android issue. This time, it involves a Preferences object. I have a settings menu where the user can adjust things like sound effects volume, etc. There is a single Preferences object that lasts the entire lifetime of the game. In the settings menu, I read from and write to this object. And obviously I read the values elsewhere for the settings to take effect. A Preferences object is a simple key/value store with a "flush" method for persistence. Great, I figure. I can write to this thing, read from it, and persist it when needed. So, my approach to the settings menu is for the widget callback to write values to the persistence object. I.e., when a slider is slid, the callback grabs the new value of the slider. It then assigns this value to the relevant key in the preferences object. Then, any runtime state that needs realtime updating (e.g. music volume) can pick up these changes in their normal processing by reading t...
Read more