Hello Future of Coding community, I have finally h...
# share-your-work
n
Hello Future of Coding community, I have finally had time to put together a draft of a concept I've had for a few months now - ReadableScript is a very simple 'javascript virtual machine language' that uses assembly-like syntax. Would love any and all feedback, do you think this could be a more accessible style of programming for beginners? Also as it's a "vm" it may be well suited to low-code programming environments. My next milestone goal is to integrate the language into a REPL. Note that this is a very rough draft, you can't even make strings! But the concept should be clear. https://readablescript.com/
f
I hope I'm not bikeshedding if I recommend that you increase the overall text contrast of that page. Especially the red on black in the sample code and output image will be invisible to many people. And if you add
white-space: pre
to your textarea you'll ensure that lines won't wrap.
💓 1
n
Thank you so much for the feedback @Fabian Iwand! I've deployed your suggestions
f
Much better, thanks! 😅
🙌 1
k
Don't the long multi-line and blocks hinder read-aloud-ability? I can imagine listening on the phone and having to periodically ask, "how many quotes is that?" I didn't design https://github.com/akkartik/mu to be read aloud, but now that I think about it, it feels a bit nicer to read aloud since statements really occupy a single line and are therefore constrained to be short. The cost: lots more temporary variable names, so you'd have to ensure they're don't sound too similar to each other. Have you considered creating just a style of JavaScript that is convenient to read aloud?
f
I'm curious if you've given thought to the treatment of camelCase words. For example, in
createElement
do you consider the function to be known to the receiving party so that any ambiguity would be acceptable? Or did you use a specific diction in the past? Dragon NS for example seems to require post editing commands, which doesn't seem like a reasonable workaround for natural language.
(Perhaps all special characters should be aliased to onomatopoeias like "Pow" and "Whoosh" ... 😬)
😁 1
n
@Fabian Iwand I'd almost rather enforce everything be lowercase as far as language keywords go (but symbol names and strings should be able to contain any character)
@Kartik Agaram thanks for calling that out - note that putting many lines on one line with ' is optional, so the following are identical:
Copy code
at foo ' add 40 ' log
and
Copy code
at foo
add 40
log
so you can trade vertical and horizontal space when writing the language I will check out Mu - about to catch a ✈️
The quotes as the start of a block are not optional, however
r
The quotes as semicolons seem to hurt readoutability - you would want that boundary to either be uniform, saying "ret" each time eg, or best yet unnecessary by making statements expressions that are bounded in arity. I keep getting confused by the structure of it as the semantics of the at/call/push paradigm are nearly inside out from the standard ALGOL style procedure call. The simplicity of your approach is very refreshing compared to JS; however, I only wish it could sit under it rather than above it. Ultimately, I think the most "readable" languages look like https://en.wikipedia.org/wiki/HyperTalk or Ruby - quite verbose, though with linguistic affordances carrying a lot of context. We have communication hard-wired into our brains, but inventing languages that take advantage of this is more of an art than a science. The more whoever is learning it knows a different type of language, the more the impedance mismatches between them will trip them up compared to an absolute beginner.
j
Have you read the papers around Applescript? It might be interesting to see how they approached some very similar design constraints.