> Tutaj jedyna wartość dodana to "wiedza z eksperymentu".

OK. To jest jak najbardziej wartość dodana. Tzn. na razie jest to dług techniczny,
ale niech będzie, że jest to inwestycja w eksplorację.

> Docelowo zaś: jest nadzieja, że dla różnych zastosowań zwiększy to efektywność
różnych interakcji za pośrednictwem Smartfona.

OK. Ale dlaczego tylko smartfona? Nie będę mógł skorzystać z tego pomysłu machając
myszką na desktopie? Chciałbym.
Inaczej mówiąc - nie traktuj wspomnianego wcześniej kibelka jako docelowego
use-case'a. Nawet jak już wszyscy będą mieć po trzy telefony, to jednak praca
inżynierska nadal odbywać się będzie na dużym ekranie (i słusznie).

> Ja sobie myślę o nieco bardziej "telefonowych" use case'ach: że rysuję sobie guziki
na ekranie i je rozmieszczam jak mi wygodnie, i przypisuję sobie do nich różne
funkcje.

20 lat temu robiły to różne Buildery i inne Visuale. To się nazywało RAD.

> Może na przykład rysowanie diagramu przepływu sterowania na telefonie okaże się
lepszym pomysłem?

Znowu ślepa uliczka. Rysowanie diagramu ogólnie jest lepszym pomysłem, nie tylko na
telefonie.

> Na pewno największą motywacją dla mnie jest w tej chwili wizualizacja danych.

Tak. Ale podchodzisz do tego od strony edycji. Wizualizację można zrobić bez edycji.

> Że na przykład (-1, 1), (1, 1), (1, -1), (-1, -1) mówi mi stosunkowo niewiele, ale
już coś w rodzaju
>
> +------+
> | |
> | |
> | |
> +------+
>
> (kwadrat, na wypadek gdyby się źle sformatowało) mówi mi nieco więcej.

Tak. Przy jakiejś tam metodzie wizualizacji. Bo akurat narysowałeś wielokąt rozpięty
na zadanych punktach. A może to miał być graf?
Ale zgadzam się, że wizualizacja jest potrzebna.

> I nie chodzi mi o to, że chcę mieć obrazek, tylko że dla każdego rodzaju danych, z
którymi pracuję, chciałbym mieć wyspecjalizowany edytor do pracy z tym właśnie
rodzajem danych. Albo nawet kilka wyspecjalizowanych edytorów.

Dobry pomysł.
A tak nie jest? Mam edytor do plików graficznych, inny edytor do plików dźwiękowych,
jeszcze inny do kodu, inny do arkusza kalkulacyjnego, inny do schematów
elektrycznych...

> Ja mam taką nadzieję, że może iteracyjnie uda się dojść do takiej sytuacji, że
tworzenie kodu na ekranie dotykowym będzie nie mniej efektywne od tworzenia go z
poziomu klawiatury.

To może krok albo kilka do tyłu. Dlaczego chcesz tworzyć *kod*?
Może to właśnie kod jest ograniczeniem, a nie metoda jego wprowadzania?
Może np. graf jest lepszy od kodu? Wtedy nie trzeba myśleć o nowej metodzie
wprowadzania kodu, tylko o nowej metodzie wyrażenia jakiejś intencji, jak np.
następstwo zdarzeń. W tej koncepcji niech kod zostanie kodem (bo tak jest dobrze i
nie trzeba tego poprawiać) ale niech też istnieją inne artefakty inżynierskie, które
nie są kodem.
I do tych innych będzie można zrobić inne edytory. I to może być autentycznie lepsze,
niż obecne opisywanie tych wszystkich innych koncepcji kodem, tak jakby kod był
jedyną metodą zapisywania czegokolwiek.

--
Maciej Sobczak * http://www.inspirel.com