A lot of the demos I see for novel programming environments run on laptops, which all programmers own. But most people right now are on smartphones or tablets, which are severely underpowered from a programmability perspective. This makes me think that the potential impact for these kinds of projects is actually much bigger on smartphones than on laptops(I concede that on the scale of decades though, these hardware trends may be less meaningful). So I’m curious if anyone here is working on programming for smartphones or tablets, and what your thoughts are on the limitations and potential there.

Current smartphones are closed enough to make a Windows machine seem like a paragon of openness. And then there's the hostility towards developers. I can't even get Apple to accept the password I just reset on my account. And charging $90 or whatever it is to even start installing apps is beyond egregious. So it's not laptops I develop for, so much, but open source. The moment there's an open source mobile device I'll be all over it. (It's also possible I'll go that route myself in a few years. I would really like to avoid that, though.)

Really compelling question! I'm sure this has been said a lot before but I think there's a serious bandwidth issue. It's hard to get good interactive text entry with a virtual keyboard + thumbs. If this is solved I think there will be some really positive downstream effects. I think there are some promising ways to improve bandwidth, maybe with something like Swype or even mid-air text entry with devices like Google's Soli sensor

@Kartik Agaram Well, Android is open source, and there are a number of forks that strip out Google's proprietary extras if you want that. F-Droid is an open source app store that you can install on any Android phone: no jailbreaking is required. It hosts some cool apps that you can't find in the iOS app store due to Apple's policies. Although you can install Android binaries directly without using an app store, F-Droid gives you automatic updates. Contributing to F-Droid is a merge request on their GitLab repo: no annual payments to Apple are required.

Interesting. I'm going to try it out.

Before installing an alternate Android distro you must check that your phone hardware is supported. Then gestures, etc will work, that's part of the Android core. What is typically missing are the Google apps and the Google play store.

You can install apps on your own iOS devices without paying anything. You just can’t distribute them on the App Store. I’m primarily focused on touch-screen devices. You can still hook (Bluetooth) keyboards up to them and connect them to larger screens, if you still want classic text entry, but I think that’s exactly what makes mobile devices so successful with the general public: text entry is possible and good enough, but the device is not optimized for it with a large, physical, full-size keyboard. We need to pull programming into that world — less dependence on keyboard and more alternative interactions. Writers should be more dependent on keyboards than programmers. After all, what we do is mostly selecting symbols from a pre-defined set of possible options and arranging them in hierarchies. There must be alternative ways to do that than just typing them into a text editor. If you think about it that way, you might even start to believe that there must be a more efficient way to program than typing text. Crazy, I know.

Jolla Sailfish OS is another breakaway OS: https://jolla.com/ They've survived for a long time through much upheaval in the industry, so I expect them to keep on keeping on! https://twitter.com/JollaHQ

Hopscotch has done a lot of work to make their programming experience feel native to mobile. (one Future of Coding podcast is with founder Samantha Jones)

I am waiting for AR or VR for coding. I want to program to humans. Smart phones are for consuming , and can only produce simple content .

@Stefan you talked about input, but what about output? A phone is an awfully tiny peephole into a codebase, and large touchscreens seem unlikely to become ubiquitous. Between those two constraints, don't we just end up with a laptop-like system where we swipe around in a small screen to make changes in a large screen?

@Stefan "You can install apps on your own iOS devices without paying anything."

This is a misleading statement. • On Android, if you click on a link to an Android executable, the web browser will ask if you want to install the app. Distributing apps outside the Google Play app store is trivial. • On iOS, nothing like this is available. There is a specialized technique available to iOS developers for installing apps on their own devices, for testing purposes only, but this technique is deliberately locked down by Apple, by the use of digital certificate trickery, so that you can't use it to distribute apps. In practice, a user cannot install apps on an iOS device without going through the official Apple app store. This distinction between Android and iOS matters, because Apple heavily restricts the kinds of FoC content that they will permit in the iOS app store. For example: • Apps may not download or install standalone apps, kexts, additional code, or resources to add functionality or significantly change the app from what we see during the review process. • Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. • Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected. There's more, and Apple will reject apps for additional reasons that aren't written down. In general, Apple will not tolerate any iOS software that conforms to Alan Kay's vision of "personal dynamic media", in which personal computers are fully programmable by the end user.

Deadline is next Wed!

Hey, @Doug Moen, I was just trying to resolve a common misconception about iOS development. Thanks for clarifying. Seems like you have a strong opinion on where the future of programming is going to happen… or not. I support you. I’d love to see your plan come to fruition and challenge the status quo. More competition would be great. However, I’d also like to encourage you to not close your eyes and ignore what’s happening on the platforms you don’t support for whatever reason. Good ideas can pop up everywhere. There’s a lot of great talent working on Apple platforms, in particular people who are not just exceptional developers, but also have very strong design skills. We all have our preferences. For platforms. For tools. We can’t even agree on a language. I hope that’s not getting in the way of learning from each other.

@Stefan This is not a "preference". I can't develop FoC software for iOS because Apple has locked my software category out of their platform. This is Apple's decision, not mine. I am aware that there is some great software being developed for iOS. For example, there's a lot of great real-time music performance software for the iPad, and there's very little of that for Android. But for the FoC mobile software experience I described, based on Alan Kay's vision, the only hardware that supports it is Android devices and Windows tablets.

My thoughts on the screen size issue: Last year I made a small prototype of a data-driven design tool for smartphones: https://twitter.com/yoshikischmitz/status/1176642448077967362?s=2 So the screen size imposed a lot of constraints, the biggest one is limiting the number of things you can display at once, which in turn limits the number of things you can reason about at once(for example, I wanted to edit properties of multiple nodes at once, but that wasn’t possible in that panel based UI). One solution I’ve thought about is to leverage the fact that many people own or have access to multiple smartphones, and create a programming system that can run on two phones at once, and the user can decide how to divide things between them. So you could say, use one smartphone as a “preview” device and another as an “editing” device, or use one phone as a debug log. Another one I’ve thought about particular to my app is to allow one to extract property editors for multiple nodes into another panel where you can edit multiple properties side by side. If you have multiple such panels and can quickly switch between them, my hunch is that you would be able to get some nice productivity.

Firstly, to those people who object that Apple has a "walled garden" approach, Apple has had a very salutary effect on the ability of the independent developer to earn an honest living. With piracy protection, a marketplace that is considered family friendly, and an honest company that pays monthly, i don't see what is wrong about the $99/year publishing fee. You don't pay per title submitted, and this encourages people to make lots of apps, which they do. This ecosystem generates tens of billions in royalties to developers, and allowed me to feed my family, at least in the beginning, when the number of titles was reasonable. In the history of publishing the Apple royalty rate of 70% of retail payable to the developer is an order of magnitude better than in previous industries like books or recorded music. The overwhelming success of the App store has exposed the very poor indexing system that they have not modified much since its creation. To my knowledge there are many programming apps on the store, and i am not aware of any programming language toolkit that was blocked from publishing due to App store restrictions. Yes, their decision-making logic can be capricious and if you have any nudity be prepared for a long slog. It took me two months get an art calendar with Adam and Eve represented to be approved, which doomed the product. You can't really expect Adam and Eve to be wearing clothes. And I wasn't too fond of Apple kicking out my titles because i wouldn't update them to accommodate their stupid notch. They also have a nasty habit of breaking stuff along the way, because they just-don't-care about older hardware and software. As an apple customer you are expected to follow their releases. In that respect, MS is a far more generous company. As for tools that generate Mobile, Desktop and Web, there are several FoC projects like Red, Beads that are targeting cross-platform development where one code base can emit products on multiple platforms. There are long running framework/language combinations like Dart/Flutter which are good at this as well. I personally find it bizarre that people accept the expensive and wasteful system of having different toolchains for each of the 3 main platforms (IOS, Android, Web), not to mention the other 2 big OS (Mac and Windows).

There's a fundamental philosophical divide here: I don't care about improving how we sell software. That side seems to be working fine. Being a programmer pays great, in a wide variety of ways. So sure, it's great that Apple lets programmers sell consumptive apps to laypeople. It seems irrelevant to our agenda of getting people creating more with their computers.

@yoshiki I think every tool that allows people to manipulate abstract

structures (in our case code) needs to help people build a strong mental

model of that structure in their minds.

We probably often want some sort of symbolic semantics to extract a view or lens of some larger structure to reason about, manipulate, or connect it with, another view from a different context, and intuitive means to rediscover the contexts for when we inevitably lose track of them. We would want ways to quickly view a compressed gist of the larger structure when we forget it, without having to review the whole thing. And we would want powerful organization primitives to teleport from one context to another (like in a table of contents or an index of a book), without having to retread the particular path we first took there.

I don’t think we have a good “universal UI language” for these operations, nor a good internalization as designers of how people forget and lose track of things, but I suspect that if we did, it would make such operations on every device more powerful, regardless of screen size.

This is an excellent summary of the problem. My idea is to organize the entire structure in space, and build a zoomable user interface for navigating the structure. It won't be straight "photographic" zooming. Instead, as you zoom out, structures are progressively compressed by eliding increasing more detail, while allowing important labels to remain visible for longer. Zooming in adds details. The zooming, and the animation as details are squashed during zooming, needs to be continuous and smooth, not jerky. The graphics implementation will rely heavily on the GPU hardware.

Video on following thread is quite describing current state of GUIs (https://futureofcoding.slack.com/archives/C5T9GPWFL/p1579324191059700). GUI is usually flat static object with literals. Interaction is only about editing literals and navigation between views. We can copy some literals to clipboard and recover them but for example you cannot even copy/paste value of multi select button. Maybe: -Treat all literals as real copy pasteable values like mutiselect buttons, radios, checkboxes, file inputs etc. -Treat composition of form values as first class 'thing' -Allow user to manage those literals outside of specific form -Allow user to define variable so that single value can be updated easily on multiple places

@Niko Autio I'm actually in the very early stages of an exploration into what the GUI would be like if all values and views were individually addressable, so they can be pointed to, combined, and reacted against, in a space of continuous context-preserving navigation. Inspired by Smalltalk and Morphic, but trying to place it in the contemporary context of smartphones, multiple devices, apps, and services.

When I look at conventional GUIs, even on mobile, what I see is not what I want. Everything I see on the screen should be an object running on some underlying VM. I should be able to interact with any object I see. I should be able to view the source code of any object on the screen, and edit it (this is my idea of what "open source" should mean). Obviously, any text I see should be selectable/copyable. This means inventing a new and richer GUI interaction language. @yoshiki, are any of your explorations in a blog or on github?

@Doug Moen Totally agree! I have some previews of a comic I'm working on regarding this topic on Twitter(https://twitter.com/yoshikischmitz/status/1188455560045158400), but my perspective on what the UI should be like has evolved since then. Besides twitter, once I do get something ready for more public consumption I'll post it to #CCL5VVBAN.

@Doug Moen I don't see how this is possible. Every single text entry control in the wild has at least one million lines of code underlying that supposedly simple control. I assert that the difficulty of programming a text entry control prevents a startup from building a new operating system. Anyone with a medium degree of competency can make buttons and sliders, but the minute you ask for switching between left-to-right languages and right-to-left, and rendering TrueType with kerning and ligatures and fancy swashes, you are now in a sea of underlying modules and technologies. TrueType is this weird language that holds the letter shapes. Almost everyone thinks that a font is some kind of vector artwork file, but it is not; it is a programming language that is executed by an interpreter, and I doubt there are 100 active programmers who know it, it so obscure. A truly bizarre language it is, basically a domain specific 2D vector to raster language. A lot of the other controls an OS offers are indeed simple inside, and could easily be interact-able/editable. It is one of the central reasons why there are so few graphical OS'es to choose from. You have Windows, IOS/OSX, Android, and the slightly inferior Unix renderers, which never got near the sophistication of the others. I would argue that one of the reasons why we haven't gone full 3D in OS'es is the subtleties surrounding text processing are quite difficult. People often fail to grasp how powerful Adobe was in the beginning, and how both MS and Apple conspired to damage Adobe by inventing their own rendering technology so they could avoid using Adobe's renderers. (The predecessor of Postscript was invented at, yes you guessed it Xerox PARC). You can see in the Adobe products that they do their own rendering, and even have optical kerning (the subtle squeezing of letters together so they read better). And let's not forget all the Input Method Editors that are used with Chinese, Japanese, and Korean, which require very sophisticated algorithms to minimize keystrokes. those are part of every input field, implied, and each OS has pursued slightly different approaches. This is why only giant companies can make an OS today.