This looks like a perfect skeleton for bringing Minecraft redstone to an ascii game like Dwarf Fortress. Very cool! Especially if you could design "sub-circuits" by zooming in, sort of like the chips in Robot Oddysey[0] or in the super circuit maker mod for Minecraft[1].
That's really interesting. I will look into that.
Right now, subcircuits are created by using "libraries" to define custom characters (typically letters).
This reminds me of befunge[1], which is also a two dimensional programming language, and has been around for quite a while. This language looks a bit simpler and easier to understand, though. Neat.
"[I]n Befunge, there is no comment syntax: to embed documentation in the code, the programmer simply routes the control flow around the 'comment' area, so that the text in that area is never executed"
I'd argue that Befunge is far simpler. It's yet-another-esoteric-programming-language but the program pointer can move in 4 directions instead of 2. Every instruction is simple stack/heap manipulation or IO. AsciiDots looks a lot more complicated, multiple program pointers which are also the variables in the program with no concept of stack or heap. Not to mention library support, too.
Suggestion: if you want it to be more "inspired by circuits", remove this feature:
+ is the crossing of paths (they do not interact)
That's not how the real world works. Instead, make a feature where source file names can include metadata declaring which layer in your printed circuit board they describe, and add a way to drill holes in all layers (lowercase 'o'?)
That also will allow you to make the front layer contain nothing but outputs, so that one could, for example, write a program that mimics pong or a digital clock (or basically everything)
That also can make you get rid of warps and that weird "Define warps at the beginning of the file by listing them after a %$" rule.
Also, libraries would simply be additional layer files that can be rotated and translated to their right location. Programs using one would have to provide connectors to that layer in just the right places.
The only comment I have is that the `__main__.py` looks like a bit like spaghetti with ~1200 lines, multiple classes, and scattered global state. Not really a big deal unless you plan on growing the project or using it as a portfolio piece. Also in my opinion the project really is a prime portfolio piece, it shows creativity, polish, and theoretical understanding.
The tragedy is that a data-flow oriented graphical programming language is probably a good idea. LabVIEW is a just a good demonstration of how not to do any of the details.
I mean there is no need for a strongly typed EDITOR that goes and actively looks for transient type errors and then inserts non-transient damage at every site where it finds one.
You basically have arbitrary-arity NOR gates, that are your only way of splitting signals. From it you can make anything from XORs to flip-flops to clock signals to anything you want. I remember him making a very fancy 8-segment display counter (that actually counted up over time) in one version of it back in the day.
Very cool! Unfortunately, I couldn't get this working in Windows. Appears that the curses library is not compatible. Tried Unicurses with the same effect. Running Python 3.62.
Ran it in Ubuntu with no problem. Looking forward to writing some .dot programs. Well done!
Sorry to hear that.
I recently wrote some code to support debugging without curses (both the library and a pun when you are on windows and need it).
It just uses try-catch block to detect if it should go into compatibility mode, so you should be able to use the latest version of the repo without thinking about Curses.
I just gave the online demo a debug view, and your counter is the first code I tried (this is a link to your code on the demo site):
https://goo.gl/edPZdR
Very cool! If you're not already familiar with LabVIEW, you might check it out as there are some very interesting similarities and differences between AsciiDots and LabVIEW. A couple that caught my eye:
- LabVIEW creates loops by enclosing the repeated code in a graphical frame of sorts. That ends up being an elegant way to deal with iteration: An array that flows into a loop turns into individual elements inside the loop (one loop iteration per element) and elements that flow out of a loop stack up into an array. I wonder if something similar might work well in AsciiDots? Or more generally, a way to deal with multi-dimensional data by having dots pile up into an array?
- The way AsciiDots deals with libraries (defining inputs and outputs spatially, i.e. top/right/bottom/left) is very similar to how sub-VIs are created in LabVIEW. The way your operations like addition, subtraction, multiplication, and division take two inputs and wait until both inputs arrive to release the result is reminiscent of LabVIEW, but they way you use horizontal and vertical to mean different things is different and very interesting. Direction is mostly meaningless in LabVIEW, so I love the way that AsciiDots ascribes a meaning to horizontal vs. vertical. Can that idea go even deeper?
- Having the "dot" carry information and have a value (not just be the point of execution) is very consistent with LabVIEW and a difference from some other text-based visual languages.
- LabVIEW "wires" (the connections between things) have different thicknesses and colors to tell the user what datatype they carry. It sounds clunky but ends up giving a lot of readability to LabVIEW programs. Not sure if a similar idea could help make AsciiDots programs more readable...?
- LabVIEW has a "highlight execution" mode that slows the program down and highlights the flow of data; very reminiscent of your animated GIF. More than just a pretty gimmick, it helps debug LabVIEW programs and it'd be a great addition to your "try it online" Heroku app.
- For when arithmetic becomes a spaghetti of symbols, LabVIEW has a "formula node" that lets you type in traditional code in C++, thereby mixing graphical and traditional languages. Maybe an interesting paradigm for AsciiDots?
All in all, AsciiDots seems to have a much lower entry barrier than other text-based graphical languages like befunge. It could even be practical for some things, the same way LabVIEW has an interesting niche in the data acquisition and instrument control world. Maybe it could be used for data analysis, where arrays flow from "open file" to "manipulate data" and "plot results"? Or a very interesting way for children to learn some programming concepts, combining the visual-ness of things like Scratch and Lightbot while still having the kids use a text editor?!
I'll shut up now. Fantastic work! Thank you for sharing it!
[0] http://www.formauri.es/personal/pgimeno/temp/RO/stereorecord...
[1] https://www.reddit.com/r/supercircuitmaker/top/