🚀 go-pugleaf

> 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