Philosophy Mondays: Human-AI Collaboration
Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...

Intent-based Collaboration Environments
AI Native IDEs for Code, Engineering, Science
Web3/Crypto: Why Bother?
One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...
Philosophy Mondays: Human-AI Collaboration
Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...

Intent-based Collaboration Environments
AI Native IDEs for Code, Engineering, Science
Web3/Crypto: Why Bother?
One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...
>400 subscribers
>400 subscribers
Share Dialog
Share Dialog
There are quite a few studies that have come out recently showing that multitasking is bad for performance in humans. For instance, driving your car while talking on your cell phone significantly increases your accident risk. In machines, however, we have come to love multitasking because it enables better CPU utilization. Much discussion has therefore revolved around the iPhone not having multitasking, whereas Android supports it. For starters that simplistic characterization is of course wrong. The iPhone does have multitasking, but app store applications can only run in the foreground (in that regard the iPhone is not a throwback to the time when Apple had an OS that simply did not support multitasking at all). It is easy to poo-poo Apple’s decision, but it is a bit harder to come up with a solution that meets the demands of providing a fast and foolproof user experience. If too many apps start taking up CPU resources it may well result in a slow down of normal phone functions and then how do you figure out which tasks to de-prioritize or kill altogether. On top of that, the iPhone is not exactly known for its battery life and background apps could drain the battery even faster.
I believe though that many of the use cases for multitasking on a phone could be handled by an alert mechanism. Applications could register a simple textual alert for certain types of events. When the event occurs, the phone displays the text and asks the user if they want to switch to the application in question. For instance, a task manager application that wants to provide a reminder would be able to register a time-based event. A couponing application might register a series of location-based events. The phone would run a single background task that looks for events that have been triggered and displays the relevant alerts to the user. If the user decides that an alert warrants firing up the app, they should be able to do so right from the alert panel and the event should be passed back to the app. The alerts should go away if the app is uninstalled or if the user presses a “don’t show this again” button on the alert panel itself.
![Reblog this post [with Zemanta]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/http://img.zemanta.com/reblog_e.png?x-id=b854103b-2790-4489-9d5c-759d7e81e485)
There are quite a few studies that have come out recently showing that multitasking is bad for performance in humans. For instance, driving your car while talking on your cell phone significantly increases your accident risk. In machines, however, we have come to love multitasking because it enables better CPU utilization. Much discussion has therefore revolved around the iPhone not having multitasking, whereas Android supports it. For starters that simplistic characterization is of course wrong. The iPhone does have multitasking, but app store applications can only run in the foreground (in that regard the iPhone is not a throwback to the time when Apple had an OS that simply did not support multitasking at all). It is easy to poo-poo Apple’s decision, but it is a bit harder to come up with a solution that meets the demands of providing a fast and foolproof user experience. If too many apps start taking up CPU resources it may well result in a slow down of normal phone functions and then how do you figure out which tasks to de-prioritize or kill altogether. On top of that, the iPhone is not exactly known for its battery life and background apps could drain the battery even faster.
I believe though that many of the use cases for multitasking on a phone could be handled by an alert mechanism. Applications could register a simple textual alert for certain types of events. When the event occurs, the phone displays the text and asks the user if they want to switch to the application in question. For instance, a task manager application that wants to provide a reminder would be able to register a time-based event. A couponing application might register a series of location-based events. The phone would run a single background task that looks for events that have been triggered and displays the relevant alerts to the user. If the user decides that an alert warrants firing up the app, they should be able to do so right from the alert panel and the event should be passed back to the app. The alerts should go away if the app is uninstalled or if the user presses a “don’t show this again” button on the alert panel itself.
![Reblog this post [with Zemanta]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/http://img.zemanta.com/reblog_e.png?x-id=b854103b-2790-4489-9d5c-759d7e81e485)
No comments yet