Feedback

[ccorcos]

Hey, I saw your demo on Reddit and I'm really excited to find other people interested in visual programming languages.

First off, I think you might enjoy this curation of visual programming languages. I can see some similarities between what you've built and some things that have been built in the past.

As for your actual design and implementations, what is the actual goal here? why do you want to visualize your code?

Your demo is less concise and arguably harder to understand that the plaintext code example you provided. But perhaps you are intending to visualize something that I'm not aware of. I would think hard about this question because that should dictate and guide your design.

In my own experience with this stuff, I'm most interested in providing a visualization that presents the mental model that I have in my head for how a program works. That's still pretty vague, but it gives me inspiration to think about.

One thing I would consider is creating a declarative representation that inverts the AST and provides more of a flow-based visualization. That is, rather than represent the function add = (x,y) => x + y as a LISP-like syntax tree with inputs at the right and outputs at the left, try inverting it so it reads left to right with inputs on the left and outputs on the right. Max, Audulus, Antimony CAD, and a variety of other programs have a similar concept. The problem I've run into is that things get quite a bit more complicated when you introduce stateful impure functions.

Lastly, I would consider creating a direct manipulation interface where you can interact with the visualization to produce changes to the code. If you use Typescript, you can use their language api so that you can validate manipulations of the interface and surface type errors.

Anyways, thats enough for now. I'm curious to see where this project leads!

Cheers,

Chet

[jones1618]

Your mobile IDE looks very promising. I am a fan of JSAnywhere but its desktop-like text editing is not at all well adapted to mobile devices, especially not small screen phones where text selection with fat fingers is often a nightmare.

Your idea of dividing code into visual "chunks" that also act as convenient touch targets, is a great alternative to that.

Some suggestions for touchPL:

• Add labels, icons or shapes to distinguish boxes and sub-boxes and not by color alone. So, I'd prefer a FOR box that contains four sub-boxes (maybe labelled): "init" containing "var i = 1", "condition" containing "i <= 20", "next" containing "++i".

• Put one statement per line (like "var i = 1") rather than "var i" on one line and "1" on another. For the loop condition, it would be nicer to have one condition expression per line. Not only would It be more compact vertically, it would make each row a single "thought."

• When you get around to expression editing, please make sure that it is possible to put the cursor anywhere, before and after text, brackets, operators, etc.. (In JSAnywhere, you can easily put a cursor after a keyword or brace but it is hard to put it before a keyword or brace.) Also, if you implement a virtual keyboard, please include u/d/l/r cursor keys and a DELETE key (for deleting characters to the right of the cursor.)

Also, if you want further inspiration besides what ccorcos offered, I'd recommend looking at the inline interaction of Explorable Explanations. I'm not quite sure how you could adapt it to a mobile environment but it would be amazing if variables, keywords and values could be modified as easily in your IDE.

[masiulis]

Glad to see someone else working in this space.

I have been working on visual editors and languages for a few years, my last project is close to being opensourced but you can check an older version at ugnis.com.

There are two lessons that I would like to share with you

1.) Having a textual representation and a visual one at the same time makes either of them terrible. Either your code is so declarative that you can't read it, or your editor can basically just move AST nodes, which defeats the purpose of the visual editor, because writing text is the fastest way to move AST nodes.

2.) There is no point in editing code with a mobile phone. If someone is serious about programming, they are more likely to spend a $100 on an old laptop than program on a mobile phone. We came to this conclusion after a lot of user testing for our project.

But don't get discouraged, test your ideas with more people and listen to their needs. In the end you will get somewhere, but don't be surprised if it's not the place where you expected to be. It certainly wasn't for us.

[jones1618]

masiulis, I strongly disagree with "#2 There's no point in editing code with a mobile phone."

A lot of my coding experiments are banged out on my phone while on the train or waiting to pick up my kid after tennis practice, etc. Also, I thought coding on my phone was merely convenient and "cute" until recently a friend's son found out I was a developer and excitedly whipped out his phone to show me Python code running on his Android. Then it dawned on me that kids and teens live on their phones. Now they can code on-the-fly wherever they are and do it without drawing a lot attention to "geeking out" unless they want to.

Besides, mobile coding is an interesting problem to solve. And, if you can paint, compose music and do 2D or 3D technical design on your mobile, why not coding?

[masiulis]

@jones1618 Note that I am talking about developing for 8 hours per day on a device. I held the same views as you did before user testing, but after talking with people, I have changed my mind.

On the other hand, there are so many unexplored opportunities, that I encourage anyone to try and see, maybe they'll get a different result.

[balzss]

Hi,

Thanks everyone for the feedback. Sorry for the lateness of this response but I just picked up the topic again. Lately I've been studying the design of functional languages especially Haskell, Elm and the Lisp family. I think they have a lot of characteristics that make them suit better for a visual adaptation. The main one is the pipe operator from Elm. One of the major flaw with my design is that "flattening" imperative code is tedious. Like @jones1618 mentioned, it's much better to leave i++ in one line rather than splitting into 3. So that's where the pipe operator can help us to keep the meaningful sections together. I imagine something like this (in a visual form):

getDigits n =
    intToString n
    |> listToSet
    |> map stringToInt

The other thing is to make everything prefix notation to make the functions more suitable for piping.

And to answer the why: everything is moving to mobiles and tablets. The only thing you can't do on a mobile phone is developing apps for that very device. Imagine creating webapps on a computer that doesn't have an internet connection or developing games without a graphics environment... Developing on the device the app will run on makes so much more sense to me.

Thanks again for the opinions!

[Zireael07]

Just stumbled onto this as someone trying to make a visual(-ish) IDE for use on a tablet.

1) The demo misbehaves when the horizontal size is less than 860 px (the fake phone takes the entire horizontal space after it moves below the code editor) 2) No indication that the fake phone can be scrolled. 3) No way to change fake phone dimensions (think desktop browser pretending to be a phone, I use this feature a LOT when developing)