Before I comment, I'll just express how insanely cool this is. Mobile programming environments suck right now and this is a step in the right direction. Good proof of concept.
Excuse me if this is implemented and just not in the README:
It would be super awesome if there was a type inference engine that fed into the UI to increase productivity.
For example, if I start to define a function that returns an int, when I go to write out the definition, it suggests functions to me that return ints.
Suppose I pick a function "string_length" which takes strings and returns ints. Now I continue the composition, so it suggests functions (either built-ins or user-defined) which return strings.
Suppose I pick "bool_to_string" which takes a bool and returns strings. Then to finish off the function I pick from a list of bool-returning functions, say I pick "xor".
So now with a few keypresses I have defined a function that, in C, would look like:
Yes! Typing is a BIG question here and I think some form of static analysis is going to be a critical piece of the puzzle. Completely dynamic menus I think can make users have to think too much, but it could work if you have static menus that pop up based on type (for instance, I just hit bool_to_string, so I'm already getting ready for the string-based menu that I know is going to come next...)
I’m working on a statically typed concatenative (stack-based functional) language called Kitten, and it’s one of the eventual goals to use type information to enable better editing environments, including on touch devices as seen here. The language is still a research project at this point, but it might be something you’d like to keep an eye on.
I had no idea this many people cared about this sort of thing! I'll totally follow along. I think there's something real in all this; we just need the right combination of ideas, and perhaps the will to collaborate.
Statically typed concatenative programming may be at the point that lazy functional programming was a few years ago. As valuable as separate research and hobby projects are, at some point we should probably put our heads together and collaborate on a single vision.
I’m more than willing to lead the effort if there’s enough interest—but as it is, it seems like those most interested in seeing it happen are those least interested in actually helping. So I just keep working on Kitten.
Factor is an impressive piece of engineering, and for those who like dynamic typing, I’d strongly encourage people to use it, and see how useful a dynamic and reflective programming environment can be. It’s just not the language I want to build.
If you haven't already, you may want to look into "row polymorphism". I've been working on and off on a statically-typed stack-based language with type inference called Parles; it's not 100% yet, but you can check out my type inference algorithm in the git repo: https://github.com/gliese1337/Parles
Fantastic; I was unaware of row polymorphism, and I'll certainly dig into it deeper. Partly, I intentionally wasn't thinking about the typing because so many incredibly intelligent people are already working on that.
My first thought was, "How does this compare to Swift?" But this is totally different: you want to create useful programs _on_ the touchscreen device.
It's purely functional and stack-based. This is a clever approach to the UI problem - how to program when you can't typeLongWords? Answer: use the stack! I expect the act of writing programs will feel a lot like using an old programmable calculator.
Yes! The title could be better. While researching this, I found an amusing comment: "Reverse Polish notation is so last century" That's probably true. Still, I think it's a fun project. If you're interested in this sort of thing, I also recommend checking out the programming languages "Joy" and "Pure". I find both really interesting.
I'll add official build info tonight, but it's a cordova app, so: (also be aware most things are buggy or simply not implemented right now)
1. Holy shit that is a fantastic way to do mobile UX. Radials for each thumb? Fucking brilliant. I could imagine this could also make a great keyboard layout for certain domains
2. I would flip out even more if this UI was available for more mainstream functional languages like Haskell or Clojure. Do libraries break the process? I don't think they have to.
:) Thanks! I don't really understand why radial menus aren't all over the place, frankly.
I think there is a ton of room to adapt popular languages to mobile (and would love it if this inspires someone to do that!) Here, I'm more trying to figure out what the upper bound is for how efficient it could possibly be. So, (1) avoid naming things and (2) be super minimalistic in your primitives. For instance, I was wondering whether I should even have a sum() function. Perhaps not. Perhaps lambda-plus-reduce becomes the way you "spell" the word sum. I haven't convinced myself on that point, but I think it's fun to consider.
In High School I read through a lot of Don Hopkins' blog on Pie Menus (https://en.wikipedia.org/wiki/Pie_menu) and also wonder why they continue to be infrequent in usage. The interesting thing is that apparently on Don's watch the proliferated somewhat in NextStep, but never quite made the leap to OS X Cocoa (and subsequently iOS), which seems interesting. Maybe there's an AU out there where OS X and iOS are heavily radial menu driven.
I wrote an article for InfoVis.net about "Why pie menus aren't ubiquitous?" [1] in 2003, but since they still aren't ubiquitous, it's good to keep asking that question.
They may not be everywhere, but they've turned up many places, including games like The Sims, and tools like the Grasshopper visual programming language for Rhino 3d.
Some NeXT Step applications may have implemented pie menus, but I tried unsuccessfully to convince Steve Jobs to make them an official part of the NeXT Step GUI.
On October 25 1988, I gave Steve Jobs a demo of pie menus, NeWS, UniPress Emacs and HyperTIES at the Educom conference in Washington DC. His reaction was to jump up and down, point at the screen, and yell “That sucks! That sucks! Wow, that’s neat! That sucks!”
I tried explaining how we'd performed an experiment proving pie menus were faster than linear menus, but he insisted the liner menus in NeXT Step were the best possible menus ever.
But who was I to rain on his parade, two weeks after the first release of NeXT Step 0.8? (Up to that time, it was the most hyped piece of vaporware ever, and doubters were wearing t-shirts saying "NeVR Step"!)
In the mean time I've been developing pie menus for many different applications and platforms:
This is a demonstration of the pie menus, architectural editing tools, and Edith visual programming tools that I developed for The Sims with Will Wright at Maxis and Electronic Arts.
They have a full set of useful notifiers so you can tightly integrate them with your application to give rich feedback during tracking (for example, modifying the 3D menu items, or previewing the effect of the menu item and distance parameter in real time, making them more like "direct manipulation").
For example, to show how you can implement feedback like The Sims pie menus with the head in the center that looks at the selected item, I've made a 3d object in the pie menu center with the webcam texture on it, so YOUR head is in the center of the menu, looking at the selected item! (That's why the demo asks for permission to use the webcam.)
The pie menu and each item has a title as well as a description. One feature I've added is the ability not only to disable an item, but also to provide an explanation of why the item is disabled! (PacMan in the demo is disabled, for example.) I wish other menus and widgets would do that -- it's frustrating when you can find an item you want, but can't figure out why it's disabled!
Another nice thing about them is that you can either configure algorithmically with an API, or with JSON data (which makes it easy to make dynamic data driven menus downloaded from a server or database), or construct them in the Unity3D editor out of objects (which makes it easier for artists to design them)!
I've made a custom Unity3D editor that lets you edit the properties, drag and drop textures and objects, edit and rearrange the items, and has some convenience commands, so you can place the 3D item objects in a circle in the 3D world, and call a command that figures out which item is in which direction by their position, and tidies them up. (That is much easier than arranging their order in a linear list of items.)
I'm going to play around with more in-world editing features, to make them easier for artists to design them.
This is a demo of a user interface research prototype that I developed for Will Wright at the Stupid Fun Club. It includes pie menus, an editable map of music interconnected with roads, and cellular automata.
It uses one kind of nested hierarchical pie menu to build and edit another kind of geographic networked pie menu.
One nice thing about PostScript is that it's homoiconic: PostScript code is just PostScript data. So that lets you use a data structure editor as a code editor.
It had a generic set of pie menus that applied to all objects for editing the view and doing standard copy/paste/edit/eval operations, but there was also one object-type-specific submenu to the north-east. So there was a common set of gestures across all objects, that you could learn to use easily.
This is amazing. In 1989. And here we are in 2015, looking at data by feverishly flipping arrows in collapsable trees in eclipse. I just don't get it.
I am somewhat in love with homoiconicity; perhaps no other revelation in CS mattered more to me than that discovery when learning scheme. Here's the one sticking point that I couldn't figure out: how to live without closures. Building up a quoted hunk of code and injecting the right values in the right places just seems so much less clear. Thoughts?
Maybe it's just a matter of having the right helper functions, like something that does printf-style substitution for quoted programs?
And I'll need another hour to go through all those other links above, but I'm excited about it! More later.
It could use a lot more explanation! Or, at least, something more than zero. I appreciate you taking the time to reason it out in spite of that. For the moment, I'm just collecting some preliminary feedback. I owe you some real docs once I get to an alpha, plus interest.
Nice work! I have been playing around with touch programming concepts for a while but did not yet dare to show any to the world. Let this stimulate me in that and hope others will follow. Even if just for fun.
Excuse me if this is implemented and just not in the README:
It would be super awesome if there was a type inference engine that fed into the UI to increase productivity.
For example, if I start to define a function that returns an int, when I go to write out the definition, it suggests functions to me that return ints.
Suppose I pick a function "string_length" which takes strings and returns ints. Now I continue the composition, so it suggests functions (either built-ins or user-defined) which return strings.
Suppose I pick "bool_to_string" which takes a bool and returns strings. Then to finish off the function I pick from a list of bool-returning functions, say I pick "xor".
So now with a few keypresses I have defined a function that, in C, would look like: