Very interesting (and inspiring) to get an insight into the visions of the people behind Racket.
Third in a series (#1, #2) of questions occupying my mind at the beginning of 2014. Which may (or may not) inform what I’ll be working on.
3) How can we program on tablets?
I’m now a tablet user. I became a tablet owner at the end of 2012. For six months I played around with it, trying a few Android programming exercises. But I only really became a regular tablet user half-way through the year. Firstly when I put Mind Traffic Control into a responsive design. Secondly when I bought a couple of e-books. And I only really got committed when I did OWLdroid and coupled that with btsync.
So – somewhat late to the party, I admit – I’m now a tablet enthusiast.
And so my question is, how the hell do I program on this thing?
There’s a trivial answer to that question : get an external keyboard, an appropriate editor / IDE and treat it like a normal computer with a small screen. I can do that. I’ve worked a lot on netbooks and small screens don’t freak me out. But that’s not really what I mean.
Because tablets aren’t meant to have keyboards. And a computer without a keyboard challenges one of my deepest held programming beliefs : the superiority of plain text.
Plain-text is so flexible, so expressive, so powerful, so convenient to work with, that I’ve always been highly sceptical of those who want to do away with it. But on a keyboardless computer, it’s a different matter. Plain text isn’t at all convenient without a keyboard.
Especially the text of programming languages which makes rich use of another dozen or so punctuation symbols beyond the alphabet and numerals. And where manipulation relies on cursor-keys, shift and control, deletes (both forward and backspace), page up and down, tab-complete etc.
And yet tablets are becoming ubiquitous. Increasingly they’re the target of our programming, and the tool we have with us. So how are we going to program in this new environment? With multi-touch or stylus but no keyboard?
I have yet to see anything even vaguely plausible as the revolution in programming “language” we’re going to need for this.
I don’t think it’s the “Scratch”-like or “App Inventor”-like “stick the blocks together” languages. The problem of programming on tablets shouldn’t be conflated with the problem of teaching novices to program. (Which is what most visual programming environments seem to be about.)
One issue with that kind of system (and other “flow-charts”) is that blocks need to be big enough to be easily and unambiguously manipulated with fat fingers. But to be decently usable, a programming system should be able to have a reasonable density of information on the screen, otherwise you’ll spend all your time scrolling and forgetting what you’ve seen. How do you resolve that tension?
Perhaps “data-flow” programming of the Max/MSP, PD, Quartz kind. Piping diagrams. Process Modelling packages have something to teach us about orchestrating in the large. But they are shockingly clumsy for certain fine-grained activities that are expressed easily in text. (Eg. how the hell can you talk about tree-shaped data or recursive algorithms using this kind of piping model?)
So I don’t have any information about who is doing interesting work in this area. (Aside : while writing this post, I thought I’d consult the collective wisdom on StackExchange. Needless to say, my question was immediately shot down as too vague.) But I’m now very curious about it.
How might such a world (of universal programming literacy) come about?
Most likely from a continuing trend to automate the way a lot of work gets done, and then people would learn programming as a way of engaging with that world.
For example, instead of spending half an hour in the supermarket or even 10 minutes browsing a supermarket site on the web, you might be able to compose an augmented shopping list on your phone.
4 bread rolls
Could become :
prefer("Pink Lady" or "Fuji").
Similar little languages can be developed for most activities. So I’d guess that we’ll all be writing little scripts for robots or large automated services. There’s an assumption that people must prefer navigating rather laborious graphical interfaces to get stuff done. But if they were more programming literate they may learn to use and love such small scripts instead.
Initial thoughts :
Big question is what it compiles to. It’s about time we had a programming language that compiles a single program down to parts that run on both server and clients, in a really easy and transparent way.
Building in knowledge of protocols like http and json and making services like twitter at least members of the standard library is a good idea.
Like most programmers, I’m sceptical of the “easy English-like” nature of it. We’ve had plenty of time to learn that what’s hard in programming is the logical thinking not the strange syntax. (Update : See my Quora answer)
But if Dog can become a little-language which makes it easy to configure and administrate social software back-ends then it will be very useful. Particularly if there are ways of compiling the same program down to multiple back-ends (Django, Rails, Chicago Boss etc.)
Back writing more Prolog and getting into Definite Clause Grammars. Having a parser generator built into the language is sweet. 🙂
This is an absolutely brilliant summary of the virtues of PHP.
But it will retain the virtues of PHP : none of this fussy separation of presentation and logic; easy discoverability of where URLs go; fast iterative development; big built-in library etc.
(Hat-tip, BillSeitz for the links)
Shapes is a functional drawing language.
Phil Windley on creating your own Domain Specific Language.