mobile coding

I find it frustrating that I have to open up my laptop to start coding. to code on phones, but I still find myself reaching for a heavier device when doing even the simplest of coding tasks.

We are in the where mobile touch devices are ubiquitous, but developer tools have not kept up with this evolution. seems to imply that personal computers are still popular when citing use cases such as gaming. To me, it seems like personal computing devices such as laptop and desktop computers have become the new mainframes - for high(er) performance computing, portable touch devices are not powerful enough.

I can understand why touch devices would lack the compute specs needed for certain games, but I do not understand why writing code would require similar compute resources. suggests that the main obstacle to mobile programming is not compute resource needs, but interface design. When making code editors that fit on small screens, there is usually a tradeoff made between complexity and usability.

is a thesis exploring the limitations to mobile programming. Traditional text editors that rely on interaction don't make sense on touch screens where windows, pointers, and even menus are rare. is an example of this kind of editor.

seems promising but, in my opinion, cannot be paired with existing coding languages. While visual programming could be considered user interface design alone, it really entails creating or redesigning programming languages to break away from text editing.

I do care a lot about visual programming because I have seen kids struggle with JavaScript and thrive with Scratch. I feel optimistic that visual programming would enable end-user programming. The issue is that, although can be designed for touch devices and easy for beginners to learn - I cannot actually make anything useful with it. Scratch embodies the usability vs. complexity tradeoff of mobile programming.

The author of agrees with who argue that direct manipulation is the future of coding.

This makes me think of on direct manipulation. Chun says that:

None of these ideas necessarily suggest that direct manipulation is bad, but they do make me long for a more...pure?...interaction design paradigm.

My primary issue with direct manipulation is that it is not empowering when considering how all graphical user interfaces are first designed using lower level system capabilities. If graphical user interfaces enabled by direct manipulation offered the full power and control provided by and terminal user interfaces, I would not have a problem with them.

Mobile programming does not have to rely on visual programming or direct manipulation. Structure editing, which imposes constraints on user input while editing, can make sense on touch devices. Micorsoft attempted to bring structured editing to mobile devices with the project. Structured editors are language-specific, and still run into this problem outlined in :

"In many creative endeavors, the production and consumption of artifacts are separated, which can lead to undifferentiated production and passive consumption. [This paper presents a system] that blends production and consumption of media into a singular creative process."

is another popular concept. All the mobile programming paradigms considered so far "can lead to undifferentiated production and passive consumption," but programming by example seems to be the worst idea by far.

My criteria is: can the mobile programming tool create a system as complex as that which enables the tool's existence? In other words, can you create a mobile programming tool that could be used to write itself?

With visual programming and structured editing, such a possibility is unlikely yet theoretically possible. With programming by example, such a possibility is gone.

The author of seems to have come to the same conclusion that I have: the usability-complexity tradeoff involved in moving away from traditional text editing is too severe.

create a text-editing experience suitable for touch devices, but user feedback has been mixed. I've been asked to add more features to the but this defeats the purpose of designing a programming tool simple enough for mobile devices. I've also received confusion about whether the tool can be used to write code at all.

Most concerning to me is the fact that I myself do not use the tool I created. I still use Visual Studio Code because, even though I tried to make code editing simple enough for touch screens, code deployment on mobile devices is a problem I have not found a solution to.

I know that I could design a mobile Git workflow for myself, but it genuinely seems simpler to open up my laptop at that point. I have a hunch that solving this problem - passive consumption, the usability vs. complexity tradeoff - would require abandoning the entirely.